一致性hash 大众点评订单分库分表实践

井底之蛙 https://mp.weixin.qq.com/s?src=3&timestamp=1543228894&ver=1&signature=uF6nV0yYseJ554HjTj8Z2E3ogX05l14gv88Je-2mvUxRt61gl07eWEpf*tU5NHitn3pZ3IEKmlrHK*2xMiceDtgvPpk7y8pZUrAibjAcsmyKQzQiQ9cbjMbhx-GUWVNltVqTj6lv2Jv70sP1nuCFPA==

李华慰 井底之蛙 2016-02-19

背景

订单单表早已突破两百G，因查询维度较多，即使加了两个从库，各种索引优化，依然存在很多查询不理想的情况；加之去年大量的抢购活动的开展，数据库达到瓶颈，应用只能通过限速、异步队列等对其进行保护；同时业务需求层出不穷，原有的订单模型很难满足业务需求，但是基于原订单表的DDL又非常吃力，无法达到业务要求；随着这些问题越来越突出，订单数据库的切分就愈发急迫了。

我们的目标是未来十年内不需要担心订单容量的问题

垂直切分

先对订单库进行垂直切分，将原有的订单库分为基础订单库、订单流程库等，这篇文章就不展开讲了。

水平切分

垂直切分缓解了原来单集群的压力，但是在抢购时依然捉襟见肘，并且原有的的订单模型已经无法满足业务需求，于是我们设计了一套新的统一订单模型，为同时满足C端用户、B端商户、客服、运营等的需求，我们分别通过用户ID和商户ID进行切分，并通过PUMA同步到一个运营库

切分策略

1、查询切分

将id和库的mapping关系记录在一个单独的库中

优点：id和库的mapping算法可以随意更改

缺点：引入额外的单点

2、范围切分

比如按照时间区间或id区间来切分

优点：单表大小可控，天然水平扩展

缺点：无法解决集中写入瓶颈的问题

3、hash切分

一般采用mod来切分，下面着重讲一下mod的策略

数据水平切分后我们希望是一劳永逸或者是易于水平扩展的，所以推荐采用mod 2^n这种一致性哈希

以统一订单库为例，我们分库分表的方案是32*32的，即通过userId后四位mod 32分到32个库中，同时再将userId后四位div 32 mod 32将每个库分为32个表，共计分为1024张表。线上部署情况为8个集群(主从)，每个集群4个库。

为什么说这种方式是易于水平扩展的呢？我们分析如下两个场景

场景一：数据库性能达到瓶颈

方法一：

按照现有规则不变，可以直接扩展到32个数据库集群

方法二：

如果32个集群也无法满足需求，那么将分库分表规则调整为(32*2^n)*(32/2^n)，可以达到最多1024个集群

场景二：单表容量达到瓶颈（或者1024已经无法满足你）

方法：

假如单表都已突破200G，200*1024=200T（按照现有的订单模型算了算，大概一万千亿订单，相信这一天，恩，指日可待！），没关系，32*(32*2^n)，这时分库规则不变，单库里的表再进行裂变，当然，在目前订单这种规则下(用userId后四位 mod)还是有极限的，因为只有四位，所以最多拆8192个表，至于为什么只取了后四位，后面会有篇幅讲到。

另外一个维度是通过shopId进行切分，规则8*8和userId比较类似，就不再赘述，需要注意的是shop库我们仅存储了订单主表，用来满足shop维度的查询。

唯一ID方案

这个方案也很多，主流的有那么几种

1、利用数据库自增ID

优点：最简单

缺点：单点风险、单机性能瓶颈

2、利用数据库集群并设置相应的步长(Flickr方案)

优点：高可用、ID较简洁

缺点：需要单独的数据库集群

3、Twitter snowflake

优点：高性能高可用、易拓展

缺点：需要独立的集群以及ZK

4、一大波GUID、Random算法

优点：简单

缺点：生成ID较长，有重复几率

我们的方案：

为了减少运营成本并减少额外的风险我们排除了所有需要独立集群的方案，采用了带有业务属性的方案：

时间戳+用户标识码+随机数

有下面几个好处：

1. 方便、成本低

2. 基本无重复的可能

3. 自带分库规则，这里的用户标识码即为用户ID的后四位，在查询的场景下，只需要订单号就可以匹配到相应的库表而无需用户ID，只取四位是希望订单号尽可能的短一些，并且评估下来四位已经足够

4. 可排序，因为时间戳在最前面

当然也有一些缺点，比如长度稍长，性能要比int/bigint的要稍差等。

其他问题？

• 事务支持：我们是将整个订单领域聚合体切分，维度一致，所以对聚合体的事务是支持的

• 复杂查询：垂直切分后，就跟join说拜拜了；水平切分后，查询的条件一定要在切分的维度内，比如查询具体某个用户下的各位订单等；禁止不带切分的维度的查询，即使中间件可以支持这种查询，可以在内存中组装，但是这种需求往往不应该在在线库查询或者可以通过其他方法转换到切分的维度以实现。

数据迁移

数据库拆分一般是业务发展到一定规模后的优化和重构，为了支持业务快速上线，很难一开始就分库分表，垂直拆分还好办，改改数据源就搞定了，一旦开始水平拆分，数据清洗就是个大问题，为此，我们经历了以下几个阶段

第一阶段：

数据库双写(事务成功以老模型为准)，查询走老模型

每日job数据对账(通过DW)，并将差异补平

