Redis应用学习——Redis Cluster运维常见问题

2019独角兽企业重金招聘Python工程师标准>>>

1. 集群完整性

    1. 在每个节点的配置文件中有一个配置参数cluster-require-full-coverage，默认值为yes，该参数就表示是否要保证集群中16384个槽位全部可用时，该集群才会提供服务，即要保证集群的完整性；参数值设置为yes，则如果某个持有槽位的节点发生故障或者正在故障转移，客户端执行key命令时就会返回客户端一个error错误，提示该集群已下线停止服务，所以一般来说，在实际应用中是无法容忍参数值为yes，一般都会设置为no

2. 带宽消耗

    1. Redis Cluster中的节点数量不超过1000个（官方建议），因为每个节点之间都会定时进行一些信息交换（比如节点状态监测、进行ping/pong操作等），当节点数量扩大时，就会带来不容忽视的带宽消耗，影响带宽消耗主要在下列三个方面：

（1）消息发送频率：节点发现与其他节点的最后一次通信时间超过cluster-node-timeout/2时，会向其他节点发送ping命令

（2）消息数据量：比如会接收slot槽位数组和整个集群的状态数据

（3）节点部署的机器规模：集群部署的机器规模越大，且每台机器的节点部署的越均匀，则集群整体可用宽带会提高

    2. 优化方法：

（1）避免多个业务使用一个集群，大业务可以使用多个集群

（2）尽量将节点均匀部署到多台机器中

（3）合理配置参数cluster-node-timeout

3. pub/sub广播

    1. 发布订阅在集群中的影响：当通过某个节点的客户端发布一条消息，那么该节点会自动向集群中的其他节点发布消息，无论其他节点是否订阅了该节点发布消息的频道，这就导致带宽消耗。可以单独写一套Redis Sentinel来解决

4. 集群倾斜

    1. 数据倾斜：简单来说就是槽位或者说节点之间的数据量差异较大，通常由以下四个原因造成

（1）节点与槽位的分配不均匀，可以通过 redis-trib.rb info ip:port，该命令来查看集群所有主节点的节点、槽位与键值的分布

（2）各个槽位中的数据量差异大，在前面说过可以通过在key之前添加一个hash_tag可以保证批量命令的执行可以在同一个节点上，这就会导致数据倾斜

（3）包含bigkey，即key所对应的value数据量极大，比如大字符串，具有大量元素的list、set等类型的数据，这时就需要优化数据结构

（4）内存相关配置不一致

    2. 请求倾斜：也就是热点key问题，某个key是一个极高访问频率的key，或者该key是一个bigkey

5. 读写分离

    1. 集群模式的从节点不接受任何读写请求，某个客户端连接到从节点进行读写操作时会重定向到其主节点上进行读写操作，而通过一个readonly命令就可以使从节点实现，在连接到从节点的客户端上进行读操作时必须先执行命令readonly，然后才能进行读操作

    2. 集群模式中实现读写分离面临的问题与Redis Sentinel中相同，但是集群中实现读写分离更为复杂，所以不建议实现读写分离，通常是在集群中部署多个节点来减轻读写压力

6. 数据迁移

    1. 通过官方集群管理工具redis-trib.rb将单机节点的数据迁移到集群中：命令为 redis-trib.rb  import  host:port   --from <arg>，host与port参数写集群中的一个节点的IP地址与端口，而arg参数则要写单机节点的IP地址与端口，形式也是host:port，该命令只能将数据从单机节点迁移到集群中，而且不支持在线迁移（也就是源节点一边写入数据一边进行迁移数据），不支持断点续传（也就是无法从上一次迁移中断的地方继续迁移）

转载于:https://my.oschina.net/ProgramerLife/blog/2874534