Redis高可用

单机或主从 8wQPS
集群: 千万级QPS
分布式 千万级QPS

来看 Redis 的高可用。Redis 支持主从同步，提供 Cluster 集群部署模式，通过 Sentine l哨兵来监控 Redis 主服务器的状态。当主挂掉时，在从节点中根据一定策略选出新主，并调整其他从 slaveof 到新主。

  • 集群架构 可轻松突破Redis自身单线程瓶颈，满足大容量、高性能的业务需求。
  • 主从架构 ，提供高性能的缓存服务和数据高可靠。
  • 读写分离架构 提供高可用、高性能、高灵活的读写分离服务，解决热点数据集中及高并发读取的业务需求，最大化地节约用户运维成本。

1. Reids主从复制

复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。
复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。
缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。

使用异步复制(asynchronous replication)是Redis集群可能会丢失写命令的其中一个原因，有时候由于网络原因，如果网络断开时间太长，redis集群就会启用新的主节点，之前发给主节点的数据聚会丢失。

你启动一台slave 的时候，他会发送一个psync命令给master ，如果是这个slave第一次连接到master，他会触发一个全量复制。master就会启动一个线程，生成RDB快照，还会把新的写请求都缓存在内存中，RDB文件生成后，master会将这个RDB发送给slave的，slave拿到之后做的第一件事情就是写进本地的磁盘，然后加载进内存，然后master会把内存里面缓存的那些新命名都发给slave。

2. Redis哨兵

Redis Sentinal着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。
在复制的基础上，哨兵实现了自动化的故障恢复。

缺陷：写操作无法负载均衡；存储能力受到单机的限制。

