数据一致性-对帐

引子架构

妈妈要个人时候已经40岁了。她必定是下了很大的决定才决定终究仍是想要个女孩,但愿这个女孩能够解救她的孤独。上高三的时候,有次又是由于哥哥的事情,妈妈把我从学校接回家。一个劲儿的问我怎么办好。在我能和她一块儿思考前的50多年里,她该是多么无助。因此当我不断看本身的掌纹,上面的起起伏伏。在想这一切解释不通的苦难何时过去。在想是否是在天堂的妈妈安排了这一切,由于理解她的痛苦是个人使命。我错了,她不是在天堂安排了这一切,是在我很小的时候。我为理解她而生,这是个人命运。命运并非很深奥的东西,只是一个发展脉络。比如作金融领域,和清算、结算、对帐打交道就是命运。对帐原本用在金融领域,逐渐扩大到数据一致性领域。比如弹性工程,原本是航天领域的术语。逐渐演变为构造高可用工程的方法,方法的核心是经过提出边界场景(失败、风险、意外事件)问题,而后从检测、补救、预防几个维度去思考答案,最终反哺到系统设计开发与流程改善上,倒逼架构和流程SOP改进,再结合预案演练达到扼杀故障和缩短故障时间的目的。

概念异步

一致性分为强一致性和弱一致性。
强一致性的协议和手段主要有:二阶段提交(2PC)、三阶段提交(3PC)、TCC(Try-Confirm-Cancel)补偿型。这里面常常有人把两阶段提交和TCC补偿型混淆。二阶段提交实际上业务逻辑是在提交以前作的,两阶段只是事务控制的两个阶段。而TCC是将业务逻辑分为try、confirm和cancel三个阶段。举个例子:好比一我的要预售苹果,有两种销售策略。一种让用户先付钱,根据用户需求量准备足够的苹果。另外一种是让用户先付钱同时声明到时候先到先得,没抢到的就退款。第一种就是二阶段提交,第二种就是TCC。弱一致性在分布式系统中经常使用的是一种特例:最终一致性。在工做中,最终一致性一般经过补单和对帐来解决。补单主要指在运行时同时检查返回值,若是返回值为失败,会从新处理(补单处理)。
对帐主要分为两个阶段:数据核对和差错处理。数据核对就是对帐中的轧帐。注意「轧」这里念「ga」二声。差错处理就是对帐中的平帐。

 

 

 

应用分布式

以秒杀场景为例说明一下对帐的经常使用流程。

对帐依据和标准设计

对帐问题最早解决的问题是对帐依据和标准。好比秒杀场景,对帐依据就是订单号,整个链路采用惟一内部订单号。对帐标准能够设定为对用户的承诺。就是说:一次秒杀活动结束,若是给用户的结果是成功,那么实际上超卖了,那就本身补货解决。若是给用户结果是失败了,实际上有不少没卖出去,那就是没卖出去放着。总之,我承诺给用户的结果必定要履行。若是数据核对时,各个环节结果不一致,最终结果向用户的承诺对齐。

对帐梳理blog

能够从明细和总数两个方面来作对帐。在秒杀场景中,明细是一条条请求订单。总数是成功和失败了多少个请求,买出多少库存。明细对帐主要用于定位问题。总数对帐是兜底策略,用来解决「怎么证实本身是对的」的问题。

对帐时机事件

分为在线对帐和离线对帐。在线对帐又分为实时对帐和准实时对帐。实时对帐就是好比秒杀成功了,那下游的每一步都须要是成功的,其余状况如超时等则采用重试来进行强一致性保证。准实时对帐一般用异步来实现。在秒杀的场景,若是订单返回失败,能够异步发起一个任务进行退款,若是退款不成功则能够用屡次重试进行补单。 离线对帐就是平时所说的定时任务。这个对帐方法就比较多了,自由发挥空间比较大。特别是在轧帐场景中,由于不实际修改数据,风险低,不少新技术试用能够选择在此模块进行。
相关文章
相关标签/搜索