1、集群完整性

-》cluster-require-full-coverage默认为yes

集群中16384个槽全部可用：保证集群完整性

节点故障或者正在故障转移：（error）CLUSTERDOWN The cluster is down

-》大多数业务无法容忍，cluster-require-full-coverage建议设置为no

2、带宽消耗

-》官方建议：1000个节点

-》ping/pong消息

-》不容忽视的带宽消耗

--消息发送频率：节点发现其它节点最后通信时间超过cluster-node-timeout/2时会直接发送ping消息

--消息数据量：slots槽数组（2KB空间）和整个集群1/10的状态数据（10个节点状态数据约1KB）

--节点部署的机器规模：集群分布的机器越多且每台机器划分的节点数越均匀，则集群内整体的可用宽带越高

优化：

-》避免”大“集群：避免多业务使用一个集群，大业务可以多集群

-》cluster-node-timeout：带宽和故障转移速度的均衡

-》尽量均匀分配到多机器上：保证高可用和带宽

3、pub/sub广播

问题：publish在集群每个节点广播：加重带宽

解决：单独”走“一套redis sentinel

4、集群倾斜

数据倾斜：内存不均

-》节点和槽分配不均

redis-trib.rb info ip:port查看节点、槽、键值分布

redis-trib.rb rebalance ip:port进行均衡（谨慎使用）

-》不同槽对应键值数量差异较大

CRC16正常情况下比较均匀

可能存在hash_tag

cluster countkeysinslot{slot}获取槽对应键值个数

-》包含bigkey

bigkey：例如大字符串，几百万的元素的hash，set等

从几点：redis-cli --bigkeys

优化：优化数据结构

-》内存相关配置不一致

hash-max-zpilist-value、set-max-intset-entries等

优化：定期”检查“配置的一致性

请求倾斜：热点

热点key：重要的key或则bigkey

优化：避免bigkey

          热键不要用hash_tag

          当一致性不高时，可以用本地缓存+MQ

5、读写分离

只读连接：集群模式的从节点不接受任何读写请求。

-重定向到负责槽的主节点

-readonly命令可以读：连接级别命令

读写分离：更加复杂

-同样的问题：复制延迟、读取过期数据、从节点故障

-修改客户端：cluster slaves{nodeId}

在集群模式下不见使用读写分离

6、数据迁移

离线/在线迁移

官方迁移工具：redis-trib.rb import

--只能从单机迁移到集群

--不支持在线迁移：source需要听写

--不支持断点续传

--单线程迁移：影响速度

在线迁移：

-唯品会redis-migrete-tool

-豌豆荚：redis-port

7、集群vs单机

集群限制

--key批量操作支持有限：例如mget、mset必须在一个slot

--key事务和Lua支持有限：操作的key必须在一个节点

--key是数据分区的最小粒度：不支持bigkey分区

--不支持多个数据库：集群模式下只有一个db0

--复制只支持一层：不支持树形复制结构

分布式redis不一定是好的

-》1redis cluster：满足容量和性能的扩展性，很多业务”不需要“

大多数时客户端性能会”降低“

命令无法跨节点使用：mget、mset、scan、flush、sinter等

Lua和事务无法跨节点使用

客户端维护复杂：SDK和应用本身消耗（例如更多的连接池）

-》2很多场景redis sentinel已经足够好