分布式（Redis/Zookeeper/Etcd）集群选主，复制

 

 

 

1. Zookeeper选主：

  https://blog.csdn.net/alyson_han/article/details/80044047

数据复制原理

https://blog.51cto.com/welcomeweb/2103292?utm_source=oschina-app

https://www.2cto.com/kf/201808/768816.html

集群恢复：

2， etcd 选主

 

 异常后数据恢复

 

3 redis 集群原理

2.8 以前：哨兵：https://www.jianshu.com/p/06ab9daf921d

redis 3.0以后：redis cluster

https://blog.51cto.com/853056088/2164743

redis选主：

https://www.jianshu.com/p/03d87fa84fc4

redis主从数据同步

https://blog.csdn.net/yuyh131/article/details/83629656

异常后数据恢复：

 

 

4. mysql 复制原理

 

 

新加集群节点

不停机、不停机？

 

 

在日常开发中，经常使用的有Redis锁和Zookeeper锁。redis是基于AP原则的，而zookeeper是基于CP原则的，redis的高性能毋庸置疑，但是在对一些一致性要求比较高的场景下是不能够使用redis的。具体原因涉及到redis和zookeeper的数据主从复置原理上。
1. redis在主从复置时，数据在主节点提交完成就算完全提交了，主节点会通过offset，把提交的数据异步复制到从节点，在使用redis锁时，锁会加在主节点，在Redis服务器工作正常的情况下，OK完全没有问题，但是在Redis 宕机的情况下就会产生问题。假如主节点数据已经提交（占有锁），但是从节点还未收到数据，这个时候主节点宕机，redis（2.8版本以前需要使用哨兵，2.8版本以后使用Cluster模式），从节点被选为主节点，但是此时从节点上没有锁的占用，其他客户端就会重新获取到锁，就会产生锁失效。
2. zookeeper 多次使用了过半原则，在数据的提交时，是一个类似于二阶段提交过程，但是它不需要全部的从节点全部确认之后才提交事物，也只需要过半节点提交即可，这样能够提升一半的性能，也能保证数据的一致性。考虑灾难的情况：假如有5台机器首先在主节点A上加锁，主节点A在过半从节点提交后提交事物，占有锁，假如有3个节点同步到了锁，2个节点未同步到锁，这个时候主节点宕机，Zookeeper会从剩下的机器中重新选一个主节点出来，zab选主协议中候选节点一定是事物zxid最大的，所以会从3个同步到锁的节点中选一个主出来，所以锁会正常生效。同时注意到过半原则的精妙，集群在挂掉半数以下节点的情况下，任然能够在数据一致性的情况下保证正常工作。