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

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，该命令只能将数据从单机节点迁移到集群中，并且不支持在线迁移（也就是源节点一边写入数据一边进行迁移数据），不支持断点续传（也就是没法从上一次迁移中断的地方继续迁移）