redis(三)分布式篇

上篇重点持久化
持久化机制
rdb（记录快照）配置多少秒中多少key被修改，aof（记录操作命令）
子进程fork会快照，不会阻塞，所以rdb快

哨兵模式，监控，自动选取主节点
哨兵发送命令，等待redis响应，监控多个redis
哨兵投票（算法），进行故障转移，切换成功后，发布订阅

配置哨兵配置文件
sentinel monitor myredis 127.0.0.1 6379 1
1代表主机宕机开始投票
客户端配置哨兵ip和端口，不再配置redis集群的了。


通过30000响应时间判断是否响应，没有响应，询问其他哨兵，如果其他哨兵统一，真正下线。奇数个，才能投票确定。
然后重新选举master节点
三个哨兵节点，先选个leader，然后这个leader去选
哨兵基于Raft算法进行选举leader

Raft算法

实现分布式一致性算法的协议
一个节点在raft中有三种状态
Flower，候选人，leader
一开始都是跟随者，如果有宕机，然后让其他节点给自己投票，先到先得。
然后就选出leader
选举完成后是数据同步，主节点发起同步给其他，让其他节点写入数据。
这样就达成分布式一致性。

一直会master发送心跳检测，如果宕机，开始倒计时，倒计时时间有快有慢

master选举
然后这个哨兵leader开始选举redis的master节点。
如果与哨兵链接断开时间久，失去选举权，如果拥有选举权，看谁优先级高，如果优先级相同，看谁复制偏移量大，如果复制数量相同，选进程id最小的

sentinel哨兵模式 主从切换可能丢失数据，没有解决水平扩容问题。
100亿条数据，三个redis group怎么分布，获取时候能获取到
不具备分片功能。

分片功能如何实现？

可以通过sharedjedis来实现。

一致性hash算法来实现。hash环
根据redis节点名字计算一下，hash后取模，得到余数，将服务节点挂在hash环
然后计算key的hash值，放到hash环上，然后顺时针取找节点。然后将数据分布开来，将key放到节点上。
增加减少redis节点，影响一小部分。只影响其中一段。这就是hash环的作用

解决动态节点增减问题

但是也有缺点，可能节点分布不均匀。造成负载不平均。
还需要一个东西，就是虚拟节点。hash环上分布虚拟节点
这样就比较均匀分布了。

最后redis-cluster实现

redis-cluster

数据如何均匀分片
客户端如何访问到的相应节点和数据
重新分片的过程，如何保证服务正常

三主三从

CRC16

hash后取模16384，得到余数落在slot上面
创建集群时候预设slot范围在哪个redis group 上

新增节点，数据迁移，不需要借助额外工具，有这个功能

所以不同的东西底层不一样，sharedjedis是通过红黑树实现hash环，来分片
redis-cluster是通过自己配置哪个范围落在哪台机器上，总共是16384，通过CRC16算法，计算后余数落在那个slot上面。

分布式锁如何实现

第一种，通过redis
分布式锁，redis用的时候加锁，携带过期时间，用完解锁，finally中强制删除锁。

Lua脚本保证原子性删除。所以加锁setnx，释放锁lua脚本

这个分布式锁redission已经实现。

延展问题：


分布式id问题生产上遇到过，生产上集群，通过日期+时间+几位随机数来生成一个单号，但是当并发量高的时候，两个单子的id会一模一样，导致无法处理业务。这时候就需要分布式id解决。