携程数据库高可用架构实践

Redis 的元数据被存放在 ConfigDB 中。元数据包括 Redis 实例的状态信息，以及对应的 IP 地址和端口信息等。前端可以通过页面对元数据进行调整，如设置某个实例不可用或不可读等。服务是通过 Config Service 实现的。服务会从 ConfigDB 中拉取配置，应用会定期调用 Config Service 服务，获得实例元数据信息，实现对 Redis 群集的实际访问。

我们通过一致性哈希算法对 Redis 进行分片。每一个分片都被称为组。在每一个组中，有读写实例和只读实例，它们会通过复制关系来传递数据。在部署时，我们尽量把实例分散到不同的服务器上。一旦服务器发生故障，则只会影响部分分片，不会严重影响后端数据库。我们应当尽量控制 Redis 缓存的每一个实例为 10GB 左右。如果超过 10GB，则可能需要确定是否可以进行拆分。若需要重新进行分组，则多拆分出几个组。

Redis 由哨兵来监控 Redis 实例的运行状态。我们启用了5个哨兵来同时监听。哨兵的主要功能为：

• 监控所有实例是否在正常运行；

• 当 Slave 出现故障时，通过消息通知机制把该 Slave 拉出，并将其设置为不可用，同时把 Master 设置为可读、可写；

• 当 Master 出现故障时，通过自动投票机制从 Slave 节点中选举新的 Master，实现 Redis 的自动切换。

哨兵实际上是一个运行在特殊模式下的 Redis 服务，我们可以通过在启动命令参数中指定 sentinel 选项，来标识该 Redis 服务是哨兵。每一个哨兵会向其他哨兵，即 Master 和 Slave 定时发送消息，以确认对方是否正常运行，如果发现对方在指定时间内未回应，则暂时认为对方主观挂机 ( Subjective Down，简称 SDOWN )。如果哨兵群中的多数哨兵都报告某个 Master 没响应，系统就会认为该 Master 客观挂机 ( Objective Down，简称 ODOWN )。

通过 Redis 的运行机制可以看出，Config Service 的状态信息需要和 Redis 实例的实际状态信息保持一致，否则在访问应用时会发生异常，比如，当只读实例发生故障，在重新向 Master 节点全量同步数据期间，如果该实例还是配置可读，在访问应用时就会报错。当有故障发生时，Redis 需要具备快速自动恢复的能力，减少人工干预。我们应当尽量从哨兵处获得信息，如果超过半数的哨兵发生故障，则直连 Redis 实例来获得物理状态。

对于 Redis 异地机房容灾而言，我们需要考虑跨机房全量同步为网络带来的开销，以及可能存在的网络不稳定因素。因此，我们采用了一个中间层，即 Keeper 来对数据进行缓冲。在本质上，Keeper 是伪 Slave，即实现 Redis 协议，伪装成 Slave，让 Master 推送数据到 Keeper 中。受限于篇幅，对于 Redis 异地机房容灾及切换，这里就不介绍了，谢谢大家。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：
																																					

																																						

长按订阅更多精彩▼
																																					

																																						
如有收获，点个在看，诚挚感谢