Redis_主从+哨兵-集群

 redis_主从复制-读写分离

　　主从架构开始第一次 全量把数据通过rdb到从节点,后续是AOF日志追加数据 简单的主节点挂了需要手动改代码连接到子节点

　　防止数据不一致,从节点只能读 不能写

　　一主一从,一主多从,树状主从

 

redis_哨兵模式

　　1.主从要主动改代码切换节点,哨兵自动切换,Redis自带哨兵功能

　　2.其实就是单独出来1个线程监听主从架构(使用redis的发布订阅模式来哨兵和主从节点互相通信), 官方推荐哨兵的节点最少是3台,并且是单数防止平票

　　3.宕机的情况,主观宕机：单独的哨兵认为你宕机了则认为你发生了故障

　　　　　　　　客观宕机：半数的哨兵认为主节点宕机,就是发生了故障

　　4.选举主节点的规则：1.健康度：从节点响应的时间,2.完整性：从节点备份数据的完整型,根据数据备份的偏移量,如果越高代表备份数据越完整3.稳定性,根据启动周期,心跳检测,就是哨兵和从节点之间的互动。4.如果上面三个都相等,则根据节点的启动时分配的runid来,runid越小则最优先选择

　　a.偏移量计算,选举主节点公式

　　5.脑裂现象：出现了主节点和哨兵之间的网络波动,而且多数哨兵认为主节点宕机,则会从现在的节点选为1个主节点,这个时候客户端还是连接之前的主节点,继续往之前主节点写数据,此时哨兵选举了新的主节点,但是网络又突然好了,于是造成了数据不一致

　　客户端写12345数据往主A节点, 哨兵和主节点网络波动,选了新的主B,主B的数据写了1234567,但是网络又好了，于是主A的数据备份到已经变为子节点的主b 。造成数据不一致

　　6.异步复制数据丢失问题：主和子节点复制数据太慢,然后宕机了,这个时候从节点变成主节点。造成数据丢失

 

 

 

 

redis_集群原理

　　1.副本复制的集群-多个节点都可以读写,且数据一致,kafka使用的就是这种-这种需要解决数据一致性问题

　　2.redis采用的是分片模式-每个节点只负责一部分的数据读写

　　1.数据书否分配均匀

　　2.数据节点增删对数据分布影响不能太大-性能问题

redis集群分配规则是-按数据槽

怎么分配哈希槽-哈希取余：  redis用的是哈希环 先哈希,如果计算哈希得到哈希槽为1,则吧数据放在哈希环上1-2之间的虚拟节点 有固定的16384个哈希槽点