高可用集群架构之Redis HA方案（redisha方案）

高可用集群架构是当前互联网公司解决软件稳定性，伸缩性以及容错性的一种重要解决方案，能够确保应用持续的可用性，这也是当前互联网公司技术架构不可缺少的部分之一。其中 Redis HA 作为高可用集群架构的重要支撑，一直是互联网公司数据组中重要的存储资源，那么搭建基于Redis HA 的高可用集群架构又有哪些做法呢？

Redis HA 的高可用集群架构首先需要搭建集群，而搭建集群需要解决两个问题：一个是数据分布以及一致性问题，另一个则是保持集群节点的高可用性。

针对数据分布与一致性问题的解决方案，当前Redis支持多种数据分片技术，可以将数据分布在不同的节点上，并且可以实现多节点数据同步，来确保数据的一致性。

通常Redis 集群以三种角色维护集群状态：

– Master：主节点，提供客户端读写服务。

– Slave：从节点，从主节点读取数据；

– Sentinel：哨兵节点，监控主节点，如检测到主节点发生故障，Sentinel 会从 Slave 中选取一个节点转让主节点资格，使集群保持高可用性。

基于此，当前互联网公司针对Redis HA的方案一般会搭建N+1的集群结构，如图：


以上是个典型的Redis HA架构，其中包括3 个 Master，2 个 Slave，3 个 Sentinel，主要目的是保证Master-Slave读写一致性，确保当Master发生故障时，Sentinel可以及时发现故障并将新的Master移交给Slave，保证数据存储的高可用性，在另外的一台服务器上可以采用Sentinel的主备机制，保证Sentinel的高可用性。

Redis官网提供了一份参考方案：https://redis.io/topics/sentinel

上述参考方案会提供四种形式的实现模版，即sentinel.conf，slave_sentinel.conf ，sentinel-7000-x.conf，sentinel-7001-x.conf；代码形式如下：

sentinel.conf：

protected-mode no
port 26379

# Sentinel monitor for upstream mastern
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000

sentinel failover-timeout mymaster 180000

sentinel parallel-syncs mymaster 1

slave_sentinel.conf：

protected-mode no
port 2637
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

sentinel-7000-x.conf：

protected-mode no
port 7000
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

sentinel-7001-x.conf：

protected-mode no
port 7001
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

本文阐述了Redis HA架构的实现，具体的工程实践还需要根据具体情况做出不同的调整，以保证系统的高可用性，稳定的可用性，以及维持数据的一致性。