海量存储之十三.docVIP

海量存储之十三 在上一章中，我们主要介绍了规则引擎中最重要的一个部分，自动扩容，在今天的章节，我们主要还是介绍一下我们在淘宝TDDL中的工程实践吧。 首先从原理开始吧。 先来一张图 这张图以前也出现过，我们在里面着重介绍了规则引擎 规则引擎是什么呢？对应在上述例子里面，其实就是DBNum = pk % 3 这个规则。 他的变化可能很多，比如对于一致性hash则变为一个if – else 的表达式（见前面）也可能有其他的变化。所以，我们要回归本源，问一个问题，什么是规则引擎？ 抽象来看，规则引擎在做的事情是，根据一组输入条件（例如主键id,或者用户id+时间,或者一个rowKey），进行了一种计算，然后返回在某个机器某个表上执行的结果。这种计算要保证，在规则本身不发生变动的情况下，同一组输入条件，返回的永远是相同的结果。 想想这种描述像什么？:-) 我个人认为很像函数的定义，那么让我们换一下表述方式吧:假设输入数据为x(主键id,用户id_时间，或者rowKey) ，经过运算F,返回了该数据在某台机器上这个结果y.那么表达式就是y = F(x) 这是第一层抽象，为了方便表述，我们后面都以这种方式进行表述。 这种规则引擎，在几乎所有“有状态”的数据存储中都会用到，在我们的工程实践中，我们发现这套引擎需要非常灵活的表现能力，才能适应不同用户的不同需求，比如有些场景中，业务方会给出一批经过数据分析以后的大卖家，他们固定的就拥有大量数据，会对其他人造成影响，这时候规则引擎必须能够对各种不同的场景进行适应。 因为规则能够决定数据的分布是否均匀，因此规则是整套系统中最重要的核心组件。 有了规则引擎，我们要追寻的下一个目标就是，如何能够在尽量少的影响业务的正常使用的前提下，改变规则，以达到均衡访问或扩容的目标。 要达到这个规则，第一个需要做的事情就是要能够分辨，哪些数据应该被移动，以及从哪个源头移动到哪个目标去。要解决这个问题，在当时能够想到的方法有两个，一个是定死的规则，比如一致性hash,一致性hash，因为规则本身的入参是定死的，输出也是定死的，所以可以知道从哪里移动到??里。但这也会带来问题，因为有些业务根本不是使用一致性hash来完成的，他们可能有自定义的函数（如：如果卖家id=2000，那么走特殊的机器） 。一旦有这样的自定义函数，那么就很难通过分析规则来获取需要迁移的数据是哪些以及应该从哪里移动到哪里这些属性了。 于是，就必须有另外的方法。 我们采取的方案，是完全放开F，采取多版本的方式来获得“哪些数据应该被移动，以及从哪个源头移动到哪个目标去”，这两个信息。 原理如下: 我们假设有老规则 F0 ,以及新规则F1.对于相同的输入X,我们能得到两个y，也即y0 = F0(x) 以及y1 = F1(x) 对两个y进行比较(compare) ，能够获取两种结果: 结果1 ： y0 == y1. 结果2 ： y0 != y1. 思考这两种结果的含义，不难明白其中的含义：如果y0 == y1,那么意味着，对于相同的数据x，在老规则和新规则中，数据都在同一个库的同一张表上(y相同)，这条数据在老规则换为新规则的时候是不需要移动的。而，如果y0 != y1，那么意味着，这条数据，如果将规则从F0换为F1,则数据需要被移动，移动的方向应该是从y0到y1. 这样，我们就很轻松的使用多版本的方式，获得了“哪些数据应该被移动，以及从哪个源头移动到哪个目标去”，这两个信息。 最后，在知道了上面的两个关键的信息后，还需要一套东西来帮用户把数据尽可能平滑的从一个源机器中移动到目标机器中。 这就是我们在平衡迁移中进行的思考，如果有想探讨的欢迎一起参与。 下面，我们进入工程实践，来看一下我们的规则引擎在做的事情吧。 角色介绍 对于规则引擎，它实现了如下特性：多版本支持只有支持多版本，才能够方便的知道哪些数据应该从哪里移动到哪里去。枚举支持用来支持用户按照日期进行切分，但需要注意的是，这里的日期切分不是传统意义上B树模型的那种切分方式，原因见后续分析。内建多种切分函数支持允许方便的直接使用内置定义的一致性hash,虚拟节点hash等函数方法，减少代码量。 与规则引擎配套的，还有一套我们目前叫做“大禹”的项目工程，他主要完成了以下几件事：切分数据收集能够协助收集用户切分后的数据状态，如访问热点情况，硬件情况等。决策支持能够帮助用户定义新的扩容策略，但我们不做“自动化扩容”，因为扩容本身不是常态。自动迁移能够根据用户的多版本规则，协助用户自动化的进行规则迁移，最终能够将数据迁移导致的不可用时间降低到深夜1分钟内，基本不造成影响。工程实践描述 在我们的工程实践中，我们选择了groovy来实现java的规则引擎，使用jav