【Redis官方解答】为啥Redis Cluster设计成16384个槽?
2023-04-18 13:06:56 时间
消息大小考虑
crc16()一共可以有:
2^16 -1=65535
不同的余数,代表bitmap 有 65535 bit。所以bitmap的大小可以计算为
65535 / 8 (8bit/byte)/1024(1k)=7.99 Kbytes
尽管crc16能得到65535个值,但redis选择16384个slot,是因为16384的消息只占用了2k,而65535则需要8k。
正常的心跳包携带节点的完整配置,可以以幂等方式替换旧配置以更新旧配置。这意味着它们包含原始形式的节点的插槽配置,该节点使用2K的空间和16384个slot,但使用65535的插槽会使用令人望而却步的 8K 的空间。
65k = 8 * 8 (8 bit/byte) * 1024(1k) = 8K bitmap size
为什么要传全量的slot状态?
因为分布式场景,基于状态的设计更合理,状态的传播具有幂等性。
集群规模设计考虑
同时,由于其他设计权衡,Redis Cluster 不太可能扩展到超过 1000 个主节点。集群设计最多支持1000个分片,16384是相对比较好的选择,需要保证在最大集群规模下,slot均匀分布场景下,每个分片平均分到的slot不至于太小。 所以16384是在正确的范围内,以确保每个 master 有足够的插槽,最多 1000 个 maters,但这个数量足够小,可以轻松地将插槽配置作为原始位图传播。
在小集群中,位图将难以压缩,因为当 N 小时,位图将设置的槽位/N 位占很大比例的位。
为什么不考虑压缩?
集群规模较小的场景下,每个分片负责大量的slot,很难压缩。
简而言之,它是消息大小和主机持有的平均slot数之间权衡的结果。
参考
- https://github.com/redis/redis/issues/2576
相关文章
- 直接在代码里面对list集合进行分页
- .NET Framework 4.5新特性详解
- 大数据的简要介绍
- 大数据的由来
- 高斯混合模型的自然梯度变量推理
- timing-wheel 仿Kafka实现的时间轮算法
- 使用Navicat软件连接自建数据库(Linux系统)
- 那一天,我被Redis主从架构支配的恐惧
- Redis 深入了解键的过期时间
- C#使用委托调用实现用户端等待闪屏
- 基于流计算 Oceanus 和 Elasticsearch Service 构建百亿级实时监控系统
- GRAND | 转录调控网络预测数据库
- JFreeChart API中文文档
- 临床相关突变查询数据库
- TIGER | 人类胰岛基因变化查询数据库
- 视频边缘计算网关EasyNVR在视频整体监控解决方案中的应用分析
- Apache Arrow - 大数据在数据湖后的下一个风向标
- 常见的电商数据指标体系
- AKShare-艺人数据-艺人流量价值
- MySQL中多表联合查询与子查询的这些区别,你可能不知道!