为什么Redis常规架构不适合海量请求？
作者：程序员马丁
在线博客：https://open8gu.com
大话面试，技术同学面试必备的八股文小册，以精彩回答应对深度问题，助力你在面试中拿个offer。
回答话术
Redis 可以以多种方式进行部署，具体的部署架构会根据应用场景、性能需求和可用资源等因素而有所不同，常用的 Redis 部署架构包括单机部署、主从复制、Sentinel 哨兵模式、Cluster 集群模式。
这里面能承载更多并发的是集群模式，得益于集群模式的分片、主从复制、弹性扩容这些功能可以将集群模式自动化，通过简单的部署就可以获得一个大容量、高可靠、高可用的 Redis 集群，并且对于应用来说，近乎于是透明的。
所以，Redis Cluster 是非常适合构建中小规模 Redis 集群，这里的中小规模指的是，大概几个到几十个节点这样规模的 Redis 集群。
但是 Redis Cluster 不太适合构建超大规模集群，主要原因是，它采用了去中心化的设计。Redis 的每个节点上，都保存了所有槽和节点的映射关系表，客户端可以访问任意一个节点，再通过重定向命令，找到数据所在的那个节点。但是它的更新会有一些问题，比如说，集群加入了新节点，或者某个主节点宕机了，新的主节点被选举出来，这些情况下，都需要更新集群每一个节点上的映射关系表。
Redis Cluster 采用了一种去中心化的 流言 (Gossip) 协议 来传播集群配置的变化。这个协议的特点类似于八卦，比如说，我们上学的时候，班上谁和谁偷偷好上了，搞对象，那用不了一天，全班同学都知道了。咋知道的？张三看见了，告诉李四，李四和王小二特别好，又告诉了王小二，这样人传人，不久就传遍全班了。这个就是八卦协议的传播原理。
这个八卦协议它的好处是去中心化，这样部署和维护就更简单，也能避免中心节点的单点故障。八卦协议的缺点就是传播速度慢，并且是集群规模越大，传播的越慢。这个也很好理解，比如说，换成某两个特别出名的明星搞对象，即使是全国人民都很八卦，但要想让全国每一个人都知道这个消息，还是需要很长的时间。在集群规模太大的情况下，数据不同步的问题会被明显放大，还有一定的不确定性，如果出现问题很难排查。
问题详解
1. Redis 常用部署架构
Redis 可以以多种方式进行部署，具体的部署架构会根据应用场景、性能需求和可用资源等因素而有所不同。以下是一些常用的 Redis 部署架构以及对应的一些可能遇到的问题：
1.1. 单机部署
- 架构描述：单台服务器上运行 Redis 服务。
- 可能问题：
- 单点故障：如果 Redis 实例所在的服务器发生故障，会导致整个服务不可用。