司马南近况
如果说「共识」解决的是「水平」问题,那么「事务」解决的就是「垂直」问题,是如何让一条绳上的蚂蚱共同起舞。
事务只是一个计算机术语,其实事务的体现形式在我们生活中也无处不在。任何我们认为应该是这样的事情,去确保它达到预期的过程就是「事务」。往小了说,我们平时在走的时候,向前摆动左手的同时抬右腿,如果不是这样的话就是不一致,别人会说你走不协调。所以我们小时候父母会通过各种方式我们这个,这些各式各样的方式就好比我们在软件开发中去实施「事务」一样,一题是多解的。
提到事务不得不提到「XA规范」[1],这是分布式还没大行其道的时期,被大多数的数据库作为其内部分布式事务实现的接口标准。
「XA规范」就是上图中「RM」和「TM」的交互规范和接口定义。仅仅是定义了xa_和ax_系列的函数原型以及功能描述、约束和实施规范等,并不包括的实现方式。后面会提到的两阶段提交(2PC)是「TM」协调「RM」们完成事务的方法。
所以其实可以说,事务起源于数据库,辉煌于分布式系统。在摩尔定律还适用的时候,软件系统为了承载更大的流量或者说用户数,开始运用「分治」的思想来设计。然后随着互联网的蓬勃发展,B/S应用大行其道的背景下,分布式系统越来越常见。并且随着一个个巨无霸互联网公司的出现,越来越被鼓吹和传颂。
能被的永远是有益的一面,再加上耀眼的数据:多少TPS、多少QPS,更眼球。但是这背后为了让「分治」后的系统能够尽可能的像单个个体一样运作,各类专家学者们通过多年研究,才有了如今的各种著名理论和解决方案。
正如前面所说,事务问题其实一直存在,只是在分布式系统中被放大了。并且随着系统拆分的粒度越细,问题的复杂度成指数上升。
举个不是特别严谨的例子,这就好比要实现一个系统不能产生BUG(C),并且10天内完成上线(A),以及需要多人团队一起协作进行(P)。我们做开发的也很清楚这三者是无法兼得的。况且只要是一个组织,团队协作是无法避免的,正如这里的分区性一样,比如得考虑人员请假的问题。
剩下的2项,如果说可以达到没有BUG的话,那就是时间无限延长,但也只是无限趋近于0,并不能达到线,因为没有人可以发现了所有的BUG。
「BASE」理论是由时任ebay架构师的Dan Pritchett提出的[4],本质上就是对「线性一致性」的弱化。弱化的方式正如上一篇文章的「顺序一致性」和「最终一致性」。(关于这两种一致性的解释,点《上篇》可阅读)
「BASE」理论的提出并不是取代「CAP」理论,不是让我们在实际的工作中完全撇开「线性一致性」,而是引导我们可以区分核心和非核心,然后分别对待,核心部分还是需要用CAP理论来「线性一致性」。
为什么要区别对待?根本上还是无法「线性一致性」带来的巨大性能损耗,因为它是反可伸缩性的。但只要是涉及到Money之类的高数据的操作部分,还是必须「线性一致性」。
便于理解,还是用的例子:我们侧重于降低核心功能的BUG,不花过多精力在非核心功能上(BA)。我们允许产生不影响核心功能的BUG(S),但是必须最终要修复(E)。
如果说「CAP」理论和「BASE」理论是「道」,那么围绕这两个理论演化的解决方案就是「术」。对我们来说,最重要的事是在实际的运用中根据所处的场景找到最合适的。
以「CAP」为基础的强一致性解决方案都会引入一个类似“协调器”的东西来作为全局事务的掌控者,可以来看一下:
只是在我们打破了链式规则后必须要额外确保执行了「回滚」之后再接收到「正向请求」,等于“请求无效”的效果。中心节点模式还有一个比较大的好处是能够更好的避免事务之间的循环依赖关系。
额外提一下,这个其实是一个具体的、运用BASE理论实现的协议,借由Cassandra的热火而让更多人知道了。这协议一般会用于数据复制、P2P拓扑构造、故障探测等。
看这些案例我们可以发现,基于「CAP」的解决方案都是在线的,而「Base」是允许离线的。好比前者是,累倒了必须得马上爬起来继续干活,要不然就是失败。而后者是,慢慢来,只要最终能干完。
不管怎样,如果每个解决方案中增加「重试」和「回滚」,会大大提升程序的修正能力,以降低需要人为介入的比例。识别是否需要人为介入的方式就是类似于「对账」的机制,这个机制就是兜底的。最后还需要做一道选择题来防止混乱:确保参与者的接口符合「幂等性」,或者在中间件里做到「正好一次(Exactly-once)」。
这些基于「BASE」的解决方案都是可以作为「CAP」解决方案出现问题时的PlanB来用的,起到补充作用。当然,如非必要,可以优先考虑基于「BASE」的方案,毕竟这才是天然易伸缩的,自然也能带来更好的性能。
解决方案如此多,所以不管我们是架构师、还是在成为架构师的上,甚至在日常生活中,都需要养成Balance的习惯,找到那个最适合的方案。
「事物都具有两面性」,所以,在选择分布式之前,慎重考虑下是否有必要,以免给自己徒增麻烦。
网友评论 ()条 查看