知识库系列：【架构必备】读写分离。准备面试？工作遇到问题？想要积累知识？快来7TCoding搜一搜。不积跬步，无以至千里不积小流，无以成江海。生活中总有些东西值得分享。

 

底部有惊喜，关注更多精彩不积跬步，无以至千里不积小流，无以成江海生活中总有些东西值得分享整理 | 7TCoding ； 策划 | 小七

由于公众号改版，为了不错过精彩内容，大家一定要把我们星标哦！1. 问题&分析在读多写少的互联网业务场景，往往“读”性能会成为第一个瓶颈随着业务的发展，数据库负载越来越高，逐渐成为系统的瓶颈面对“读”性能瓶颈，大致有以下几种解题思路：。

提升 DB 配置从而获取更高的性能使用更 NX 的机器，升级 DB 的 CPU、内存、磁盘等；使用更多的 DB 来分担读压力对 DB 进行“拆分”，一个 DB 实例负责数据写入，一组 DB 实例负责数据查询，也就是常说的读写分离；。

将 读 压力转移到其他存储引擎比如引入读性能更高的 Cache，让 Cache 挡在 DB 前面，降低落到 DB 上的请求量；上面三种方案各具千秋，但性价比最高的仍旧是“读写分离方案”：方案一，升级硬件资源，简单粗暴，主要是金钱上的考量；另外，硬件是存在天花板的，金钱不能解决一切问题；。

方案三，缓存是提升读性能的一大杀器，追求性能的同时需要做很多事，比如调整逻辑代码、进行一致性保障、增加运维成本等，同时也为系统引入更多的复杂性落地效果非常不错但有时，杀鸡焉用牛刀？方案二，中规中矩介于两者之间，无需过量的金钱投入，也无需过早的引入太多复杂性。

2. 读写分离以数据库部署架构为基础，对数据操作进行分离，主节点主要处理写请求，从节点主要处理读请求通过引入多个副本来分散读请求，从而实现 读请求 的水平扩展主副本 与 从副本 间的数据一致就是通过 “复制” 来完成。

读写分离架构有几个非常重要的概念：主副本也称主节点，可以接受 读&写请求；从副本也称从节点，只能处理 读请求；复制主副本 与 从副本 间 基于“复制”技术实现数据同步；路由基于路由规则将请求分发至整个集群（主副本 + 从副本）。

以最常见的MySQL主从架构为例：

image通过扩展 Slave 可以实现 读请求 的水平扩展，核心流程如下：应用将写请求路由到 Master 节点；Master 节点完成写入后（事务提交），将变更写入到 Binlog；Slave 节点从 Master 节点获取 Binlog，并执行变更（涉及中继日志和并发复制），保持与 Master 数据一致；

应用将读请求路由到 Slave 节点，从 Slave 中获取数据；备注：Slave 过多会加重 Master 的压力，可通过多级复制或分区进行解决读写分离架构可以方便的对读请求进行扩展，看似美好，但需要解决两个问题：。

数据同步如何保障主从副本间的数据一致性，通常情况下由存储引擎的“复制”机制来保障；请求路由何时操作主副本，何时操作从副本，如何在多个副本间做负载均衡？2.1. 复制模式复制模式主要解决数据同步问题通常比想象中的复杂，在此只对 单主复制 进行介绍，对于多主复制，由于过于复杂，并不在讨论范围。

2.1.1. 同步复制同步复制架构如图所示：

image核心流程：主节点处理完请求后，将复制信息同步到所有节点；待所有节点返回后，再向用户返回最终结果；特点：优点强一致性保障，应用写入成功后，从节点与主节点间就达成了一致，不存在数据延时问题缺点影响写入性能。

写性能 = Master + Max（Slave）影响可用性某个 Slave 异常，直接影响写入，导致写入流程被中断常见应用场景：在实际开发中，该方案很少使用，特别是在 CAP 最终一致性思想的影响下TiDB 等 NewSQL 内部通过一致性协议保障 强一致，基于 NRW 理论保障可用性，这块非常复杂，不在讨论范围

2.1.2. 异步复制异步复制架构如下：

image核心流程：主节点处理完请求后，直接返回处理结果；从节点通过异步方式从主节点获取信息；特点优点：写入性能好缺点：存在数据丢失风险应用场景数据安全性要求低，性能要求高的场景，如 日志记录 等极端情况下的“饮鸩止渴”，如 秒杀、大促场景

2.1.3. 半同步复制半同步复制是同步复制和异步复制的结合体，架构如下：

