redis集群与应用问题

redis集群的三种方式：

1、主从复制

主从复制即将master中的数据复制到slave中，一个master可以拥有多个slave，一个slave只对应一个master。master可执行读写操作执行写操作时将变化的数据同步到slave。salve只能读取数据。

主从复制流程：
      Redis从服务器连接主服务器，发送SYNC命令,主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的写操作命令。
     主服务器BGSAVE执行完后，向所有从服务器发送快照文件， 从服务器收到快照文件后丢弃所有旧数据，加载收到的快照。
     主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令。
     从服务器完成对快照的加载后，开始接收命令请求，并执行来自主服务器缓冲区的写命令。

主从复制优点：
     读写分离master写、slave读，数据冗余实现数据备份提高数据安全性，由slave分担master的读提高Redis服务器并发量与数据吞吐量。
缺点：
     主从分离不能提高并发写能力，当master宕机后不能实现自动故障恢复(可以手动执行slave no one 将主机变成从机)。

2、哨兵

Sentinel(哨兵)是用于监控Redis集群中Master的状态，是Redis高可用解决方案，哨兵可以监视一个或者多个master服务，以及这些master服务的所有从服务。 当某个master服务宕机后，会把这个master下的某个从服务升级为master来替代已宕机的master继续工作。

1、心跳机制：
      1）Sentinel 会从主节点上获取所有从节点的信息，之后 Sentinel 会定时向主节点和从节点发送 info 命令获取其拓扑结构和状态信息。 
      2）每个 Sentinel 节点会向主节点的 sentinel 的 hello 频道上发送该 Sentinel 节点对于主节点的判断以及当前 Sentinel 节点的信息 ，同时每个 Sentinel 节点也会订阅该频道， 来获取其他 Sentinel 节点的信息以及它们对主节点的判断。
      3）这样所有的 Sentinel 节点 与所有的 Redis 节点之间都已经彼此感知到，之后每个 Sentinel 节点会向主节点、从节点、以及其余 Sentinel 节点定时发送 ping 命令作为心跳检测， 来确认这些节点是否可达。

2、判断master节点是否下线：
       1）每个 sentinel 哨兵节点每隔1s 向所有的master、slave以及其他 sentinel 节点发送一个PING命令，如果 master 节点回复 PING 命令的时间超时，则这个 master 会被 sentinel 标记为主观下线，修改其 flags 状态为SRI_S_DOWN。
       2）当sentinel 哨兵节点将 master 标记为主观下线后，会向其余所有的 sentinel 发送消息，询问其他sentinel是否同意该master下线。
       3）其余sentinel收到命令之后，会根据发送过来的 ip和port 检查自己判断的结果，回复自己认为该master节点是否下线，sentinel收到回复之后，如果同意master节点进入主观下线的sentinel数量大于等于quorum，则master会被标记为客观下线，即认为该节点已经不可用。

3、基于Raft算法选举领头sentinel：
   当 master客观下线后，就需要选举一个sentinel来负责故障转移，过程如下：
   1）判断客观下线的sentinel节点向其他 sentinel 节点发送 一个自己的runid
   2）目标sentinel回复是否同意master下线并选举sentinel，选择sentinel的过程符合先到先得的原则。列如：sentinel1判断了客观下线，向sentinel2发送了第一步中的命令，sentinel2回复了sentinel1 选你完成故障恢复，这时候sentinel3也向sentinel2发送第一步的命令则sentinel2会直接拒绝
   3）当sentinel发现选自己的节点个数超过 majority 的个数的时候，自己负责当次故障恢复
   4）如果没有一个sentinel达到了majority的数量，等一段时间，重新选举

4、故障恢复：
    1）配置的优先级越高的额slave节点优先选为master。
    2)  偏移量越大的优先选为master（偏移量越大意味着同步的数据约多）。
    3）runid越小优先选为master。(redis启动后会随机生成一个40位的runid)。

3、cluster

    Redis集群是一个由多个主从节点群组成的分布式服务集群，具有复制、高可用和分片特性。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展。主要是针对海量数据、高并发、高可用的场景。

1）slot（槽）
      Redis Cluster中有一个16384长度的槽的概念，槽是一个虚拟的槽，并不是真正存在的。Redis Cluster中的每个Master节点都会负责一部分的槽，当有某个key被映射到某个Master负责的槽，那么这个Master负责为这个key提供服务，至于哪个Master节点负责哪个槽，这是可以由用户指定也可以经过CRC16哈希到一个指定的Slot上，集群客户端连接集群中任一Redis 实例 即可发送命令，当Redis 实例 收到自己不负责的Slot的请求时，会回复MOVED重定向错误（该错误信息会包含正确的节点槽、ip、端口等信息），通知客户端请求正确的节点。

2）master 选举
选新主的过程基于Raft协议选举方式来实现的
     1、当从节点发现自己的主节点进行已下线状态时，从节点会广播一条。CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST消息，要求收到这条消息并且具有投票权的主节点向这个从节点投。
     2、如果一个主节点具有投票权，并且这个主节点尚未投票给其他从节点，那么这个主节点将向要求投票的从节点返回一条CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，表示支持这个从节点成为新的主节点。
     3、每个参与选举的从节点会根据自己收到的支持消息条数 来统计自己的获选票数。
     4、如果集群里有N个具有投票权的主节点，那么当一个从节点收集到大于等于集群N/2+1张选票时这个从节点就成为新的主节点。
    5、如果没有从节点能够收集到足够的支持票数，那么集群进入一个新一轮选举，直到选出新的主节点为止。

redis应用问题之缓存穿透、缓存击穿、缓存雪崩：

1、缓存穿透

    客户端恶意访问出现很多非正常的key redis和数据库中都不存在的数据，造成大量请求转向数据库给数据库造成巨大压力同时也是去缓存的意义。
   解决方案：
   1）对空值做缓存 不管数据是否存在仍然把这个结果进行缓存并设置过期时间。优点：实现简单。缺点：若有人恶意访问(比如使用uuid访问) 那么会出现大量无意义的占用大量内存。
   2）布隆过滤器，使用 bitmaps + 不同的hash算法  给key算出几个hash值  用该值作为 bitmaps 下标并将该下标的value设置为1。当有key请求时用同样的算法 算出该key的hash值 若该hash对应的bitmaps下标中有值则表示数据存在。优点：判断相对准确、占用内存小。缺点：存在误判可能，实现相对复杂，若有key删除需要更新布隆过滤器。

2、缓存击穿   

     redis中的某个key过期后，出现大流量访问这个key，因瞬时访问过大造成大量的请求访问数据库给数据库造成巨大压力甚至宕机。
    解决方案：
    1）大流量key预估，将其预先放入redis中并设置合适的过期时间。
    2）实时调整，监控热门数据实时调整设置key的过期时间。
    3）使用锁机制，当查询不到key值时  对访问库的代码进行加锁保证只有少量请求访问数据。

3、缓存雪崩

 

   大量key集中过期，大量请求访问数据库给数据库造成巨大压力甚至宕机。
   解决方案：
   1）使用多级缓存 ：nginx缓存+应用缓存(ehcache)+redis缓存。
   2）缓存失效时间分散开（随机时间缓存）