互联网场景下，我们经常会面临一个产品流量从初创时期的小流量到全盛大流量的过程。
这时候，原本的架构设计就显得很不合理，变成你追求服务稳定性阻碍。
然而这一切并不一定是你的架构能力的问题，而是在小流量场景下，不能过高的去评估容量和架构冗余性，避免造成不必要的资源和维护人力的浪费。
能做的是为以后的架构演进提供可扩展性准备，让原本强依赖数据存储层的风险可以实现逐层降级。

2 强依赖降级过程

2.1 第一阶：简单流量，读写不分离

如果你的业务刚上线，服务流量很小，那你大概率数据服务会仅部署一个实例，读写也会汇聚在一些。结构如下：

这样做的好处是：

• 小流量场景下资源利用率高
• 一致性高，不会出现读写顺序和一致性问题

这样做的坏处是：

• 读写互相影响，一旦出现故障，整体不可用

2.2 第二阶：流量上涨，读大于写，读写分离

大厂内部的评估法则通常流量达到一定规模，并且读写比不低于8:2，否则读写分离的价值不大。结构如下：

读写分离这种数据库架构策略，将数据库的读和写操作分散到不同的数据库服务器上。这种策略有助于提高数据库的并发处理能力和整体性能。

读写分离的基本思想是将数据库的读操作和写操作分开处理，通常使用一个主数据库（Master）来处理写操作（如INSERT、UPDATE、DELETE等），而使用多个从数据库（Slave）来处理读操作（如SELECT等）。主数据库会将其更改实时同步到一个或多个从数据库中，确保数据的一致性。

它有如下优势：

• 负载均衡：分发读操作到多个从数据库服务器，以提高并发处理能力和负载均衡。
• 监控和故障转移：检测数据库服务器的健康状况，并在主数据库出现故障时自动切换到从数据库。

也存在一些挑战和限制：

• 主从同步可能会引入延迟，导致从数据版本差异
• 读写分离也可能增加数据一致性和故障恢复的复杂性

2.3 第三阶：多域流量和稳定性要求高，两地三中心

“两地三中心” 是指本地和异地分别建立三个中心，包括本地生产中心、同城灾备中心和异地灾备中心。这种架构旨在确保业务的高可用性和数据的安全性，以应对各种自然灾害或人为因素导致的业务中断。

从图中『核心指标』可以看出，它主要提高了可用性，即使在大规模流量场景下，能够保证系统足够健壮。
详细可以参考笔者这一篇《高可用架构，去中心化有多重要？》

2.4 第四阶：使用缓存进行风险降级

缓存的目的主要是兜底，避免持久化数据层出现故障时候的完全不可用。
同时能提高性能和可用性，毕竟高速缓存和磁盘的效率不可同日而语，多了一层保障，可用性也大幅提升。
详细可以参考笔者这边《深刻理解高性能Redis的本质》。

2.5 第五阶：去中心化，本地缓存提升可用性

互联网性能演进经常会听到这样一句话：把数据放在离用户最近的地方，即安全又快捷。
无论读取数据库还是读取缓存服务，毕竟是跨节点的，那就存在风险，网络抖动，机房故障都有可能成为故障诱因。
去中心化的本质是在所有依赖项都无法正常运转之后，服务依然独立可用。
详细可以参考笔者这一篇《高可用架构，去中心化有多重要？》

这边的做法就是在本地缓存一份刚性数据，允许一定的延迟，但是需要保证服务不被挂起，短时间内（一般4小时为判断标准）服务有依然可用。如下图：

本文介绍了互联网场景下高流量的数据强依赖的降级演进过程。主要核心点如下：

• 读写分离保证数据存储单点故障的恢复，如：Master故障，Slave切换成Master；Slave故障，读写汇聚到Master
• 两地三中心提高可用性，应对地域级风险
• 缓存服务提高性能和可用性，为数据中心故障做兜底
• 本地缓存实现去中心化，进一步提高可用性，依赖项故障依然能保证服务独立可用