目录
- 架构为啥要设计
- Redis 支持的四种架构模式
- 单机模式
- 性能分析
- 优点
- 缺点
- 主从复制（读写分离）
- 结构
- 性能分析
- 优点
- 缺点
- 适用场景
- 哨兵模式
- 结构
- 优点
- 缺点
- 应用场景
- 集群模式
- 可用性和可扩展性分析
- 单机模式
- 主从模式
- 哨兵模式
- 集群模式
- 总结
本文主要以 Redis 为例，对比分析不同模式下的
优缺点，以及 系统
可用性和
可扩展性，不涉及每个模式的原理实现。
架构为啥要设计
并发量的不断提高是根本原因，要想系统不崩溃，接住这泼天的流量，需要及时找到当前新系统的瓶颈,可能是redis，mysql 或者其他组件，解决瓶颈，提高对高并发的支持- 举个例子，自己干活就是
单机模式（只能接待几个客户，而且忙死），夫妻店就是主从模式（可以接待更多的客户），搞一个团队就是集群模式，可以招待更多的客户。这几种是常见的架构，具体的 开源框架，要看它支持哪些架构。 如何看公司的系统是啥架构，直接看配置文件里关于redis 的配置就可以了
所以架构考虑的是 可用性 和 可扩展性，可以对比不同模式下的系统可用性和可扩展性。
扩展性又分为纵向扩展（加内存，加处理器，提高单机能力）和横向扩展（加单机，多个单机直接性能翻倍）。
Redis 支持的四种架构模式
- 单机模式
- 主从复制（读写分离）
- 哨兵模式
- 集群模式
单机模式
性能分析
- 顾名思义，就是一个
Redis实例节点，读写数据都找它，根据官网，单机模式如果是简单的 kev-value 读写，QPS（每秒查询速率）可支持 10w 并发，实际情况可能有复杂对象的读写，一般小于 10w。
优点
- 单机模式最大的好处就是部署简单，不存在数据同步的问题
缺点
存在单点故障，也就是加入某个时刻，这个Redis实例故障了，那系统直接没法对外提供读写功能了，所以如果不想有单点故障，就得换其他模式。 单点故障不是只有redis有，任何的单个节点，都存在单点故障，是通病- 如果系统用户激增，上千万用户同时访问 Redis，QPS 达到 10 万+。这些请求过来，单机 Redis 直接就挂了。系统的瓶颈就出现在 Redis 单机问题上，此时我们可以通过主从复制解决该问题，实现系统的高并发。
主从复制（读写分离）
结构
主从复制（从从节点的角度，从节点复制主节点的数据），主从同步（从主节点的角度，主节点会给从节点同步数据），读写分离（从读写操作的角度，读操作和写操作可以访问不同的redis实例），说的都是同一个模式- 主从复制架构里，必须只有一个
主节点，从节点的个数不定。如果是一个从节点，就叫一主一从 - 从功能上，
写操作只能访问主节点，这个是由主节点和从节点之间数据同步的方式决定的，主从模式下，只能主节点给从节点同步数据，来保证数据的一致性。读操作就可以访问所有节点了，因为读操作不改变数据的状态。
性能分析
- 估算性能的时候可以简单叠加，比如一个实例支持并发是10w，那两个实例就是20w
- 由于主从模式，读写是分开的，可以看出，对于
一主两从，读可以读三个节点，那读性能就是 30w；写只能写主机点，写性能就是10w。
优点
使系统具备了读性能的水平扩展的能力（如果用户变得更多，并且绝大多数都是读操作，那我就一直加从节点，分摊读数据的压力）优化了单点故障，如果主节点故障了，就手动切换某一个从节点为主节点，继续提供写服务。可以看出这块还能优化
缺点
- 主从模式虽然提高了系统读性能，但是写性能仍然受限，由于从节点存的是数据的备份，系统的存储性能也受限（只有一个主节点存数据，而不是 n 个节点都存）
- 主节点故障，需要手动切换，手动指定哪个是主节点，哪个是从节点，很麻烦
适用场景
- 高并发读，但是写不多的场景；同时对系统故障不那么敏感
哨兵模式
结构
- 包含
哨兵节点和数据节点,数据节点中包含主节点和从节点 - 从Redis实例的角度看，哨兵和数据节点都是一样的
- 哨兵节点：特殊的 Redis 节点，
不存储数据，用来监控数据节点，如果主节点挂了，及时选举出新的主节点 - 数据节点：主节点和从节点都是数据节点。主节点只能有一个，功能同主从模式。
优点
- 解决了单点故障的问题，可以自动选举主节点
- 是对主从模式的进一步优化
缺点
- 扩展性 同 主从模式一样，受限于单点写性能和存储性能（但是对一般小公司来说够用了）
应用场景
- 大多数小公司会选用哨兵模式，大型互联网公司得上集群模式
集群模式
集群模式可理解为 多主多从架构，从而可以改善系统的写能力，进一步提高系统的可用性。是大公司的首选
可用性和可扩展性分析
单机模式
- 可用性 和 可扩展性 均不高
- 可用性差是因为 一旦故障，则直接没法提供服务
- 可扩展性不高是因为如果系统用户激增，读写请求 10w+，系统还得崩，没法直接加服务来缓解
主从模式
- 相比
单机模式 - 提高了系统部分
横向可扩展性，具体是可以方便的通过加从节点的方式提高系统的读请求处理能力 - 提供了系统的
可用性，但远达不到高可用，具体是当读操作猛增，可通过加从节点让系统不崩，或主节点挂了，可以手动切换主节点，继续提供服务
哨兵模式
- 相比
主从模式 - 提供了系统的
可用性，具体是如果主节点挂了，系统会自动选举新的主节点，减少了故障时间，从而提高了系统的可用性
集群模式
- 相比
主从模式，哨兵模式 - 提高了系统的
可用性，可以通过添加主节点或从节点，任意的提高系统的读、写能力，不管用户怎么增加，我都能hold住 - 提高了系统的
可扩展性，同理 - 至此，完成了系统的
高可用性和高可扩展性
总结
- 面对不同的业务场景，可根据需要 确认当前可使用哪个架构模式 解决当前系统的瓶颈
- 思路是如果并发量不断提高，你怎么优化系统的架构。
- 本文只是从 Redis 的角度出发，如果再跳出一层，站在全局的角度，可优化的方案又是怎样呢
