服务化架构下的数据一致性如何保证

在系统服务化的过程中,我们不得不面临的一个问题是多个子系统间业务数据的一致性如何保证,解决这个问题有多种方式。

XA

可能很多人首先会想到XA规范中定义的分布式事务,下图是XA规范中定义的DTP(Distributed Transaction Processing)模型:

但该模式并不适用于如今的互联网应用,主要有以下几点问题: 1. XA采用2PC,并不能完全保证一致性; 2. 2PC有同步阻塞问题,并且增加了2次RTTs(round trip times),性能低下; 3. 服务化架构天然与DTP模型相悖,服务化架构显然是面向服务的,为了解决数据一致性,直接向对方暴露数据库,这还是服务化吗?

本地消息表+MQ

既然分布式事务不行,我们自然想到了本地事务,可以利用本地事务的ACID特性来保证一致性,数据存储之后,再想办法将数据传输给其它系统,做之后的业务处理,如果处理失败,还可以重试。这个过程实现起来并不难,并且有多种实现方式,但每个系统自己去搞成本还是很高的,所以我们追求的是一种通用且相对优雅的方式。目前业界多数都采用本地消息表+MQ的方式,本地消息表设计成一种通用的结构,与业务模型无关,将其放到业务库同实例上,这样就可以保证业务操作和存储消息在同一个事物内,其它线程读取消息表数据,发送到MQ Server(broker),发送成功则删除数据,失败则保留数据,后续会不断重试,直至成功。随后MQ Server进行广播通知其它系统,做后续处理,如果处理失败,MQ Server负责重试。

上面的流程看起来对业务侵入也比较大,但我们可以通过一些手段来屏蔽这些细节:

  • 首先,我们要搭建一个公共的MQ Server;
  • 其次,我们要预先在业务库去建立一个消息表,可以通过运维的手段解决;
  • 最后,我们要提供一个拆箱即用的Message Producer API,屏蔽发送消息的细节,Message Consumer API直接用MQ原生的即可。
@Transactional
public void doSth(Object obj) {
    xxxDao.insert(obj);// 1.biz operation
    Message msg = buildMessage(obj);
    messageProducer.sendMessage(msg);// 2.store msg
}

这套机制从0搭建起来还是需要较大成本的,但搭建完之后将一劳永逸,算是先苦后甜吧。

RocketMQ

那有没有现成的解决方案呢?答案是有的,那就是今年风头很盛的RocketMQ(已成为Apache顶级项目),RocketMQ在其商业版中提供了事物型消息,所谓事物型消息就是保证了业务操作和发送消息满足一致性(业务操作成功,消息一定发送成功,业务操作失败,消息一定未发送,反之也成立),上面描述的方式(本地消息表+MQ)就可以看作是事物型消息,下面引用一下阿里中间件团队博客中的描述。

这里的事务消息指的其实是数据发送者事务消息,简单而言就是在真正地做业务逻辑之前会发送一条半消息到服务端,接下来发送者会执行本地的事务,在完成本地事务之后,如果成功就会向服务端发送一条确认信息,这时候服务端会将之前的半消息事务状态进行变更;如果失败了,服务端就会不断地回调客户端,来保证发送端的事务一致性。

http://jm.taobao.org/2017/03/09/20170309/

这里的关键点是第三步如果失败,要依靠第四步broker回调客户端来保证一致性,这里猜测一下其大概实现,客户端发送消息前,会添加一个事物检查的实现,并开通一个端口,broker回调时会携带着topic、message等信息,客户端依据message信息和自己的业务数据判定是提交或者回滚,可能有些业务场景依据这两个信息无法判定,那客户端依然要建立本地消息表。

其它方案

其它方案大多缺失普适性,比如TCC(Try/Confirm/Cancel),适用于金融领域。

版权声明 本博客所有的原创文章,作者皆保留版权。转载必须包含本声明,保持本文完整,并以超链接形式注明作者高爽。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏运维小白

10.6 监控io性能

监控系统状态 iostat -x 磁盘使用 iotop 磁盘使用 查看磁盘使用情况 在运维工作中,除了查看CPU和内存之外,磁盘的io也是非常重要的一个指标 ...

1837
来自专栏程序你好

微服务架构中基于DNS的服务发现

1112
来自专栏Spark学习技巧

HBase的region管理

HBase 内置的处理拆分和合并的机制一般是合理的,并且它们按照预期处理任务,但在有些情况下,还是需娶按照应用需求对这部分功能进行优化以获得额外的性能改善。 ...

3797
来自专栏逸鹏说道

分布式小文件系统fastdfs与weedfs的对比

小编小文件存储用的一直是Mongodb,Tair和FastDFS风评一直很不错,最近1年Net界用的比较多的基本上都是FastDFS或者Mongodb(分布式图...

4857
来自专栏博客园

Redis持久化方式

     snapsotting是默认方式,(把数据做一个备份,将数据存储在文件)

953
来自专栏HBStream流媒体与音视频技术

c# 实现p2p文件分享与传输系统

3385
来自专栏程序员互动联盟

【编程基础】初学者如何学习Linux网络

1. Linux网络编程--网络知识介绍 网络程序和普通的程序有一个最大的区别是网络程序是由两个部分组成的--客户端和服务器端. 1.1 客户端 在网络程序中,...

29913
来自专栏程序之美

第一节 netty概述

382
来自专栏SDNLAB

容器有很多优势,但它们是否安全?

容器被誉为是将应用程序部署到服务器上的非常有效的手段。容器(例如基于Docker开源标准的容器)比虚拟机消耗更少的资源,并且容器的设计更容易,且实例化和提供更快...

774
来自专栏后端技术探索

nginx日志request_time 和upstream_response_time区别

笔者在根据nginx的accesslog中$request_time进行程序优化时,发现有个接口,直接返回数据,平均的$request_time也比较大。原来$...

773

扫码关注云+社区