个人经验总结

冗余(扩展性)的作用和带来的问题

分布式系统中,实现可扩展性(节点冗余)是实现系统高可用性、数据可靠性的重要手段,因为冗余使得节点挂了备用节点可顶上、数据丢了备用节点的数据还在。这些冗余节点组成了集群,且通常是主从模式。其运行模式通常有两种:

  一种是主可写从可读。比如MySQL主从复制、Redis主从复制架构。

  另一种是主可读写从不可读写。比如Kafka 的 partition replacation,前面Redis 分布式模式下主从的关系。这种模式在分布式系统中很常用,从节点不提供读写,只作为主节点的备份,在主节点故障时顶上发挥作用。

可扩展性(节点冗余)下,必须思考的问题有:主节点选举、不同节点间的数据一致性等。

 

提高数据写效率的措施

为提高数据写效率,措施有:

利用内存:

WAL:写内存+写日志。比如MySQL bin log 和 redo log 写时的两阶段提交

内存缓冲再批量写。比如MySQL redo log 的写。

不利用内存:分区、append only、零拷贝等。比如 Kafka Topic 数据的内部写。

 

WAL(Write Ahead Log)技术

为提高读写效率,写的数据通常不立即持久化,而是只写内存。此时有个问题:服务器故障会导致内存数据丢失,如何解决?写内存的同时以append onlf的方式写日志,客户端请求写数据时,服务端先写内存再写日志完成后就返回响应给客户端。这就是所谓的WAL(Write Ahead Log)技术。例如MySQL的redo log,Zookeeper数据的持久化等都是这样。该技术在分布式系统中很常用。

当然,同样地也可对日志写进一步优化,即先写内存、攒一定量后再持久化。持久化的策略:达到一定量持久化、后台开线程周期性持久化等。

MySQL的数据写实际上就是上述两种方式的结合,详情可参阅 MySQL的日志原理-MarchOn

 

 

 

为什么分布式系统中集群的节点数不少于3且通常是奇数?

因为做一个决策(主节点挂了需要进行leader选举等)通常要求少数服从多数,最极端的场景是决策意见相反的两方势均力敌(双方都是n个),为了达到少数服从多数,一方至少要多一个1,故总的至少要n+n+1=2n+1个。因n是正整数,故至少需3个节点。

 

专题

1、

2、

原文地址:http://www.cnblogs.com/z-sm/p/16440944.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性