从 Redis 开始聊一聊分布式架构

一、先谈单节点的 Redis 存在的问题

1. 单点故障
2. 数据容量问题
3. 连接数、请求压力问题

解决方案：AKF 思路：AKF 立方体也叫做 scala cube，AKF 把系统扩展分为以下三个维度：

• X 轴：直接水平复制应用进程来扩展系统。形象的实现就是数据库的主备模型
  。

• Y 轴：将功能拆分出来扩展系统。形象的实现就是数据库的分库
  方案。

• Z 轴：基于用户信息扩展系统。形象的实现就是数据库的分表（like：基于ID不同而分配到不同的表中）
  方案。

当时引入了一个方案之后往往会出现其他的问题。

• 由于节点增加之后增加的问题：如何保证节点之间的数据一致？

强一致性：不允许任何数据差异。

解决思路：阻塞式的挨个把数据同步到位，再返回给用户成功与否。

弊端：当一台节点挂了就 破坏了整个系统的可用性
。

弱一致性：允许丢失部分数据

解决思路：用户请求过来之后立即返回给用户成功与否，非阻塞式的同步数据给其他数据节点。

弊端：可能在 A 节点能访问到，B 节点无法访问到 C 又能访问到，就会存在丢失部分数据的问题 破坏了数据一致性
。

最终一致性

解决思路：接受到用户的操作请求之后，主节点处理完成之后将同步操作的指定放到可靠消息队列
中，保证消息最终能达到一致。

弊端：在某一个时刻会存在数据差异，破坏了数据一致性
。

画外音：什么是主备，什么是主从?

• 主备:对于客户端而言只能访问到主节点。
• 主从:对于客户端而言所有的节点都能访问到。

二、如何搭建 Redis 主备架构

详见：如何搭建 Redis 主备架构并设置哨兵

三、主备的架构，主的单点问题如何处理？

主备架构当中，主节点说到底还是避免不了单点问题？那么单纯通过人工的方式的话其实就是定时的检查端口是否还能进行通信，那么交给 redis 实现的话完全可以交给 Redis 的哨兵Sentinel

详见：如何搭建 Redis 主备架构并设置哨兵