image核心流程主节点处理完请求后，对部分节点进行同步复制，等待其复制完成后，在向应用返回最终的处理结果；其他剩余节点进行异步复制特点在性能和一致性间做平衡应用场景满足大多数业务场景2.2. 路由模式。

路由模式，主要决定请求如何分发到众多的数据库节点。2.2.1. 应用路由在应用层使用代码对请求进行分发，整体架构如下：

image核心流程：为每个数据库节点构建一个DataSource，结合 ORM 框架，构建不同的 DAO应用代码根据业务场景，调用不同的 DAO 实现，完成读写操作多个从节点 DataSource 可以封装为 一个聚合 DAO，内嵌负载均衡算法，在不同的 从库 间进行路由

特点：优点：简单，使用编码实现，掌控力最强缺点：对系统存在极大的侵入性，需要修改大量的逻辑代码场景：存在于老的项目或需要极致掌控力的场景2.2.2. 智能数据源将多个 DataSource 封装为一个具有路由功能的 SmartDataSource，整体架构如下：

image核心设计如下：每一个数据节点对应一个 DataSource将多个 DataSource 封装为一个 SmartDataSourceSmartDataSource 自动解析 SQL，根据 SQL 类型自动完成请求路由

应用程序仅于 SmartDataSource 进行通信特点：优点：对程序没有侵入性，无需调整代码，只需替换底层 DataSource 即可缺点：集群情况下，需要配置中心进行统一协调场景：特别使用于高性能场景

2.2.3. Proxy 路由将 SmartDataSource 核心功能抽取到单独的服务，整体架构如下：

image核心设计：将 SmartDataSource 的职能抽取到单独的服务向下管理多个数据库节点向上暴露标准的 jdbc 接口，供应用程序使用特点：优点便于管理，所有的管理动作全部收口到 Proxy 层；。

缺点增加一层网络开销，对性能有一定的影响；场景：使用于管理场景通常情况下，会在配置中心的基础上，综合使用智能路由和Proxy路由两种模式：智能路由用于应用程序，追求极致的性能；Proxy路由用于数据库管理，追求管理的便利性；。

配置中心为智能路由和Proxy路由提供统一的配置信息3. 延时挑战应用程序集成读写分离后，最主要的挑战便是：复制延时所以，在系统设计时，需要对特定场景进行特殊处理3.1. 更新场景，强制切主对于更新场景，为了避免 主从延时导致的 写覆盖问题，通常使用强制切主策略。

写覆盖的根源，见下图：

image由于存在主从延时，所加载的 聚合根 不一定是最新的数据，因此，后续的修改 和 保存，都是在过期数据上执行，导致写丢失备注：乐观锁保护下，不会出现写丢失情况；面对这种场景，最简单的策略便是：强制切主。

具体流程如下：

image直接从 Mater 进行加载，避免 Slave 查询到过期数据SmartDataSource 和 Proxy 都提供了强制切主的设置方式，在此不做过多介绍3.2. 根据 version 进行智能路由。

如果下游能拿到最新版本的 version，便可以根据 version 智能的获取数据。以领域事件场景为例，问题描述如下：

image核心流程如下：业务完成后，将变更更新至 DB，Master 更新完成后，直接返回处理结果；Slave 启动异步同步，但完成时间不可控；业务发送 领域事件 至 Topic；下游业务监听消息后，从 Slave 查询数据，如果Slave 尚未同步完成，则出现获取不到或获取过期数据的问题

针对这个场景，可以引入 version 进行数据验证，基于 Version 的流程如下：

image核心流程如下：业务完成后，将业务变更和version变更更新至 DB，Master 更新完成后，直接返回处理结果；Slave 启动异步同步，但完成时间不可控；领域事件包含当前的最新 version，将其发送至 Topic；

下游业务监听消息后，先从 Slave 获取数据，并比对两者的 version如果大于等于 msg 中的 version，则直接使用；否则 从 Master 中进行加载，然后执行业务逻辑备注：步骤4 中 version 管理应该封装在服务接口，对外提供统一的带 version 参数的接口；

时间戳是一种特殊的version，可以使用数据表的 update_time 作为 version3.3. 读己之写读己之写，简单说就是：保存完数据后，理解读取数据由于复制延时的存在，通常无法立即读取刚写入的数据，问题流程如下：。

image核心流程：业务基于 Master 完成操作直接返回，异步并将变更复制到从节点UI跳转至下一个页面，该页面会读取最新数据（详情页、列表页）由于存在主从复制延时，可能无法获取最新数据3.3.1. 主动延时

最简单的解法便是，在完成数据更新操作后，UI 主动sleep几秒，然后在进行下一步操作。

