redis优化

转自     https://mp.weixin.qq.com/s/tTtGN3hTQXAwuGNCDvwToQ

1）容量：Redis属于内存型存储，相较于磁盘存储型数据库，存储成本较昂贵，正是由于内存型存储这个特性使得它读写性能较高，但是存储空间有限。因此，业务在使用时，应注意存储内容尽量是热数据，并且容量是可预先评估的，最好设置过期时间。在存储设计时，合理使用对应数据结构，对于一些相对大的value，可以压缩后存储。

 

2）热key倾斜：Redis-Cluster把所有的物理节点映射到[0-16383]slot（槽）上，每个节点负责一部分slot。当有请求调用时，根据 CRC16(key) mod 16384的值，决定将key请求到哪个slot中。由于Redis-cluster这个特性，每个节点只负责一部分slot，因此，在设计key的时候应保证key的随机性，特别是使用一些hash算法映射key时，应保证hash值的随机分布。另外，控制热点key并发问题，可以采用限流降级或者本地缓存方式，防止热点key并发请求过高导致Redis热点倾斜。

 

3）集群过大：Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。每个节点都保存所有节点与slot映射关系。当节点较多时，每个节点保存的映射关系也会变多。各节点之间心跳包的消息体内携带的数据越多。在扩缩容时，集群重新进行clusterSlots时间相对较长。集群会存在阻塞风险，稳定性受影响。因此，在使用集群时，应该尽量避免集群节点过多，最后根据业务对集群进行拆分。

 

这里有个问题：为什么Redis-Cluster使用16384个slot，而不是更多，最多可以有多少个节点？

 

官方作者给出了解释，并且在解释中说明，Redis-Cluster不建议超过1000个主节点。

 

1）由于Redis集群模式，每个主节点只负责一部分slot，业务在设计Redis key时要充分考虑key的随机性，均匀分散在Redis各节点上，同时应避免大key出现。另外，业务上应避免Redis请求热点问题，同一时刻请求打到少部分节点。

2）Redis实际吞吐量还与请求Redis的包数据大小，网卡有关，官方文档有相关说明，单个包大小超过1000bytes时，性能会急剧下降。所以在使用Redis时应尽量避免大key。另外，最好根据实际业务场景和实际网络环境，带宽和网卡情况进行性能压测，对集群实际吞吐量做摸底。