redis的hashtag、槽、故障转移、热点等问题

1、了解一下hashtag的概念以及在cluster集群模式下的使用

2、hash槽在迁移过程中的读写冲突的解决方案

3、高并发下槽的访问冲突等注意问题点

4、redis的cluster选举方案

5、为什么只有16384个槽

6、图参考

附2注意点：

2.5、迁移过程中的读写冲突
因为migrate命令是同步阻塞的，因此不会存在一个key正在被迁移又同时被读写的情况，但由于一个slot下可能有部分key被迁移完成，部分key正在等待迁移的情况，因此如果读写的key所属的slot正在被迁移，redis-cluster做如下处理：

客户端根据本地slots缓存发送命令到源节点，如果存在键对象则直接指向并返回结果给客户端。
如果key对象不存在，但key所在的slot属于本节点，则可能存在于目标节点，这时源节点会回复ASK重定向异常。例如如：error）ASK :。
客户端从ASK重定向异常提取出目标节点的信息，发送asking命令到目标节点打开客户端连接标识，再执行key命令。如果存在则执行，不存在则返回不存在信息。
如果key所在的slot不属于本节点，则返回MOVE重定向。格式如下：（error）ASK :。
客户端从ASK重定向异常提取出目标节点信息，发送asking命令到目标节点打开客户端连接标识，再执行键命令。如果存在则执行，不存在则返回不存在信息
如果key所在的slot不属于本节点，则返回MOVE重定向。格式如下：（error）MOVED :。
————————————————
版权声明：本文为CSDN博主「Shi Peng」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/shijinghan1126/article/details/108256089

附3注意点：

预防“缓存被击穿”总结
评估缓存是否满足具体业务场景的请求流量，不是简单地对预估访问流量除以单台缓存的最大服务能力。
如果使用的缓存机制是按key的hash值散列到同一台机器，则必须梳理出当前业务场景中被高并发访问的那些key，看看这些key的并发访问量是否会超过单台机器的服务能力，如果超过则必须采取更多措施进行规避。
除了关注key的并发访问量外，还要关注key对应value的大小，如果key的并发访问量×value大小 > 单台缓存机器的网络流量限制，则也需要采取更多措施进行数据精简。
————————————————
版权声明：本文为CSDN博主「JJH的创世纪」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ck784101777/article/details/101367821

附4:

master节点选举过程：

1.slave发现自己的master变为FAIL。

2.发起选举前，slave先给自己的epoch（即currentEpoch）加一，然后请求集群中其它master给自己投票，并广播信息给集群中其他节点。

3.slave发起投票后，会等待至少两倍NODE_TIMEOUT时长接收投票结果，不管NODE_TIMEOUT何值，也至少会等待2秒。

4.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送结果。

5.尝试选举的slave收集master返回的结果，收到超过半投票数master的统一后变成新Master，如果失败会发起第二次选举，选举轮次标记+1继续上面的流程。

6.选举成功后，广播Pong消息通知集群其它节点。

之所以强制延迟至少0.5秒选举，是为确保master的fail状态在整个集群内传开，否则可能只有小部分master知晓，而master只会给处于fail状态的master的slaves投票。
如果一个slave的master状态不是fail，则其它master不会给它投票，Redis通过八卦协议（即Gossip协议，也叫谣言协议）传播fail。
而在固定延迟上再加一个随机延迟，是为了避免多个slaves同时发起选举。
 
#延迟计算公式：
    DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
 
SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下，持有最新数据的slave将会首先发起选举（理论上）。
每次痛苦的挣扎过程都是一次成长，坚持过去了就海阔天空；越优秀的人，越自律；越痛苦的时候，越要坚持
————————————————
版权声明：本文为CSDN博主「有盐先生」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Seky_fei/article/details/107611850

附5:

• 如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
• redis的集群主节点数量基本不可能超过1000个。集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个。 那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。
• 槽位越小，节点少的情况下，压缩率高。

作者：寒沧
链接：https://juejin.cn/post/6959080907948949512
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。