带宽优化：
避免使用'大'集群：避免多业务使用一个集群，大业务可以多集群 cluster-node-timeout:带宽和故障转移速度的均衡 尽量均匀分配到多机器上：保证高可用和带宽 5.3 Pub/Sub广播在任意一个cluster节点执行publish，则发布的消息会在集群中传播，集群中的其他节点都会订阅到消息，这样节点的带宽的开销会很大
publish在集群每个节点广播，加重带宽
解决办法：需要使用Pub/Sub时，为了保证高可用，可以单独开启一套Redis Sentinel
5.4 集群倾斜对于分布式数据库来说，存在倾斜问题是比较常见的
集群倾斜也就是各个节点使用的内存不一致
5.4.1 数据倾斜原因1.节点和槽分配不均，如果使用redis-trib.rb工具构建集群，则出现这种情况的机会不多
redis-trib.rb info ip:port查看节点，槽，键值分布 redis-trib.rb rebalance ip:port进行均衡(谨慎使用)2.不同槽对应键值数量差异比较大
CRC16算法正常情况下比较均匀 可能存在hash_tag cluster countkeysinslot {slot}获取槽对应键值个数3.包含bigkey：例如大字符串，几百万的元素的hash,set等
在从节点：redis-cli --bigkeys 优化：优化数据结构4.内存相关配置不一致
hash-max-ziplist-value：满足一定条件情况下，hash可以使用ziplist set-max-intset-entries：满足一定条件情况下，set可以使用intset 在一个集群内有若干个节点，当其中一些节点配置上面两项优化，另外一部分节点没有配置上面两项优化 当集群中保存hash或者set时，就会造成节点数据不均匀 优化：定期检查配置一致性5.请求倾斜：热点key
重要的key或者bigkey Redis Cluster某个节点有一个非常重要的key，就会存在热点问题 5.4.2 集群倾斜优化： 避免bigkey 热键不要用hash_tag 当一致性不高时，可以用本地缓存+ MQ(消息队列) 5.5 集群读写分离只读连接：集群模式下，从节点不接受任何读写请求
当向从节点执行读请求时，重定向到负责槽的主节点
readonly命令可以读：连接级别命令，当连接断开之后，需要再次执行readonly命令
读写分离：
同样的问题：复制延迟，读取过期数据，从节点故障 修改客户端：cluster slaves {nodeId} 5.6 数据迁移官方迁移工具：redis-trib.rb和import
只能从单机迁移到集群
不支持在线迁移：source需要停写
不支持断点续传
单线程迁移：影响深度
在线迁移：
唯品会：redis-migrate-tool 豌豆荚：redis-port 5.7 集群VS单机集群的限制:
key批量操作支持有限：例如mget,mset必须在一个slot key事务和Lua支持有限：操作的key必须在一个节点 key是数据分区的最小粒度：不支持bigkey分区 不支持多个数据库：集群模式下只有一个db0 复制只支持一层：不支持树形复制结构 Redis Cluster满足容量和性能的扩展性，很多业务'不需要' 大多数时客户端性能会'降低' 命令无法跨节点使用：mget,keys,scan,flush,sinter等 Lua和事务无法跨节点使用 客户端维护更复杂：SDK和应用本身消耗(例如更多的连接池)很多场景Redis Sentinel已经够用了
6.Redis Cluster总结： 1.Redis Cluster数据分区规则采用虚拟槽方式(16384个槽)，每个节点负责一部分槽和相关数据，实现数据和请求的负载均衡 2.搭建Redis Cluster划分四个步骤：准备节点，meet操作，分配槽，复制数据。 3.Redis官方推荐使用redis-trib.rb工具快速搭建Redis Cluster 4.集群伸缩通过在节点之间移动槽和相关数据实现 扩容时根据槽迁移计划把槽从源节点迁移到新节点 收缩时如果下线的节点有负责的槽需要迁移到其他节点，再通过cluster forget命令让集群内所有节点忘记被下线节点 5.使用smart客户端操作集群过到通信效率最大化，客户端内部负责计算维护键，槽以及节点的映射，用于快速定位到目标节点 6.集群自动故障转移过程分为故障发现和节点恢复。节点下线分为主观下线和客观下线，当超过半数节点认为故障节点为主观下线时，标记这个节点为客观下线状态。从节点负责对客观下线的主节点触发故障恢复流程，保证集群的可用性 7.开发运维常见问题包括：超大规模集群带席消耗，pub/sub广播问题，集群倾斜问题，单机和集群对比等