Redis项目实战（二）---Redis集群原理

一、 Redis官方推荐集群方案：Redis Cluster

      注：适用于redis3.0以后版本（官方集群版本），3.0之前采用主从方案（即哨兵机制）作为高可用方案，哨兵机制具备主从切换、自动选主、监控等功能，主从节点之间进行数据同步，保持一致，缺点是每个节点存储数据一样，浪费内存空间。

      redis cluster 是redis官方提供的分布式解决方案，在3.0版本后推出的，有效地解决了redis分布式的需求，当一个redis节点挂了可以快速的切换到另一个节点，同时实现了数据的分布式存储（每个节点上存储不同的内容，方便扩容）。

　  简介：

          1）设计上使用了去中心化，去中间件，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。

          2）哈希槽设计，使用哈希槽 (hash slot)的方式来分配数据，redis cluster 默认分配了 16384 个slot，每set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，即：CRC16(key) % 16384。

• 优点：去中心化，无中心节点

　　　（1）数据按照 slot 存储分布在多个 Redis 实例上，能够平滑的进行扩容/缩容节点；由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。

         （2）自动故障转移(节点之间通过 Gossip 协议交换状态信息，进行投票机制完成 Slave 到 Master 角色的提升)，提高了系统的可扩展性和高可用性。

• 缺点：严重依赖外部 Redis-Trib，缺乏监控管理；需要依赖 Smart Client(连接维护, 缓存路由表, MultiOp 和 Pipeline 支持)；Failover 节点的检测过慢，不如“中心节点 ZooKeeper”及时；Gossip 消息的开销；无法根据统计区分冷热数据；Slave“冷备”，不能缓解读压力。      

　架构细节：

