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

 

 

 

1. Zookeeper选主：

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

 

https://www.cnblogs.com/lanqiu5ge/p/9405601.html#_label26

数据复制原理

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
codis:
https://baike.baidu.com/item/CODIS/18160688?fr=aladdin

redis选主：

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

redis主从数据同步

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

今天每日一题：开启rdb后，redis的启动流程是怎样的？(群员6月面试题）
昨天每日一题参考答案：你觉得使用redis的主从复制的时候有什么点需要注意的吗？
https://blog.csdn.net/weixin_48502062/article/details/107523066
1.主从同步缓冲区设定大小，如果进行全量复制耗时太长,进行部分复制时发现数据已经存在丢失的情况,必须进行第二次全量复制,致使slave陷入死循环状态。在全量复制的时候，最好做好监控。
2.有时候，redis存储过多，全量同步变得不可接受。这时考虑如果增量复制时，发生阻塞，根据业务场景，考虑是否redis进入只读状态，不对外更新，防止全量同步。
3.master 内存占用主机内存的比例不应过大,建议使用50%-70%的内存,留下30-50%的内存用于执行 bgsave 命令和创建复制缓冲区。

 

异常后数据恢复：

 

zookeeper集群一般采用3个节点，redis集群一般采用3从3主结构(redis集群没有中心节点，具有线性可伸缩的功能)。

zookeeper：在zookeeper的选举过程中，为了保证选举过程最后能选出leader，就一定不能出现两台机器得票相同的僵局，所以一般的，要求zk集群的server数量一定要是奇数，也就是2n+1台，并且，如果集群出现问题，其中存活的机器必须大于n+1台，否则leader无法获得多数server的支持，系统就自动挂掉。所以一般是3个或者3个以上的奇数节点。

redis：在redis集群中，只有超过一半的节点说某个节点挂掉了，才能确定某个节点挂了。因此redis集群至少要有3个主节点(如果只有两个节点,挂掉一个,剩下一个投票是不会超过50%的,所以最少要三个节点)。

4. mysql 复制原理

https://www.cnblogs.com/miracle77hp/p/10208405.html

 

5. Raft

（1）Leader election：如何选取leader

（2）Log replication：日志如何正确复制同步

（3）Safety：安全性，即如何保证所有节点应用相同的日志

 

新加集群节点

不停机、不停机？

 

 

在日常开发中，经常使用的有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个同步到锁的节点中选一个主出来，所以锁会正常生效。同时注意到过半原则的精妙，集群在挂掉半数以下节点的情况下，任然能够在数据一致性的情况下保证正常工作。