大家好，欢迎来到IT知识分享网。
哈希槽
Redis-Cluster 集群模式使用了哈希槽（hash slot）来实现数据的分片，hash slot 的默认长度是 16384. 应用程序去存储一个 key 的时候，会通过 CRC16 计算后取模路由到对应 hash slot 所在的节点。
原因
一般情况下，对于一个中间件中某些特定的阈值的设计，都是通过相关计算和测试得到的一个相对比较合适的值。对于 Redis 中的 Hash Slot 为什么是 16384 这个问题，我认为有几个考虑因素：
- 对于网络通信开销的平衡：Redis 集群中每个节点会发送心跳消息，而心跳包中会因此每个节点需要维护的配置信息占用空间大小就携带节点的完整配置，它能够以幂等的方式来更新配置。如果采用 16384 个插槽，而每个插槽信息占用的位数为 1，是 16384/节点数/8KB，假设是 3个节点的集群，则每个节点需要维护的配置信息占用空间大小为 2KB其次，CRC16 算法产生的 hash 值有 16 位，如果按照 2^16 次方计算得到 65536 个槽那就会导致每个节点维护的配置信息占 8kb。8kb 数量的心跳数据看起来不大，但是这个心跳包每秒都需要把当前节点的信息同步给集群中的其他节点相比于 16384 个 hash slot，整体增加了 4 倍，这样会对网络带块带来极大的浪费。并且这个浪费并没有带来更好的效果。
- 集群规模的限制：Redis Cluster 不太可能扩展到超过 1000 个主节点，太多可能会导致网络拥堵等问题，因此，在这个限制条件下，采用 16384 个插槽的范围比较合适
- 16384 个插槽可以确保每个 master 节点都有足够的插槽，同时也可以保证插槽数目不会过多或过少，从而保证了 Redis Cluster 的稳定性和高性能。
总之，16384 个槽的数量是经过考虑和实践得出的，既可以满足 Redis 集群的性能要求，又可以保证管理复杂度和通信开销的可控性。
免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://haidsoft.com/129444.html
