「关注“石杉的架构笔记”，大厂架构经验倾囊相授」

“从零开始带你成为JVM实战高手” 免费加餐啦！

点击查看 专栏目录

儒猿技术团队会在“石杉的架构笔记”、“狸猫技术窝”、B站“儒猿架构”，以连载形式（图文或视频），为读者送出最新制作的“基于的分库分表实战”中的部分免费内容，期望和读者朋友一同探究业务发展里的问题，尤其是数据库的性能瓶颈问题，望各位读者朋友喜欢。

前 言

各位读者朋友，大家好，这是分库分表实战的第一篇文章，首先要介绍一下“基于的分库分表实战”的设计思路，还要介绍其内容。

本实战重点在于分库分表实战，它比较适合有1至3年工作经验的程序员朋友，实战主要将外卖APP里的外卖订单作为本次实战的核心业务。

儒猿技术团队基于外卖订单业务开发了一个外卖订单项目，借助这个项目，随着订单数据量逐步增加，系统会遇到什么问题将被逐步分析。

以这些问题为线索逐步展开分析，在进行分库分表之前，思考是否存在一些方案能够初步解决这些问题，随着订单数据量不断增加，探究为什么这些方案会失效，最终致使不得不进行分库分表。

分库分表方案具体要怎样设计，方案设计完成后要怎样落地，分库分表方案引入后会带来什么新问题，这些问题在本实战中都能找到答案。

认识一下单库版本的订单系统

开始的时候，订单系统是依靠单库运行的，随着数据量持续增多，系统会采取各类措施逐步优化，例如优化索引和sql、添加缓存、采用读写分离、进行垂直分库等方案，直到实在无法承受才会开展分库分表。

整个优化过程从单库版本到分库分表版本，其基础是一个外卖订单系统，此系统为单库版本。

儒猿技术团队已经预先运用++进行开发，从而实现了外卖订单系统，此为单库版本的订单系统，其整体架构图如下所示：

上图呈现的是单库版本订单系统的逻辑架构图与技术架构图的对比。该订单系统总共分为三层，其中一层是访问层，一层是服务层，还有一层是数据层。

访问层是调用后台服务的入口，在这里可直接进行调用，由于重点在于分库分表方案的落地，且偏向后端，因此将其直接用作请求入口极为方便。

服务层是整个订单系统的核心，它具备外卖订单系统的核心功能，像用户下单、用户查询订单列表、商家接单等；为实现这些功能，采用了一些技术，例如用某服务器对外提供服务，用Web MVC作为web开发框架，用IOC管理bean，用某工具操作数据库，用某工具记录日志。

数据层，主要用于存储外卖订单数据，此处所使用的数据库是 。

业务快速增长，驱动系统架构不断演进

设定这样一个背景，外卖订单系统处于一家初创型互联网公司，目前积累的用户数量大约为10万，每天活跃的用户大概是2万，每天相应的订单量也约为2万 。

简单做一下估算，一年的订单数据量大概是七八百万，对于单个数据库来说，轻松就能承受住 。

索引和sql优化

但创业型公司发展迅猛，若踩对风口，用户会呈现爆发式增长，此时外卖 APP 的用户量可能迅速增长至 100 万，日活用户达 20 万，日订单达 20 万，订单单表也从之前的几百万快速达到 2000 万级别，如下图：

令人担忧的是，随着时间不断推移，订单单表的数据会持续快速增长。在这个时候，sql查询的性能开始渐渐下降。到了这时，就需要着手对sql进行优化了。

此时先着手从索引和sql进行优化，展示sql优化的一般流程，这里将会有2个case。

引入缓存方案

高峰期时，大量请求打到数据库，使得数据库资源占用率很高，进而降低了查询性能，最终致使订单sql查询时间突增到2s 。

为了解决这个问题，引入缓存，如下图：

简单来讲，是运用缓存去承接大部分查询请求，如此一来，到达数据库的请求数量就变得极少，数据库的资源占用率便会稳定在正常范畴，进而让订单sql的查询效率，不会受到较大影响。

引入读写分离方案

优化案例 —— 因促销活动，大量下单的用户会不断刷新页面查询订单信息，例如查看订单是否开始配送，这时会致使大量请求打到上面 。

此时单库无法承受如此多的读请求，这使得数据库负载变得很高，进而严重降低了订单sql的查询效率，最终致使在促销活动期间，订单sql的查询时间突然增加到2.5s 。

促销活动期间存在对订单的操作，这是典型的读多写少场景，为解决该问题，引入了读写分离的方案，如下图：

写数据请求走主库，读数据请求走从库，搞了两个从库，它们能一起抗住大量读请求，订单sql的查询效率可得到显著提升。

引入垂直分库方案

引入读写分离方案后可能会遇到一个新问题，商品模块、订单模块、用户模块都部署在同一台物理数据库上，即主库，这台物理数据库的CPU负载能力，是商品模块、订单模块、用户模块共用的，其内存负载能力也是如此，网络负载能力同样是共用的。

某天，商品模块开展了一些活动，这时商品模块会承接大量读请求，尴尬的是商品模块未进行读写分离，这台物理数据库处于商品模块所在位置，它的CPU占用会很高，内存占用会很高，网络负载占用也会很高。

关键在于，数据库的资源存在限制，商品模块占用了大量数据库资源，如此一来订单模块可用的数据库资源就极为有限，这时订单写数据的sql执行时间可能会突然增加到2s，这对于订单而言绝对是无法接受的。

所以，为避免其他业务模块给订单模块带来影响，会开展垂直分库改造，情况如下所示：

垂直分库之后，每个业务都有了属于自己的独立物理服务器，之前资源相互占用的情况不复存在，最终订单写数据时间突增的问题得到了完美解决。

随着时间不断推移，订单单表的数据量肯定会越来越大，订单sql查询的时间也会越来越慢，为提高sql查询效率，为实现更好的扩展性，最终需要引入这套分库分表的方案。

来看一下分库分表版本的订单系统架构

引入分库分表的方案后，外卖订单系统的系统架构如下图：

整个分层未发生改变，分库分表之后依旧被分为三层，这三层分别是访问层、服务层以及数据层，仍然会按照从上到下的顺序逐个进行介绍：

1. 访问层：访问层使用的还是，这一层没有任何变化。

2. 服务层：

数据层会使用它，用它来进行sql改写和读写分离，并且在数据层还会引入缓存，缓存靠它来实现。

结束语

本节连载主要对整个外卖订单系统的背景做了简单介绍，对系统演进的过程做了简单介绍，对单库版本的系统架构做了简单介绍，对分库分表版本的系统架构做了简单介绍，后续会围绕单库版本的订单系统一步一步进行优化，最终优化成分库分表版本的系统架构。

为了能更好地阅读后续连载内容，建议读者仔细查看单库版本的系统架构图，还要查看分库分表版本的系统架构图，去了解当前订单系统架构的模样，清楚订单系统最终会呈现出的样子，进而形成一个整体的认知。

B站视频链接：

下期连载预告：“分库分表实战之最初的我们，了解一下单库外卖订单系统”

结束

若您对本内容有意见或建议，欢迎通过留言与我们交流，若您对儒猿团队有意见或建议，也欢迎通过客服与我们交流，借此帮助儒猿成长。儒猿会不定期送出精美礼品，用以感谢大家的关爱与帮助 。

扫描下方二维码，获取更多架构笔记资料！

点个在看你最好看