业务订单分表一

目的：

分库分表，通常在数据量增加，将会使得读写性能下降时，数据分散的一种策略。

通常分库分表，有两种选择，一种是垂直，一种是水平。

垂直一般按业务领域划分，比如用户，订单，产品等。

水平则是将将单个业务领域某一业务实体的数据按某种维度进行分散。比如按照时间，按照用户id等。

代码实现地址：

https://github.com/zhaozhenzuo/zShardingJdbc.git

下面侧重，水平分库分表方案。

一.水平分库分表方案选型

1.1.订单号生成选型

方案一：

uuid

优点：简单不重复

缺点：无任何业务含义，客服接到相应订单号处理时，会比较头疼

方案二：

数据库自增序列

优点：简单

缺点：提供自增序列的数据库可能成为单点，无业务含义

改进：可以多台数据库，每台数据库提供的步长不一样

方案三：

15位时间+8位用户id+随机数

优点：简单

缺点：可能重复

方案四：

17位时间+4位机器唯一值+4位自增+3位随机数+2位分库+2位分表

其中2位分库及2位分表的值根据userId生成。

优点：不重复，没有单点，订单有业务含义。根据用户id及订单号均可以查找到对应分库及分表。

缺点：保证5位机器唯一值在新增机子的时候不重复。增加了新增机子时的风险点。

方案四，优点比较明显，解决了订单号在有多台生成订单服务情况下的重复性问题，解决了单点问题。还有比较重要的一点是：根据用户及订单号进行路由到相对应的分库及分表。

唯品会，分库分表方案，根据用户id进行分区路由。这使得根据用户id能够高效查找。但根据订单号则需要建立订单号与用户id的映射才能高效查找。根据订单号查找场景还是多的。

二.方案四实现

2.1.订单号生成：17位时间+4位机器唯一值+4位自增+3位随机数+2位分库+2位分表

分库及分表部分，由于带userId信息，因此能够根据userId路由到。

最终实际上是通过订单上的分表信息及分库信息进行相应路由。

2.2.业务容量规则：

最大64个库，64张表。每个表按3000w数据规则，最终可存储： 1228.8亿订单数据。

每天按1000w订单量，一年是36.5亿。可以满足大约33年的业务增加。

2.3.实现逻辑

2位逻辑分库名生成规则=用户id后四位/64%64。 //必须先除以64，这样能使相应数据在一个库的64个表都分散后才进入下一个库。

2位逻辑分表名生成规则=用户id后四位%64。

根据用户id路由到实际物理库：

取用户id后4位/【每个分组实际物理库数】*【每个分组实际物理库数】

根据用户id路由到实际物理表：

取用户id后4位/【每个分组实际物理表数】*【每个分组实际物理表数】

实例：

当前分16个库，64张表。按单表3000w，可存储307亿数据。可支撑8年业务量。

假设用户id为10000016；

则2位逻辑分库=16/64%64=0

2位逻辑分表=16%64=16

最终生成订单如下：

20170729173703543100000011580016

根据userId路由：

取userId后4位0016，然后得到逻辑分库=00

逻辑分表=16

物理分库=逻辑分库/【每个分组库数】*【每个分组库数】=0／16*16=0

物理分表=逻辑分表/【每个分组表数】*【每个分组表数】=16／64*64=0