个人经验总结

冗余（扩展性）的作用和带来的问题

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

　　一种是主可写从可读。比如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、