架构设计入门（Redis架构模式分析）

本文主要以 Redis 为例，对比分析不同模式下的 优缺点，以及 系统 可用性和 可扩展性，不涉及每个模式的原理实现。

架构为啥要设计

• 并发量的不断提高是根本原因，要想系统不崩溃，接住这泼天的流量，需要及时找到当前新系统的瓶颈,可能是redis，mysql 或者其他组件，解决瓶颈，提高对高并发的支持
• 举个例子，自己干活就是单机模式（只能接待几个客户，而且忙死），夫妻店就是主从模式（可以接待更多的客户），搞一个团队就是集群模式，可以招待更多的客户。这几种是常见的架构，具体的 开源框架，要看它支持哪些架构。
• 如何看公司的系统是啥架构，直接看配置文件里关于redis 的配置就可以了

所以架构考虑的是 可用性 和 可扩展性，可以对比不同模式下的系统可用性和可扩展性。
扩展性又分为纵向扩展（加内存，加处理器，提高单机能力）和横向扩展（加单机，多个单机直接性能翻倍）。

Redis 支持的四种架构模式

• 单机模式
• 主从复制（读写分离）
• 哨兵模式
• 集群模式

单机模式

性能分析

• 顾名思义，就是一个 Redis实例节点，读写数据都找它，根据官网，单机模式如果是简单的 kev-value 读写，QPS（每秒查询速率）可支持 10w 并发，实际情况可能有复杂对象的读写，一般小于 10w。

优点

• 单机模式最大的好处就是部署简单，不存在数据同步的问题

缺点

1. 存在单点故障，也就是加入某个时刻，这个Redis实例故障了，那系统直接没法对外提供读写功能了，所以如果不想有单点故障，就得换其他模式。 单点故障不是只有redis有，任何的单个节点，都存在单点故障，是通病
2. 如果系统用户激增，上千万用户同时访问 Redis，QPS 达到 10 万+。这些请求过来，单机 Redis 直接就挂了。系统的瓶颈就出现在 Redis 单机问题上，此时我们可以通过主从复制解决该问题，实现系统的高并发。

主从复制（读写分离）

结构

• 主从复制（从从节点的角度，从节点复制主节点的数据），主从同步（从主节点的角度，主节点会给从节点同步数据），读写分离（从读写操作的角度，读操作和写操作可以访问不同的redis实例），说的都是同一个模式
• 主从复制架构里，必须只有一个 主节点，从节点的个数不定。如果是一个从节点，就叫一主一从
• 从功能上，写操作只能访问主节点，这个是由主节点和从节点之间数据同步的方式决定的，主从模式下，只能主节点给从节点同步数据，来保证数据的一致性。读操作就可以访问所有节点了，因为读操作不改变数据的状态。

性能分析

• 估算性能的时候可以简单叠加，比如一个实例支持并发是10w，那两个实例就是20w
• 由于主从模式，读写是分开的，可以看出，对于一主两从，读可以读三个节点，那读性能就是 30w；写只能写主机点，写性能就是10w。

优点

• 使系统具备了读性能的水平扩展的能力（如果用户变得更多，并且绝大多数都是读操作，那我就一直加从节点，分摊读数据的压力）
• 优化了单点故障，如果主节点故障了，就手动切换某一个从节点为主节点，继续提供写服务。可以看出这块还能优化

缺点

1. 主从模式虽然提高了系统读性能，但是写性能仍然受限，由于从节点存的是数据的备份，系统的存储性能也受限（只有一个主节点存数据，而不是 n 个节点都存）
2. 主节点故障，需要手动切换，手动指定哪个是主节点，哪个是从节点，很麻烦

适用场景

• 高并发读，但是写不多的场景；同时对系统故障不那么敏感

哨兵模式

结构

• 包含 哨兵节点 和 数据节点 ,数据节点中包含 主节点 和 从节点
• 从Redis实例的角度看，哨兵和数据节点都是一样的
• 哨兵节点：特殊的 Redis 节点，不存储数据，用来监控数据节点，如果主节点挂了，及时选举出新的主节点
• 数据节点：主节点和从节点都是数据节点。主节点只能有一个，功能同主从模式。

优点

• 解决了单点故障的问题，可以自动选举主节点
• 是对主从模式的进一步优化

缺点

• 扩展性 同 主从模式一样，受限于单点写性能和存储性能（但是对一般小公司来说够用了）

应用场景

• 大多数小公司会选用哨兵模式，大型互联网公司得上集群模式

集群模式

集群模式可理解为 多主多从架构，从而可以改善系统的写能力，进一步提高系统的可用性。是大公司的首选

---

可用性和可扩展性分析

单机模式

1. 可用性 和 可扩展性 均不高
2. 可用性差是因为 一旦故障，则直接没法提供服务
3. 可扩展性不高是因为如果系统用户激增，读写请求 10w+，系统还得崩，没法直接加服务来缓解

主从模式

1. 相比 单机模式
2. 提高了系统部分横向可扩展性，具体是可以方便的通过加从节点的方式提高系统的读请求处理能力
3. 提供了系统的 可用性，但远达不到高可用，具体是当读操作猛增，可通过加从节点让系统不崩，或主节点挂了，可以手动切换主节点，继续提供服务

哨兵模式

1. 相比 主从模式
2. 提供了系统的 可用性，具体是如果主节点挂了，系统会自动选举新的主节点，减少了故障时间，从而提高了系统的可用性

集群模式

1. 相比 主从模式，哨兵模式
2. 提高了系统的 可用性，可以通过添加 主节点 或 从节点，任意的提高系统的读、写能力，不管用户怎么增加，我都能hold住
3. 提高了系统的 可扩展性，同理
4. 至此，完成了系统的 高可用性 和 高可扩展性

总结

• 面对不同的业务场景，可根据需要 确认当前可使用哪个架构模式 解决当前系统的瓶颈
• 思路是如果并发量不断提高，你怎么优化系统的架构。
• 本文只是从 Redis 的角度出发，如果再跳出一层，站在全局的角度，可优化的方案又是怎样呢