数据库生产架构( 二 ) 分库分表

5.2.分库分表

对于大型的互联网应用来说，数据库单表的记录行数可能达到千万级甚至是亿级，并且数据库面临着极高的并发访问。采用Master-Slave复制模式的MySQL架构，只能够对数据库的读进行扩展，而对数据库的写入操作还是集中在Master上，并且单个Master挂载的Slave也不可能无限制多，Slave的数量受到Master能力和负载的限制。对于访问极为频繁且数据量巨大的单表来说，我们首先要做的就是减少单表的记录条数，以便减少数据查询所需要的时间，提高数据库的吞吐，这就是所谓的分表！

5.2.1.性能 瓶颈

5.2.2.类型

5.2.3.水平分表策略

在分表之前，首先需要选择适当的分表策略，使得数据能够较为均衡地分到多张表中，并且不影响正常的查询！

对于互联网企业来说，大部分数据都是与用户关联的，因此，用户id是最常用的分表字段。因为大部分查询都需要带上用户id，这样既不影响查询，又能够使数据较为均衡地分布到各个表中。假设有一张表记录用户购买信息的订单表order，由于order表记录条数太多，将被拆分成256张表。拆分的记录根据user_id%256取得对应的表进行存储，前台应用则根据对应的user_id%256，找到对应订单存储的表进行访问。这样一来，user_id便成为一个必需的查询条件，否则将会由于无法定位数据存储的表而无法对数据进行访问。

分表能够解决单表数据量过大带来的查询效率下降的问题，但是，却无法给数据库的并发处理能力带来质的提升。面对高并发的读写访问，当数据库master服务器无法承载写操作压力时，不管如何扩展slave服务器，此时都没有意义了。因此，我们必须换一种思路，对数据库进行拆分，从而提高数据库写入能力，这就是所谓的分库!与分表策略相似，分库可以采用通过一个关键字取模的方式，来对数据访问进行路由。还是之前的订单表，假设user_id 字段的值为258，将原有的单库分为256个库，那么应用程序对数据库的访问请求将被路由到第二个库(258%256 = 2)。

有时数据库可能既面临着高并发访问的压力，又需要面对海量数据的存储问题，这时需要对数据库既采用分表策略，又采用分库策略，以便同时扩展系统的并发处理能力，以及提升单表的查询性能，这就是所谓的分库分表。

分库分表的策略比前面的仅分库或者仅分表的策略要更为复杂，一种分库分表的路由策略如下：

1. 中间变量 = user_id % (分库数量 * 每个库的表数量)

2. 库 = 取整数 (中间变量 / 每个库的表数量)

3. 表 = 中间变量 % 每个库的表数量

​ 同样采用user_id作为路由字段，首先使用user_id 对库数量*每个库表的数量取模，得到一个中间变量；然后使用中间变量除以每个库表的数量，取整，便得到

对应的库；而中间变量对每个库表的数量取模，即得到对应的表。

​ 分库分表策略详细过程如下：

​ 假设将原来的单库单表order拆分成256个库，每个库包含1024个表，那么按照前面所提到的路由策略，对于user_id=262145 的访问，路由的计算过程如下：

1. 中间变量 = 262145 % (256 * 1024) = 1

2. 库 = 取整 (1/1024) = 0

3. 表 = 1 % 1024 = 1

​ 这就意味着，对于user_id=262145 的订单记录的查询和修改，将被路由到第0个库的第1个order_1表中执行！！！

5.2.4.分库分表之后,id 主键如何处理？

因为要是分成多个表之后，每个表都是从 1 开始累加，这样是不对的，我们需要一个全局唯一的 id来支持。
生成全局 id 有下面这几种方式：
(1) UUID：不适合作为主键，因为太长了，并且无序不可读，查询效率低。比较适合用于生成唯一的名字的标示比如文件的名字。
(2) 数据库自增 id : 两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。这种方式生成的 id 有序，但是需要独立部署数据库实例，成本高，还会有性能瓶颈。
(3) 利用 redis 生成 id : 性能比较好，灵活方便，不依赖于数据库。但是，引入了新的组件造成系统更加复杂，可用性降低，编码更加复杂，增加了系统成本。
(4) Twitter的snowflake算法 ：Github 地址：https://github.com/twitter-archive/snowflake。
(5) 美团的Leaf分布式ID生成系统 ：Leaf 是美团开源的分布式ID生成器，能保证全局唯一性、趋势递增、单调递增、信息安全，里面也提到了几种分布式方案的对比，但也需要依赖关系数据库、Zookeeper等中间件。感觉还不错。

美团技术团队的一篇文章：https://tech.meituan.com/2017/04/21/mt-leaf.html 。

5.2.5.分库分表的缺点

(1)事务的一致性：如果我们按id取模来插插数据，插10条数据，5条插一张表，另外5条插另外一张表。这就需要考虑到分布式事务的问题，分布式事务本来就已经非常麻烦了，再加上这个东西，就变得更加棘手了。分布式事务是尽量需要避免的。
(2)主键避重：如果有主键重复了，数据库没办法帮我们检测这些数据。加重了数据的麻烦程度。使用UUID也很容易造成冲突
(3)运维工作量：每做一个操作都要考虑数据片是怎么分布的。