分库分表解决方案

前言
因为每个学校学生用餐人数太多，一天订单20万量增长，而且学校使用也在不停的增多，公司最近在搞分库分表，数据分离到不同的库中或表中， 所以这段时间了解过数据库的分库分表，也读过很多大神写的博文，基本上知道个大概，也在实际的应用中掌握分库分表的技术
下面总结一下从以下几个方面说起：
1、服务和数据库的演化过程
3、分库分表有哪几种方式。
4、分库分表有哪些问题
5、目前市面有的一些开源产品，技术，它们的优缺点是什么（只说ShardingJdbc和MyCat）

分库分表详解
下面我们以一个商城系统为例逐步讲解数据库是如何一步步演进。

** 分库**

单架构应用单数据库
早期的项目比如商城购买项目，基本上都是单体架构应用系统，一个系统中包含多个基础功能模块，比如用户模块、订单模块、库存模块等
所有模块在一个系统中，所有和功能模块关联的表也在一个数据库中，通常一个数据库中会存在非常多的表，早期用户数据量不多，使用单体架构足于满足需求。

** 为服务架构应用单数据库**
早期数据量小可能没有多大问题，后期业务量，系统分成了不同的很多功能模块，系统不停地迭代更新，代码量也会越来越大，单体架构已经不能满足需求，当用户量变大系统的访问压力也逐步的增加，项目功能模块就必须拆分。系统拆分按照功能模块拆分成Portal 服务、用户服务、订单服务、库存服务等

微服务架构单一数据库设计存在的问题：

1、微服务提供多个类型服务，但单一数据库的传统设计会产生紧密耦合，无法做为独立部署服务。

如果有多个服务访问同一数据库，则需要在所有服务间协调数据模式的更改，在现实工作中，这会导致额外的工作，延迟部署更新。

2、使用这样的设计很难对单个服务进行扩展，因为你只能选择扩展单一数据库。

3、使用单一数据库，对提高应用程序性能成为挑战。当使用单一共享数据库，在一段时间过后，我们最终会有着一个数据庞大的表，让数据检索变得很困难，我们必须连接多个大表格，方能获取所需的数据。

4、在绝大多数情况下，我们将数据使用关系存储到数据库。而使用关系数据库会限制一些服务。在有些情况下，NoSQL数据存储可能更适合你，能够降低集中式数据存储的紧密耦合。

** 微服务架构多数据库*