通过job导历史数据

第二阶段：

历史数据导入完毕并且数据对账无误

依然是数据库双写，但是事务成功与否以新模型为准，在线查询切新模型

每日job数据对账，将差异补平

第三阶段：

老模型不再同步写入，仅当订单有终态时才会异步补上

此阶段只有离线数据依然依赖老的模型，并且下游的依赖非常多，待DW改造完就可以完全废除老模型了

一些思考：

• 并非所有表都需要水平拆分，要看增长的类型和速度，水平拆分是大招，拆分后会增加开发的复杂度，不到万不得已不使用

• 在大规模并发的业务上，尽量做到在线查询和离线查询隔离，交易查询和运营/客服查询隔离

• 拆分的维度的选择很重要，要尽可能在解决拆分前的问题的基础上，便于开发

• 数据库没你想象的那么坚强，需要保护，尽量使用简单的、良好索引的查询，这样数据库整体可控，也易于长期容量规划以及水平扩展

最后感谢一下棒棒的DBA团队和数据库中间件团队对项目的大力协助！

一致性哈希

编辑

一致性哈希算法在1997年由麻省理工学院提出(参见扩展阅读[1])，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题，使得DHT可以在P2P环境中真正得到应用。

 

中文名

一致性哈希

时    间

1997年

地    区

麻省理工学院

(参见

扩展阅读

目录

1. 1 哈希算法
2. 2 结论

哈希算法

一致性哈希提出了在动态变化的Cache环境中，哈希算法应该满足的4个适应条件：

均衡性(Balance)

平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。

单调性(Monotonicity)

单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲区加入到系统中，那么哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲区中去，而不会被映射到旧的缓冲集合中的其他缓冲区。（这段翻译信息有负面价值的，当缓冲区大小变化时一致性哈希(Consistent hashing)尽量保护已分配的内容不会被重新映射到新缓冲区。）

简单的哈希算法往往不能满足单调性的要求，如最简单的线性哈希：

x → ax + b mod (P)

在上式中，P表示全部缓冲的大小。不难看出，当缓冲大小发生变化时(从P1到P2)，原来所有的哈希结果均会发生变化，从而不满足单调性的要求。

哈希结果的变化意味着当缓冲空间发生变化时，所有的映射关系需要在系统内全部更新。而在P2P系统内，缓冲的变化等价于Peer加入或退出系统，这一情况在P2P系统中会频繁发生，因此会带来极大计算和传输负荷。单调性就是要求哈希算法能够应对这种情况。

分散性(Spread)

在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。

负载(Load)

负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。

从表面上看，一致性哈希针对的是分布式缓冲的问题，但是如果将缓冲看作P2P系统中的Peer，将映射的内容看作各种共享的资源(数据，文件，媒体流等)，就会发现两者实际上是在描述同一问题。

路由算法

在一致性哈希算法中，每个节点(对应P2P系统中的Peer)都有随机分配的ID。在将内容映射到节点时，使用内容的关键字和节点的ID进行一致性哈希运算并获得键值。一致性哈希要求键值和节点ID处于同一值域。最简单的键值和ID可以是一维的，比如从0000到9999的整数集合。

根据键值存储内容时，内容将被存储到具有与其键值最接近的ID的节点上。例如键值为1001的内容，系统中有ID为1000，1010，1100的节点，该内容将被映射到1000节点。

为了构建查询所需的路由，一致性哈希要求每个节点存储其上行节点(ID值大于自身的节点中最小的)和下行节点(ID值小于自身的节点中最大的)的位置信息(IP地址)。当节点需要查找内容时，就可以根据内容的键值决定向上行或下行节点发起查询请求。收到查询请求的节点如果发现自己拥有被请求的目标，可以直接向发起查询请求的节点返回确认；如果发现不属于自身的范围，可以转发请求到自己的上行/下行节点。

为了维护上述路由信息，在节点加入/退出系统时，相邻的节点必须及时更新路由信息。这就要求节点不仅存储直接相连的下行节点位置信息，还要知道一定深度(n跳)的间接下行节点信息，并且动态地维护节点列表。当节点退出系统时，它的上行节点将尝试直接连接到最近的下行节点，连接成功后，从新的下行节点获得下行节点列表并更新自身的节点列表。同样的，当新的节点加入到系统中时，首先根据自身的ID找到下行节点并获得下行节点列表，然后要求上行节点修改其下行节点列表，这样就恢复了路由关系。

结论

一致性哈希基本解决了在P2P环境中最为关键的问题——如何在动态的网络拓扑中分布存储和路由。每个节点仅需维护少量相邻节点的信息，并且在节点加入/退出系统时，仅有相关的少量节点参与到拓扑的维护中。所有这一切使得一致性哈希成为第一个实用的DHT算法。

但是一致性哈希的路由算法尚有不足之处。在查询过程中，查询消息要经过O(N)步(O(N)表示与N成正比关系，N代表系统内的节点总数)才能到达被查询的节点。不难想象，当系统规模非常大时，节点数量可能超过百万，这样的查询效率显然难以满足使用的需要。换个角度来看，即使用户能够忍受漫长的时延，查询过程中产生的大量消息也会给网络带来不必要的负荷。

使用二分查找算法可以将时间复杂度降低为O(log2n)

英文解释

Consistent hashing is a scheme that provides hash table functionality in a way that the addition or removal of one slot does not significantly change the mapping of keys to slots.