上一篇
在上一章中，我们主要介绍了规则引擎中最重要的一个部分，自动扩容，在今天的章节，我们主要还是介绍一下我们在淘宝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的规则引擎，使用javaScript来实现跨平台的规则引擎。
从规则引擎来看，他只需要一个引擎，能够运行一个函数就可以了，所以上述平台都可以满足我们的需求，从速度角度考虑，我们选择了可静态编译的groovy和jsv8引擎。
在这个引擎之上，我们对引擎进行了包装，针对淘宝的特殊需求进行了二次开发：
在淘宝，有很大一批数据是需要按照多个条件进行切分的，如，按照用户切库后，按照时间切表等，针对这种需求，我们要扩展原来的函数定义，允许用户使用类似table+”_”+#userid#%1024+”_”+dayofmonth(#gmt#);这样的方式来拼装类似table_0001_23这样的表后缀.实现多维度的切分。同时，还需要满足用户的范围查询需求，如，返回一个用户在某个时间段内的所有数据。这往往意味着可能要遍历多个分表的需求，针对这种需求，我们允许用户使用表达式的方式填入y=F(x)中的’x’,如‘x’=(gmt<=now())and(gmt>’2012-01-01′)这样的输入参数。
针对这样的参数，传统的解决方案是使用排序后的树形结构来满足查询（如hbase），我们认为，因为数据节点的个数本身是有限的，我们没有必要维持复杂的数据结构，只需要使用枚举的方式就可以达到类似的效果，因为颗粒度可控。对于大禹工程
排开数据收集以及分析后展现之外，最重要的部分无疑是能够根据多版本的规则进行自动化的扩容和迁移这一块了。
他的主要流程如下:
举个例子来说明这个流程
从整体来看，大禹在做的事情就是，全量迁移所有需要移动的数据，然后将在全量过程中产生的增量数据append到新节点上，然后部分停写1分钟，推送规则的新版本。完成迁移。
我们假定原来有一台机器，里面有两条记录:
rowa:id=0,name=“a”rowb:id=1,name=“b”切分的规则为id%1,
那么我们根据表达式y0=id%1,分别将id(rowa)=0;id(rowb)=1代入表达式，得到y0(rowa)=0;y0(rowb)=0;这两个结果。然后，我们要将机器扩容为两台，
这时候规则变为y1=id%2,分别将id(rowa)=0;id(rowb)=1代入表达式，得到y0(rowa)=0;y0(rowb)=1;这时候，用户新写入了一条数据rowc:id=3,name=”c”
因为用户在使用老规则写入，所以使用老规则后，数据应该通过老规则计算出结果y0(rowc)=id%1=0;
在按老规则写入后，数据就已经可见了，这时候，大禹会读取这条记录，按照新规则进行计算，y1(rowc)=id%2=1;因为1!=0,所以rowc需要进行迁移，迁移目标是从0机器–>1机器。这时候大禹会将这条数据保存在本地磁盘中。
而如果假定rowd通过新老规则计算出的结果y0(rowc)==y1(rowc)则该数据会被大禹增量复制组件丢弃，因为数据在规则变动后不需要移动位置。
在增量开启后，会进行全量的迁移。
全量的过程与增量类似，是按照选择条件，将老机器内的指定数据遍历一次，对每一条记录，进行老规则和新规则的计算，如果计算结果相同则丢弃，计算结果不同，则将数据写入新规则算出后的结果。当全量结束后，大禹增量复制组件会将记录在本地磁盘中的增量数据覆盖到全量后的数据上，并且继续随着新的数据产生，将数据双写在老规则和新规则所对应的机器上。并发出catchup的状态指令。
在catchup后，我们可以认为，老规则内的数据和新规则内的数据，是异步一致的，中间的数据延迟是异步复制的延迟，一般来说在几百个毫秒内。
这时候，就可以选择一个合适的时机，比如夜里5点，进行部分停写，等待新老数据绝对一致以后，发布新规则。完成迁移。
整个迁移过程，只有最后的“部分停写，等待新老数据绝对一致以后，发布新规则。完成迁移“是会影响业务应用的，这之前的所有过程都是个外加过程，对业务完全没有影响，就算异常失败了，也可以全部放弃掉以后重新来过，这就保证了整套逻辑的尽可能简单清晰。
好的软件就是少做不该做的事情的软件嘛
以上是好的地方，下面来自暴家丑，说说不足。
规则引擎所面向的目标，其实是有状态数据的节点管理，对于节点管理来说，大家的追求一般都是有共识的，也就是说，可以按照需求，随便的增加或减少节点。但遗憾的是，目前在我们的工程实践中，目前还没能很好的解决“随便”这个需求。
所谓随便，就是指可以达到这样一个效果，某天某个监控人员，发现某些数据突然的成为热点了，那么它可以快速反应，点个按钮，上线100台机器，立刻load下降，保证了系统稳定。然后呢，发现某个集群load很低，就点个按钮，下线100台机器作战略储备。
可惜，这样的事情在有状态的机器中是很难做到的，原因很简单，有状态节点的数据迁移是需要成本的，而且成本不小，这也是为什么foursquare会挂的原因。
以上，就是我对淘宝TDDL数据库切分toolkits中规则引擎和配套的自动扩容组件的介绍了。
目前淘宝的TDDL组件被广泛的使用在淘宝300多个不同的业务系统中，并且没有使用过强制命令进行推广。在未来的一个Q内，我们会逐渐的开源我们目前的这套工程实践产品，希望有更多的人能够受益。
下一篇