redis高可用集群

总的来说是通过hash运算，将不同的键值打散到不同的槽位之中，而每一段槽位的值由一个主从架构来负责存储和响应

这里就涉及到分片算法，其实就是通过对键值进行crc16的运算之后mod16834得到对应的hash槽位

跳转重定位，就是当查询的键值请求打到不是负责键值这一段hash槽位的master节点时，master节点会响应这个键值对应hash槽位对应的master ip给客户端并转发到对应的master

而master之间 的通讯主要有集中式和gossip

集中式就是将各个主从节点的信息存放在同一个地方供其他节点进行读取修改通讯,或是通过对这个集中式存储的监听，达到第一时间感知并获取最新元数据信息的目的

gossip协议就是通过几个约定好的命令，在主从节点之间进行广度有限遍历式地通知广播,  从而达到各个节点之间元数据互换的目的

再一个是网络抖动，因为主从节点之间是需要通讯来知道彼此的健康状态的，但是网络有时是会有波动的，也就是有可能连不上，但又是瞬间的事，过后就恢复正常了，那么我们为了防止从节点因为偶尔的网络波动而导致误会主节点已经挂掉从而引起新一轮的无畏地广播选举master，我们可以通过设置异常时间限制来进行错误重试或者持续连接来确定master真实的健康状态

选举机制

redis cluster的选举机制是当从节点确定主节点已经挂掉之后，会首先计算一下自己的延迟时间，这里的延迟时间其实就是固定的500ms加上随机的0-500ms再加上当前从节点的版本号乘以1000ms数，当经过这段延迟时间之后再向集群中的其他节点发送投票请求，这里会带上当前一轮的期数，而集群中只有master会做出响应，而且只会对同一期数做出一次响应，那么获得集群中master数的半数+1以上的票数就会当选当前主从节点的master，并向其他节点广播

如果从节点得到的票数 一样，那么就会重新发起新一轮期数的投票，以此类推

集群会出现脑裂情况，指的是主从节点中从节点误判了主节点的健康状态后通过重新选举成为master，从而出现了一个主从节点有两个master的情况，这两个master各自接收请求导致当前主从节点的数据错乱问题，我们可以通过master在写入时向从节点发送同步请求，只有超半数以上节点写入成功了，我们才做出成功响应。这样子就可以防止一个单独的master节点擅自接收请求从而导致节点数据错乱问题

集群中之所以推荐奇数个master主要是因为奇数个和相邻的偶数个节点在数据一致性的保障方面其实作用相同，那么用奇数个会更加的节约资源一些,如果为了保证可用性，那么还不如在偶数个基础上再增加一个达到奇数个，这样子即增加了集群的可用性，又增加了数据一致性的保障

批量操作，之所以原则上不支持批量操作是因为批量操作的键值中有可能根据对应的hash槽是会分配到不同的master节点负责处理的，那就无法确保每个节点都能正常处理，索性就不执行这样的批量请求

我们可以通过在原本的键值前面设置一样的值来达到键值都由同一个master处理的目的从而完成批量操作

水平扩展，通过将已有的master节点负责的槽位从开始的槽位各自分割一部分给新增的master负责实现水平扩展