(https://redis.io/topics/sentinel)是怎么样的。

  1. Sentinel 集群通过给定的配置文件发现 master，启动时会监控 master。通过向 master 发送 info 信息获得该服务器下面的所有从服务器。
  2. Sentinel 集群通过命令连接向被监视的主从服务器发送 hello 信息 (每秒一次)，该信息包括 Sentinel 本身的 IP、端口、id 等内容，以此来向其他 Sentinel 宣告自己的存在。
  3. Sentinel 集群通过订阅连接接收其他 Sentinel 发送的 hello 信息，以此来发现监视同一个主服务器的其他 Sentinel；集群之间会互相创建命令连接用于通信，因为已经有主从服务器作为发送和接收 hello 信息的中介，Sentinel 之间不会创建订阅连接。
  4. Sentinel 集群使用 ping 命令来检测实例的状态，如果在指定的时间内（down-after-milliseconds）没有回复或则返回错误的回复，那么该实例被判为下线。
  5. 当 failover 主备切换被触发后，failover 并不会马上进行，还需要 Sentinel 中的大多数 Sentinel 授权后才可以进行 failover，即进行 failover 的 Sentinel 会去获得指定 quorum 个的 Sentinel 的授权，成功后进入 ODOWN 状态。如在 5 个 Sentinel 中配置了 2 个 quorum，等到 2 个 Sentinel 认为 master 死了就执行 failover。
  6. Sentinel 向选为 master 的 slave 发送 SLAVEOF NO ONE 命令，选择 slave 的条件是 Sentinel 首先会根据 slaves 的优先级来进行排序，优先级越小排名越靠前。如果优先级相同，则查看复制的下标，哪个从 master 接收的复制数据多，哪个就靠前。如果优先级和下标都相同，就选择进程 ID 较小的。
  7. Sentinel 被授权后，它将会获得宕掉的 master 的一份最新配置版本号 (config-epoch)，当 failover 执行结束以后，这个版本号将会被用于最新的配置，通过广播形式通知其它 Sentinel，其它的 Sentinel 则更新对应 master 的配置。

1 到 3 是自动发现机制:

  • 以 10 秒一次的频率，向被监视的 master 发送 info 命令，根据回复获取 master 当前信息。
  • 以 1 秒一次的频率，向所有 redis 服务器、包含 Sentinel 在内发送 PING 命令，通过回复判断服务器是否在线。
  • 以 2 秒一次的频率，通过向所有被监视的 master，slave 服务器发送当前 Sentinel master 信息的消息。

4 是检测机制，5 和 6 是 failover 机制，7 是更新配置机制。

3. 集群

集群架构的本地盘实例默认采用代理（proxy）模式 ，支持通过一个统一的连接地址（域名）访问Redis集群，客户端的请求通过代理服务器转发到各数据分片，代理服务器、数据分片和配置服务器均不提供单独的连接地址，降低了应用开发难度和代码复杂度。

原理

高可用架构 - 图1

Redis集群是一个分布式Redis存储架构，可以在多个节点之间进行数据共享，解决Redis高可用、可扩展等问题。Redis集群提供了一下两个好处
1.将数据自动切分(split)到多个节点
2.当集群中的某一个节点故障时，redis还可继续处理客户端的请求

一个Redis集群包含16384个哈希槽(hash slot)，数据库中的每个数据都属于这16384个哈希槽中的一个。集群使用公事CRC16(key)%16384来计算key属于哪一个槽。集群中的每一个节点负责处理一部分哈希槽。

集群中的每个节点都有1个到N个复制品，其中一个为主节点，其余为从节点，如果主节点下线了，集群就会把这个主节点的一个从节点设置为新的主节点，继续工作。这个集群就不会因为一个主节点的下线而无法正常工作。
如果某一个主节点和它所有的从节点都下线的话，redis集群就停止工作了。
Redis集群不保证数据的强一致性，在特定的情况下，redis集群会丢失已经执行过的命令。

配置文件

cluster-enable yes
配置Master-Slave，只需要在slave上配置master节点ip port就可以
#slaveof
修改redis.conf，在最后一行添加
slaveof master 6379
另外需要注意一下slave-read-only 必须要为yes，这表示slave只读不写，这也是redis的推荐配置。

什么是redis的集群脑裂

集群的脑裂通常是发生在集群中部分节点之间不可达而引起的（或者因为节点请求压力较大，导致其他节点与该节点的心跳检测不可用）。当上述情况发生时，不同分裂的小集群会自主的选择出master节点，造成原本的集群会同时存在多个master节点。

image.png

集群脑裂问题中，如果客户端还在基于原来的master节点继续写入数据，那么新的master节点将无法同步这些数据，当网络问题解决之后，sentinel集群将原先的master节点降为slave节点，此时再从新的master中同步数据，将会造成大量的数据丢失。
解决

  1. min-replicas-to-write 3
  2. min-replicas-max-lag 10

第一个参数表示连接到master的最少slave数量
第二个参数表示slave连接到master的最大延迟时间
按照上面的配置，要求至少3个slave节点，且数据复制和同步的延迟不能超过10秒，否则的话master就会拒绝写请求，配置了这两个参数之后，如果发生集群脑裂，原先的master节点接收到客户端的写入请求会拒绝，就可以减少数据同步之后的数据丢失。
「霁云HYY」原文链接：https://blog.csdn.net/LO_YUN/java/article/details/97131426

选主策略

选主的策略简单来说有三个：

  • slave 的 priority 设置的越低，优先级越高；
  • 同等情况下，slave 复制的数据越多优先级越高；
  • 相同的条件下 runid 越小越容易被选中。

读写分离的问题

1.数据复制的延迟
读写分离时，master会异步的将数据复制到slave，如果这是slave发生阻塞，则会延迟master数据的写命令，造成数据不一致的情况

解决方法：可以对slave的偏移量值进行监控，如果发现某台slave的偏移量有问题，则将数据读取操作切换到master，但本身这个监控开销比较高，所以关于这个问题，大部分的情况是可以直接使用而不去考虑的。

2.读到过期的数据

产生原因：

redis的从库是无法主动的删除已经过期的key的，所以如果做了读写分离，就很有可能在从库读到脏数据
1）通过ttl判断
2）升级到reidis3.2

主从配置不一致

这个问题一般很少见，但如果有，就会发生很多诡异的问题
例如：
1. maxmemory配置不一致：这个会导致数据的丢失
原因：例如master配置4G，slave配置2G，这个时候主从复制可以成功，但，如果在进行某一次全量复制的时候，slave拿到master的RDB加载数据时发现自身的2G内存不够用，这时就会触发slave的maxmemory策略，将数据进行淘汰。更可怕的是，在高可用的集群环境下，如果我们将这台slave升级成master的时候，就会发现数据已经丢失了。

2. 数据结构优化参数不一致（例如hash-max-ziplist-entries）：这个就会导致内存不一致
原因：例如在master上对这个参数进行了优化，而在slave没有配置，就会造成主从节点内存不一致的诡异问题。

实际部署

redis cluster，10 台机器，5 台机器部署了 redis 主实例，另外 5 台机器部署了 redis 的从实例， 每个主实例挂了一个从实例，5 个节点对外提供读写服务，每个节点的读写高峰 qps 可能可以达到每秒 5 万，5 台机器最多是 25 万读写请求/s。

机器是什么配置？

32G 内存+ 8 核 CPU + 1T 磁盘，但是分配给 redis 进程的是 10g 内存，一般线上生产环境，redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。

5 台机器对外提供读写，一共有 50g 内存。因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis 从实例会自动变成主实例继续提供读写服务。

你往内存里写的是什么数据？每条数据的大小是多少？商品数据，每条数据是 10kb。100 条数据是 1mb，10 万条数据是 1g。常驻内存的是 200 万条商品数据，占用内存是 20g，仅仅不到总内存的 50%。目前高峰期每秒就是 3500 左右的请求量。