　　(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽；

　　(2)节点的fail是通过集群中超过半数的节点检测失效时才生效；

　　(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可，

　　(4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value.

 

   redis-cluster选举（容错）机制：

　　(1) leader选举过程是，集群中所有master参与，若半数以上master节点与master节点通信超时(cluster-node-timeout)，则认为当前master节点挂掉.

　　(2)整个集群不可用(cluster_state:fail)的条件（集群不可用时,所有对集群的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)错误），

    　　a：集群中任意master挂掉，且当前master没有slave，集群进入fail状态；

    　　b：集群中超过半数以上master挂掉，无论是否有slave，集群进入fail状态。

 　　　　

 

      相关原理分析：

      分布式基础---Redis集群数据分片

·　　Redis Cluster没有使用一致性散列，而是使用不同形式的分片slot，其中每个键称之为 hash slot.。

　　 Redis集群中有16384个散列槽，为了计算给定密钥的散列槽，采用密钥模数16384的CRC16。

　　 Redis群集中的每个节点都负责哈希槽的子集，例如，拥有一个包含3个节点的集群，则：

•  节点A包含从0到5500的散列槽。

•  节点B包含从5501到11000的散列槽。

•  节点C包含从11001到16383的散列槽。

　　（1）此特点可轻松添加和删除集群中的节点。例如，要添加一个新节点D，则将一些哈希槽从节点A，B，C移动到D即可。同样，如果想从集群中删除节点A，只需移动A服务的哈希槽到B和C。当节点A为空时，就可以完全从集群中删除它。

       （2）因为将哈希槽添加和删除节点、从一个节点移动到另一个节点、或者更改节点所持有的哈希槽的百分比，不需要停止操作，所以不需要任何停机时间。

       （3）只要涉及单个命令执行（整个事务或Lua脚本执行）的所有键都属于同一个哈希槽，Redis Cluster就支持多个键操作。可利用此分片的特点在集群操作中进行pipline和keys等相关操作。

　　高可用基础---Redis Cluster主备模型

        为在主节点子集发生故障或无法与大多数节点通信时保持可用，Redis Cluster使用主从模型，其中每个散列槽从1（主机本身）到N个副本（N） -1个额外的从节点）。创建集群时，每个主节点添加一个从节点，以便最终集群由作为主节点的A，B，C 和作为从节点的A1，B1，C1组成。如果节点B出现故障，系统就能继续运行。节点B1复制B，B失败，集群将节点B1升级为新的主节点，并将继续正常运行。

         注意，如果节点B和B1同时发生故障，Redis Cluster将无法继续运行。

        备注：非主从模式，Redis Cluster集群方案采用的是去中心化的方式，所有节点皆为主节点Master，从节点指的是备份节点，保证高可用。若其一物理节点主节点挂掉的情况下，会启动从节点提供服务，若主从同时关掉，则集群不再提供服务。

　　Redis集群一致性保证

　　Redis Cluster无法保证强一致性。在某些条件下，Redis Cluster可能会丢失系统向客户端确认的写入。

　　Redis Cluster可能丢失写入的第一个原因是它使用异步复制。即在写入期间会发生以下情况：

• 客户端写入master B.

• master B向客户端回复确定。

• master B将写入传播到其从设备B1，B2和B3。

　　（1）B在回复客户端之前并没有等待来自B1，B2，B3的确认，因为这对Redis来说是一个过高的延迟，所以如果客户端写了一些东西，B会确认写入，但是在崩溃之前能够将写入发送到其slave，其中一个slave（没有接收到写入）被提升为master ，永远丢失写入。

　　这和大多数数据库配置为每秒将数据刷新到磁盘的所发生的情况非常相似。同样，可以通过在回复客户端之前强制数据库刷新磁盘上的数据来提高一致性，但会导致性能过低。在Redis Cluster中，相当于使用同步复制。

       解决办法，需要在性能和一致性之间进行权衡。

      Redis Cluster在绝对需要时支持同步写入，通过WAIT命令实现，使得丢失写入的可能性大大降低，但即使使用同步复制，Redis Cluster也不会实现强一致性：在更复杂的情况下总是可以实现失败场景，无法接收写入的slave被选为master。

      （2）还有另一个值得注意的情况是，网络分区中，其中客户端与少数实例（至少包括主服务器）隔离，Redis集群会丢失写入数据。如，

　　以6个节点簇为例，包括A，B，C，A1，B1，C1，3个主站和3个从站。还有一个client，我们称之为Z1。在发生分区之后，可能在分区的一侧有A，C，A1，B1，C1，在另一侧有B和Z1。Z1仍然可以写入B，它将接受其写入。如果分区在很短的时间内恢复，集群将继续正常运行。但是，如果分区持续足够的时间使B1在分区的多数侧被提升为主，则Z1发送给B的写入将丢失。

　　注意，Z1将能够发送到B的写入量存在maximum window：如果分区的多数方面已经有足够的时间将slave选为master，则少数端的每个主节点都会停止接受写入。这段时间是Redis Cluster的一个非常重要的配置指令，称为节点超时。节点超时过后，master被视为失败，可以由其中一个副本替换。类似地，在节点超时已经过去而主节点无法感知大多数其他主节点之后，它进入错误状态并停止接受写入。

　　Redis集群重新分片

　　执行重新分片的过程中， 让 example.rb 程序处于运行状态， 这样就会看到， 重新分片并不会对正在运行的集群程序产生任何影响， 重新分片操作基本上就是将某些节点上的哈希槽移动到另外一些节点上面， 也可以使用 redis-trib 程序来执行，执行以下命令可以开始一次重新分片操作：

./redis-trib.rb reshard 127.0.0.1:7000

（1）只需要指定集群中其中一个节点的地址， redis-trib 就会自动找到集群中的其他节点。

（2）目前 redis-trib 只能在管理员的协助下完成重新分片，要让 redis-trib 自动将哈希槽从一个节点移动到另一个节点， 目前来说还做不到。

（3）在重新分片结束后通过如下命令检查集群状态：

./redis-trib.rb check 127.0.0.1:7000

　Redis集群扩缩容

 　

扩容原理：
　　1、redis cluster可以实现对节点的灵活上下线控制
　　2、3个主节点分别维护自己负责的槽和对应的数据，如果希望加入一个节点实现扩容，就需要把一部分槽和数据迁移和新节点
　　3、每个master把一部分槽和数据迁移到新的节点node04

  新节点刚开始都是master节点，但是由于没有负责的槽，所以不能接收任何读写操作，对新节点的后续操作，一般有两种选择：
　　1、从其他的节点迁移槽和数据给新节点
　　2、作为其他节点的slave负责故障转移

  slot迁移说明：
　　1、迁移过程是同步的，在目标节点执行restore指令到原节点删除key之间，原节点的主线程处于阻塞状态，直到key被删除成功
　　2、如果迁移过程突然出现网路故障，整个slot迁移只进行了一半，这时两个节点仍然会被标记为中间过滤状态，即"migrating"和"importing"，下次迁移工具连接上之后，会继续进行迁移
　　3、在迁移过程中，如果每个key的内容都很小，那么迁移过程很快，不会影响到客户端的正常访问
　　4、如果key的内容很大，由于迁移一个key的迁移过程是阻塞的，就会同时导致原节点和目标节点的卡顿，影响集群的稳定性，所以，集群环境下，业务逻辑要尽可能的避免大key的产生

缩容原理：
　　1、如果下线的是slave，那么通知其他节点忘记下线的节点
　　2、如果下线的是master，那么将此master的slot迁移到其他master之后，通知其他节点忘记此master节点
　　3、其他节点都忘记了下线的节点之后，此节点就可以正常停止服务了

二、扩展：

 

    Redis3.0之前的使用集群方案相关概念:

   （1）哨兵（Sentinel ）机制

     Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

    Redis哨兵机制运行流程：

   1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 

   2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被Sentinel 标记为主观下线。 

   3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 

   4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 

   5)：在一般情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 

   6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从10秒一次改为每秒一次 

   7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master的客观下线状态就会被移除。 若Master重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

 

     （2）Redis主从读写分离

          1）主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性。

　　　2）负载均衡：当Master宕机后，通过选举算法从slave中选举出新Master继续对外提供服务，主机恢复后以slave的身份重新加入，从节点通过负载均衡提供取服务。

     备注：主从复制和哨兵机制需要进行手动配置，使用zookeeper作为监控中心；3.0以后的版本去中心化，不再需要zookeeper提供监控服务。

     

 

三、Redis作为缓存应用问题及解决方案：

     1）缓存穿透

      缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。

         解决办法：

1. 对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。还有最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
2. 也可以采用一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

     2）缓存雪崩

    如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，造成了缓存雪崩。

         解决办法：

1. 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
2. 可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存
3. 不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀. 比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件
4. 做二级缓存，或者双缓存策略。A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。

     3）缓存击穿

   缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。

     4）缓存预热

  缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

        缓存预热解决方案：

1. 直接写个缓存刷新页面，上线时手工操作下；
2. 数据量不大，可以在项目启动的时候自动进行加载；
3. 定时刷新缓存；

     5）缓存更新

  我们知道通过expire来设置key 的过期时间,那么对过期的数据怎么处理呢?除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

1. 定时去清理过期的缓存；
2. 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

  两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

     6）缓存降级

  当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。 降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。   在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

1. 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
2. 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
3. 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
4. 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

四、redis作为分布式锁方案（性能最优）

        分布式锁是控制分布式系统之间同步访问共享资源的一种方式。

         实现思路：

1. 使用SETNX命令获取锁，若不存在则设置值，设置成功则表示取得锁成功；
2. 设置expire，保证超时后能自动释放锁（使用lua脚本将setnx和expire变成一个原子操作）；
3. 释放锁，使用DEL命令将锁数据删除。

        或使用Redis官方推荐的redission

五、两个redis之间同步数据工具

　　一个 Redis 需要从另一个 Redis 数据同步 或者 数据迁移，全量数据迁移一般比较好做，可以直接从源redis导出rdb，再把rdb文件导入目标redis。但是如果需要实时增量同步就比较困难，可用使用阿里云开源 redis-shake 工具。

 

 借鉴了不少文章，感谢各路大佬分享，转载请注明出处，谢谢：https://www.cnblogs.com/huyangshu-fs/p/11256007.html 

 另偶尔看到一位同胞使用图文的形式直观展示了原理部分，现附上链接，共同进步：https://www.jianshu.com/p/6e2a50b0f835