基于订单系统的分库分表实战，让应用飞起来！

V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF

前 言

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

本实战的重点是分库分表实战，比较适合1～3年工作经验的程序员朋友。实战主要以外卖APP中的外卖订单来作为本次实战的核心业务。

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

并以这些问题为线索逐步分析，在分库分表之前，有没有一些方案可以初步解决这些问题，随着订单数据量的增加，为什么这些方案会失效，最后导致不得不分库分表。

而分库分表方案具体该如何设计？方案设计完成之后又该如何落地？分库分表方案引入之后又会带来什么新的问题？这些问题都可以在本实战中找到答案。

---

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

开始时，订单系统是用单库跑的，随着数据量的不断增大，系统将会采取各种措施逐步优化，比如索引和sql的优化、加缓存、上读写分离、垂直分库等方案，最后实在抗不住了才会进行分库分表。

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

儒猿技术团队已提前使用Spring+SpringMVC+MyBatis开发实现了外卖订单系统，该单库版本的订单系统，整体架构图如下所示：

上图是单库版本订单系统的逻辑架构图和技术架构图的一个对比。该订单系统共分三层，分别是访问层、服务层和数据层。

1. 访问层：是调用后台服务的入口，这里直接使用postman来调用，因为重点是分库分表的方案落地，偏后端，所以直接使用postman来作为请求入口，非常的方便。