image整体流程如下：在跳转新页面前，增加 loading 页，主动等待主从完成同步在系统压力大时，仍旧无法从根源上解决该问题由于其简单性，在项目中也大量使用3.3.2. UI 动态添加主动等待对用户存在一定的伤害，可以使用动态添加方案提升用户体验。

image核心点包括：更新请求处理完成后，直接返回最新的数据，包括新增数据或修改后的数据；前端获取数据后，直接在 UI 上进行操作，如将其 append 到 Table 中 或 直接渲染 详情页；3.3.3. 智能切主

UI主动添加只是一种障眼法，用户刷新页面，仍旧可能看不到最新数据，可以试试强制切主

image根据规则，决定是否强制切主，如下：根据业务场景，“我的 xxx” 强制切主，其他请求 默认走 Slave时间间隔，请求时携带时间戳或版本，对请求进行切主判断4. 小结简单回顾，本文概要介绍了“读写分离”的方方面面，主要设计

读写分离是提升系统读性能的重要手段落地读写分离，需要解决复制 和 路由 技术问题由于复制延时的存在，对特殊的业务场景进行治理你学废了吗准备面试？工作遇到问题？想要积累知识？快搜索公众号：7TCoding

往期内容回顾：拼多多砍一刀黑幕终于被揭穿……全部和这个数据运营模型有关！知识库系列：并发编程之ReentrantLock类使用介绍知识库系列：JDK21 性能提升20倍互联网知识库合集【详见脑图】知识库系列：Zookeeper和Mybatis（持续更新）

知识库系列：Dubbo（附脑图-持续更新）知识库系列：分布式搜索和分析引擎Elasticsearch（附脑图-持续更新）知识库系列：Redis（附脑图-持续更新）知识库系列：分布式的高速缓存系统Memcached（附脑图-持续更新）

知识库系列：MySQL（附脑图-持续更新）知识库系列：Java基础1+2（附脑图-持续更新）知识库系列：SpringBoot干货实践及知识库（附脑图-持续更新）知识库系列：Linux知识库（附脑图-持续更新）

知识库系列：微服务系列（附脑图-持续更新）知识库系列：Spring 知识库（一）（附脑图-持续更新）知识库系列：5万长文Java知识Java3+4（附脑图-持续更新）知识库系列：Spring Cloud （附脑图-持续更新）

知识库系列：异常、网络和部分设计模式知识库（持续更新）知识库系列：RabbitMQ（持续更新）知识库系列：分布式十二问！万字图文详解！（持续更新）谁能真正替代你？AI编码工具深度对比(chatGPT/Copilot/Cursor/New Bing)

知识库系列：太牛比了！i/o timeout 的全解思路及实战， 希望你不要踩到这个net/http包的坑（持续更新）知识库系列：对标大厂的技术派架构设计（持续更新）知识库系列：一文看懂零售行业数据分析的五大场景：商品/门店/库存/活动/会员

知识库系列：8大好用的数据迁移工具，真的太方便了！（持续更新）知识库系列：从实现到原理，聊聊Java中的SPI动态扩展（持续更新）如果今年面试难，建议先上岸再说【200多家IT软件外包公司汇总】知识库系列：某大厂的DDD实践，给出落地的示例（持续更新）

知识库系列：OAuth2.0授权码模式原理与实战（持续更新）知识库系列：mysql的varchar字段最大长度真的是65535吗？（持续更新）知识库系列：我用chatGPT造了“模特”（持续更新）知识库系列：MySQL索引，快速记忆法

知识库系列：用户转化行为，该如何进行分析？知识库系列：五种最常见加密算法！你见过几个？知识库系列：18张图，详解SpringBoot解析yml全流程知识库系列：明明加了唯一索引，为什么还是产生重复数据？

知识库系列：面试官：为什么JDK动态代理只能代理接口？知识库系列：手把手教你申请微软 Azure OpenAI 全教程知识库系列：手把手教你开发一套代码生成器，学不会的来怼我！持续更新中......更多精彩，请加入我们哦！

添加小编微信，拉你进群哦

免责声明：部分内容来自网络，版权归原作者所有，禁止用于商业用途，对转载、分享的内容、陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完善性提供任何明示或暗示的保证，仅供读者学习参考之用，如有侵犯机构、媒体、公司 、企业或个人等的知识产权，请联系删除，本公众平台将不承担任何责任。

免责声明：本站所有信息均搜集自互联网，并不代表本站观点，本站不对其真实合法性负责。如有信息侵犯了您的权益，请告知，本站将立刻处理。联系QQ：1640731186