Skip to main content

为什么Redis常规架构不适合海量请求？

作者：程序员马丁

在线博客：https://nageoffer.com

note

热门项目实战社群，收获国内众多知名公司面试青睐，近千名同学面试成功！助力你在校招或社招上拿个offer。

回答话术​

Redis 可以以多种方式进行部署，具体的部署架构会根据应用场景、性能需求和可用资源等因素而有所不同，常用的 Redis 部署架构包括单机部署、主从复制、Sentinel 哨兵模式、Cluster 集群模式。

这里面能承载更多并发的是集群模式，得益于集群模式的分片、主从复制、弹性扩容这些功能可以将集群模式自动化，通过简单的部署就可以获得一个大容量、高可靠、高可用的 Redis 集群，并且对于应用来说，近乎于是透明的。

所以，Redis Cluster 是非常适合构建中小规模 Redis 集群，这里的中小规模指的是，大概几个到几十个节点这样规模的 Redis 集群。

但是 Redis Cluster 不太适合构建超大规模集群，主要原因是，它采用了去中心化的设计。Redis 的每个节点上，都保存了所有槽和节点的映射关系表，客户端可以访问任意一个节点，再通过重定向命令，找到数据所在的那个节点。但是它的更新会有一些问题，比如说，集群加入了新节点，或者某个主节点宕机了，新的主节点被选举出来，这些情况下，都需要更新集群每一个节点上的映射关系表。

Redis Cluster 采用了一种去中心化的 流言 (Gossip) 协议 来传播集群配置的变化。这个协议的特点类似于八卦，比如说，我们上学的时候，班上谁和谁偷偷好上了，搞对象，那用不了一天，全班同学都知道了。咋知道的？张三看见了，告诉李四，李四和王小二特别好，又告诉了王小二，这样人传人，不久就传遍全班了。这个就是八卦协议的传播原理。

这个八卦协议它的好处是去中心化，这样部署和维护就更简单，也能避免中心节点的单点故障。八卦协议的缺点就是传播速度慢，并且是集群规模越大，传播的越慢。这个也很好理解，比如说，换成某两个特别出名的明星搞对象，即使是全国人民都很八卦，但要想让全国每一个人都知道这个消息，还是需要很长的时间。在集群规模太大的情况下，数据不同步的问题会被明显放大，还有一定的不确定性，如果出现问题很难排查。

问题详解​

1. Redis 常用部署架构​

Redis 可以以多种方式进行部署，具体的部署架构会根据应用场景、性能需求和可用资源等因素而有所不同。以下是一些常用的 Redis 部署架构以及对应的一些可能遇到的问题：

1.1. 单机部署​

  • 架构描述：单台服务器上运行 Redis 服务。
  • 可能问题：
    • 单点故障：如果 Redis 实例所在的服务器发生故障，会导致整个服务不可用。
    • 有限的内存：受限于单台服务器的内存容量，无法处理大规模数据集。

1.2. 主从复制（Master-Slave）​

  • 架构描述：一个 Redis 主节点负责写操作，多个从节点复制主节点的数据，并处理读操作。
  • 可能问题：
    • 主节点故障：如果主节点发生故障，需要手动进行故障转移或者通过 Sentinel 进行自动故障转移。
    • 从节点复制延迟：由于复制是异步的，从节点可能会有一定程度的数据延迟。

图片来源自网��络

1.3. Sentinel 哨兵模式​

  • 架构描述：Sentinel 是 Redis 提供的一种用于监控和自动故障转移的工具。它可以监控多个 Redis 主从节点，并在主节点故障时自动将一个从节点提升为新的主节点。
  • 可能问题：
    • Sentinel 故障：如果 Sentinel 集群本身发生故障，可能会影响自动故障转移的功能。
    • 故障转移过程中的数据一致性：在故障转移期间可能会出现数据不一致的情况。

图片来源自网络

1.4. Redis Cluster​

  • 架构描述：Redis Cluster 是 Redis 提供的分布式解决方案，它将数据分片存储在多个节点上，并提供了自动数据分片和故障转移的功能。
  • 可能问题：
    • 故障转移的延迟：在发生故障时，Redis Cluster 需要一定时间来进行故障转移和数据恢复。
    • 数据分片策略的选择：合适的数据分片策略对于集群性能和负载均衡非常重要。

图片来源自网络

海量并发场景需要 Redis 提供很高的读写性能以及容灾能力，大家对于 Redis Cluster 了解会比较多，也认为这个架构是最能扛住海量并发场景的。但其实不是这样，对于小规模集群 Redis Cluster 使用是没问题的，如果对于大规模集群就有点捉襟见肘了。

2. 为什么 Cluster 模式不适合超大规模集群？​

Redis Cluster 的优点是易于使用。分片、主从复制、弹性扩容这些功能都可以做到自动化，通过简单的部署就可以获得一个大容量、高可靠、高可用的 Redis 集群，并且对于应用来说，近乎于是透明的。

所以，Redis Cluster 是非常适合构建中小规模 Redis 集群，这里的中小规模指的是，大概几个到几十个节点这样规模的 Redis 集群。

但是 Redis Cluster 不太适合构建超大规模集群，主要原因是，它采用了去中心化的设计。刚刚我们讲了，Redis 的每个节点上，都保存了所有槽和节点的映射关系表，客户端可以访问任意一个节点，再通过重定向命令，找到数据所在的那个节点。那你有没有想过一个问题，这个映射关系表，它是如何更新的呢？比如说，集群加入了新节点，或者某个主节点宕机了，新的主节点被选举出来，这些情况下，都需要更新集群每一个节点上的映射关系表。

Redis Cluster 采用了一种去中心化的 流言 (Gossip) 协议 来传播集群配置的变化。一般涉及到协议都比较复杂，这里我们不去深究具体协议和实现算法，我大概给你讲一下这个协议原理。

所谓流言，就是八卦，比如说，我们上学的时候，班上谁和谁偷偷好上了，搞对象，那用不了一天，全班同学都知道了。咋知道的？张三看见了，告诉李四，李四和王小二特别好，又告诉了王小二，这样人传人，不久就传遍全班了。这个就是八卦协议的传播原理。

这个八卦协议它的好处是去中心化，传八卦不需要组织，吃瓜群众自发就传开了。这样部署和维护就更简单，也能避免中心节点的单点故障。八卦协议的缺点就是传播速度慢，并且是集群规模越大，传播的越慢。这个也很好理解，比如说，换成某两个特别出名的明星搞对象，即使是全国人民都很八卦，但要想让全国每一个人都知道这个消息，还是需要很长的时间。在集群规模太大的情况下，数据不同步的问题会被明显放大，还有一定的不确定性，如果出现问题很难排查。

Table of Contents