高可用的Redis技术方案【单副本、多副本（主从）、哨兵】

Redis的一些常见主要用途：

• Redis单副本
• Redis多副本（主从）
• Redis哨兵（哨兵）
• Redis集群
• Redis自研

不同使用Redis方式的优缺点：Redis不使用单副本Redis单副本Redis架构，无Standby节点同步数据是实时的，不提供数据持久化和备份策略。适用于数据可靠性要求不高的纯缓存业务场景。

优点：

1。架构简单，部署方便

2。性价比高。使用缓存时不需要备份节点（可以通过admin或crontab保证一个实例的可用性）。当然，为了满足商店的高可用，也可以牺牲一个备用节点，但每次只有一个实例对外提供服务。 ？无法解决缓存预热问题，不适合数据可靠性要求较高的企业。

3。高性能受限于单核CPU的计算能力（Redis是单线程机制），CPU是主要瓶颈，因此适合操作语句简单、排序和计算量较少的场景。您也可以考虑使用 memcached 代替。 2 Redis 多副本（主从）

Redis 多副本采用主从（复制）部署结构。相比单副本，最大的特点是主从实例之间数据实时同步，并提供数据持久化。和备份策略。主从实例部署在不同的物理服务器上。根据公司环境的基本配置，可以对外提供服务，同时实施读写分离策略。

优点：

1。高可靠性。一方面，它采用了两机主备架构，可以在主库故障时自动进行主备切换。支持从库为主库提供服务，保证服务的顺利运行。 。另一方面，开启数据持久化功能并配置合理的备份策略可以有效解决数据误操作和数据异常丢失的问题。

2。通过读写分离策略，从节点可以扩展主库节点的读能力，高效处理大并发读操作。

缺点：

1。错误恢复很复杂。如果没有RedisHA系统（需要开发），当主数据库节点出现故障时，必须手动将从节点提升为主节点，并通知业务方配置变更，其他从节点必须复制新的主数据库节点。整个过程需要人工干预，相当繁琐。

2。主库的写入能力仅限于一台机器。您可以考虑分片

3。主库的存储容量仅限于一台机器。您可以考虑皮卡

4。本机复制的缺点存在于早期版本中。也会更加明显。例如：中断Redis复制后，Slave启动psync。如果此时同步失败，将执行完全同步。主库进行全量备份时，可能会造成毫秒级或秒级的延迟；并且由于COW机制，极端情况下会导致主库溢出，程序异常终止或崩溃；库主节点生成备份文件，造成服务器磁盘IO和CPU消耗（压缩）；发送多GB的备份文件会导致服务器的导出带宽增加并阻止请求。建议升级到最新版本。 3Redis Sentinel（哨兵）

Redis Sentinel 是在社区版本中运行的本机高可用性解决方案。 Redis Sentinel部署架构主要包括两部分：Redis Sentinel集群和Redis数据集群。 Redis Sentinel 集群由多个 Sentinel 节点组成。组成的分布式集群，可以实现错误检测、自动故障转移、配置中心、客户端通知等功能。 Redis Sentinel 中的节点数量必须是 2n+1 (n>=1) 的奇数。 ？其自身的单线程瓶颈可以很大程度上满足Redis大容量或高性能的业务需求。 ？浪费资源，Redis数据节点中的子节点不作为备份节点提供服务

3。 Redis Sentinel主要用于Redis数据节点中主节点的高可用切换，对Redis数据节点的故障评估分为主观下线和针对Redis从节点的主观下线操作两种，并且不执行故障转移。

4。它无法解决读写分离问题，并且实现起来相当复杂。

推荐：

1。如果监控同一企业，可以选择Sentinel集群来监控多组Redis数据节点。否则，请选择一个。 Sentinel 监控一组 Redis 数据节点。

2。 Sentinel Monitor 建议配置中的设置为Sentinel节点的一半加1。当Sentinel部署在多个IDC上时，我们不建议一台IDC部署的Sentinel数量超过（Sentinel数量-法定人数）。 ？

4、各个部署节点的服务器时间必须尽可能同步，否则日志时序会比较混乱

5。 Redis 建议使用管道操作和多个 key 来减少 RTT，提高请求效率

6。自己搭建一个配置中心（zookeeper），方便客户端访问实例链接4Redis集群

Redis集群是运行社区版本的分布式Redis集群解决方案。它主要解决Redis分发的需求。比如，当遇到单机内存、并发、流量等瓶颈时，Redis Cluster可以起到很好的负载均衡的作用。最小Redis Cluster节点配置为6个以上节点（3主3从）。主节点处理读写操作，从节点作为备份节点，不服务请求，仅用于故障转移。 Redis Cluster 使用虚拟槽分区。根据哈希函数，所有键都映射到 0 到 16383 个整数槽。每个节点负责维护一部分槽以及映射到槽的键值数据。

优点：

1。没有中心架构

2。数据通过槽存储并分布在多个节点上。数据在节点之间共享，数据分布可以动态调整。

3。可扩展性，可线性扩展至1000个以上节点，并可动态添加或删除节点。

4。高可用性，当部分节点不可用时集群仍然可用。通过添加一个Slave作为数据备份可以实现自动故障转移。节点之间通过gossip协议交换状态信息，并通过投票机制完成从Slave到Master的角色晋升。

5。降低运维成本，提高系统的可扩展性和可用性。

缺点：

1。客户端实现复杂，驱动需要Smart Client实现，缓存槽位映射信息并及时更新，增加了开发难度。客户的不成熟影响业务的稳定性。目前只有JedisCluster比较成熟，异常处理部分还不太完善，比如常见的“最大重定向异常”。

2。该节点会因为某些原因被阻塞（阻塞时间长于 clutser-node-timeout），并且会被视为离线。这种故障转移是没有必要的。

3。数据异步复制，无法保证数据强一致性。

4。多个企业使用同一个集群时，冷热数据无法统计区分，资源隔离性差，容易产生相互影响。

5。 Slave在集群中充当“冷备”，无法释放读压力。 Slave资源的使用当然可以通过合理的SDK设计来提高。

6。批处理操作的主要限制。例如，使用mset和mget目前仅支持对具有相同槽值的key进行批量操作。对于映射到不同槽值的key，由于key不支持跨槽查询，因此执行mset、mget、sunion等操作并不方便用户操作。

7。对关键事务操作的支持是有限的。它仅支持同一节点上多个密钥的事务操作。如果多个密钥分布在不同节点上，则无法使用交易功能。

8。键是数据分区的最小粒度，因此哈希、列表等大型键值对象无法映射到不同的节点。

9。不支持多个数据库空间。独立模式下的Redis最多可以支持16个数据库。集群模式下只能使用一个数据库空间，即db 0。

10。复制框架仅支持一层。子节点只能复制主节点，不支持嵌套树复制结构。

11。避免生成导致主库节点成为系统短缺的热键。

12。避免生成大密钥，这会导致网卡过载、查询缓慢等。

13。重试时间应长于集群节点时间

14。 Redis Cluster不建议使用管道操作和多个key来减少最大重定向场景。 5Redis自研-推荐

Redis自研高可用方案，主要体现在配置中心、错误检测和故障处理机制，通常需要根据当前的线上环境进行适配企业。 ？ 1。实施复杂，开发成本高

2。应建立监控、域名服务、存储元数据信息的数据库等配套外围设备。

3．维护成本高