主从同步策略
redis
redis因为是要提升性能，所以直接采用的异步复制，当在Master上写入数据后直接返回，然后把数据快照广播给Slave，让所有的Slaves去执行操作。主机宕机后会产生数据丢失的风险
zookeeper
zookeeper同步的方式是zab算法，zab算法是在Paxos的基础上引入了leader的概念，解决了poxas的写操作可以分配到任意一台机器，由于所有机器都可以写，所以写失败也会有很多，花费在io上的事件也就很多的问题。Paxos算法的思想是基于Quorum（法定人数）机制，少数服从多数，对于少数结点的网络异常、宕机、数据不一致，it doesn’t matter,消息尽一切努力送达，数据达到最终一致性，是数据一致性和系统可用性的折中。
kafka
kafka没有采用“少数服从多数”的方法，因为为了容忍1个follower挂掉，必须要有3个以上的replica，如果要容忍2个follower挂掉，必须要有5个以上的replica。也就是说，在生产环境下为了保证较高的容错程度，必须要有大量的replica，而大量的replica又会在大数据量下导致性能的急剧下降。所以这种算法更多的用皂zookeeper折中共享集群配置中，而很少用在需要存储大量的数据的系统中。
kafka采用的是ISR的方式，在zk集群中维护了一个ISR列表，符合以下两点才算是属于ISR列表：
-
broker可以维护和zookeeper的连接，zookeeper通过心跳机制检查每个节点的连接
-
如果节点是个follow它必须能及时同步Leader的写操作，不能延时太久。
当一个消息生产出来时，只有在ISR中的所有broker都commit后，才会返回commit成功。主机宕机后也只能从ISR列表中选取leader。
mysql
mysql通常采用一主多从的部署方式，
- 从库生成两个线程，一个I/O线程，一个SQL线程。i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中。
- 主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog；
- 从库SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；
主机宕机后可能发生数据丢失问题，可以采用MySQL的半同步复制，事务在主库写完binlog后需要从库返回一个已接受，才放回给客户端；
