微服务下的数据一致性思考

标签: 微服务 数据 一致性 | 发表时间:2017-07-20 08:52 | 作者:
出处:https://mp.weixin.qq.com

之前讲到了数据库层缓存层的改造思路,而对于业务层的改造,采用了集中式服务转微服务的架构方案。既然是微服务,就意味着面临大量的服务间的内部调用及服务依赖,这就意味着,如果一次请求的调用涉及到两个或多个微服务之间的调用,恰好有下游的微服务调用失败,我们就必须要考虑到回滚及服务间保证数据一致性的问题。所以,今天我将列出可能出现的失败情况及对应的解决方案,希望对大家正在做微服务改造的团队有所帮助。

首先,我们对微服务间调用做一个分类:

  1. 服务间没有直接依赖,采用异步化调用,上游服务完成后,发一个消息异步通知下游服务,下游服务成功与否对上游服务没有影响。

  2. 上游服务弱依赖于某个下游服务的处理结果,可降级。降级时可以不返回这部分的数据。同步调用降级时转为异步。

  3.  上下游微服务强依赖,上游服务依赖于下游服务的返回或者回调,下游必须正常执行,如果下游服务失败了,本次请求判定为失败。

    

        服务间纯异步调用,需保证幂等性和队列重试机制

        对于Case1, 只需要考虑2点:幂等性和消息队列重试机制,幂等性意味着,重复消息不会对下游服务的结果产生任何影响;消息队列重试机制保证了,消息本身不会出现丢失,即便消息队列在发给下游队列前挂掉了,重启后,能继续发送对应的消息。



       上下游同步执行失败,通过消息执行异步调用

        对于Case2, 采用的方案如下图所示,主服务依赖于A,B,C 三个下游服务,同步调用过程中,服务C调用失败。由于服务C不是强依赖,我们便可以给消息队列发送一条消息,保证主服务可以正常返回,同时保证服务C能继续被执行,保证数据的一致性。

        





    采用TCC进行提交与回滚,保证数据的一致性

    Case3是服务间调用最严格的情况,意味着如果下游服务中有一个服务调用失败,上下游的所有服务必须回滚。意味着服务间必须保证同一个事务。业界公认的一个解决方案就是 TCC (Try-Confirm-Cancel) 模式:

  1. 主业务服务分别调用下游业务执行try操作,并在活动管理器中登记所有下游服务。当所有下游微服务的try操作都调用成功,或者某个下游微业务服务的try操作失败。

  2. 业务活动管理器根据第1步的执行结果来执行confirm或cancel操作。如果之前所有try操作都成功,则活动管理器调用所有下游微业务,执行confirm操作。否则调用所有下游微服务的cancel操作。

  3. 如果第2步,执行confirm或concel操作出现失败,活动管理器会启动重试机制,保证所有微服务最终提交或者回滚操作成功。

    



小结



上文对微服务间调用的3种情况的数据一致性方案做了说明:

1. 确保接口幂等性,消息队列具备重试机制,实际上几乎现在所有的MQ都支持重试。

2. 服务调用同步转异步,确保上游服务成功执行,并保证服务间的数据一致性。

3. 利用TCC方案解决服务间调用强依赖的数据一致性。



 扫描二维码或手动搜索微信公众号: ForestNotes

欢迎转载,带上以下二维码即可

    



相关 [微服务 数据 一致性] 推荐:

微服务下的数据一致性思考

- -
之前讲到了数据库层和缓存层的改造思路,而对于业务层的改造,采用了集中式服务转微服务的架构方案. 既然是微服务,就意味着面临大量的服务间的内部调用及服务依赖,这就意味着,如果一次请求的调用涉及到两个或多个微服务之间的调用,恰好有下游的微服务调用失败,我们就必须要考虑到回滚及服务间保证数据一致性的问题.

消息系统在微服务间通讯的数据一致性

- - 互联网 - ITeye博客
微服务是当下的热门话题,今天来聊下微服务中的一个敏感话题:如何保证微服务的数据一致性. 谈到分布式事务,就避免不了CAP理论. CAP理论是指对于一个分布式计算系统来说,不可能同时满足以下三点: . 一致性(Consistence) (等同于所有节点访问同一份最新的数据副本). 可用性(Availability)(对数据更新具备高可用性).

大数据的一致性

- - 阳振坤的博客
看到了一篇关于数据一致性的文章:下一代NoSQL:最终一致性的末日. (  http://www.csdn.net/article/2013-11-07/2817420 ),其中说到: 相比关系型数据库,NoSQL解决方案提供了shared-nothing、容错和可扩展的分布式架构等特性,同时也放弃了关系型数据库的强数据一致性和隔离性,美其名曰:“最终一致性”.

COMMIT和数据一致性

- - Oracle - 数据库 - ITeye博客
[align=justify; direction: ltr; unicode-bidi: embed; vertical-align: baseline;]2.在执行一条update语句后一直未提交,数据会写到数据文件中吗. 一致性查询及一致性读原理. 如果8点钟可以查询出两条记录,假设一下,如果此查询很慢,从8点开.

微服务架构--服务框架,metrics 和调用链数据

- - 行业应用 - ITeye博客
微服务化以后,为了让业务开发人员专注于业. 务逻辑实现,避免冗余和重复劳动,规范研发. 提升效率,必然要将一些公共关注点推到框架. 服务框架 ( 图 9) 主要封装公共关注点. 服务注册、发现、负载均衡和健康检查,. 假定采用进程内 LB 方案,那么服务自注. 册一般统一做在服务器端框架中,健康检.

关于分布式系统的数据一致性问题

- - 互联网 - ITeye博客
现在先抛出问题,假设有一个主数据中心在北京M,然后有成都A,上海B两个地方数据中心,现在的问题是,假设成都上海各自的数据中心有记录变更,需要先同步到主数据中心,主数据中心更新完成之后,在把最新的数据分发到上海,成都的地方数据中心A,地方数据中心更新数据,保持和主数据中心一致性(数据库结构完全一致).

分布式系统数据一致性的6种方案(转)

- - 企业架构 - ITeye博客
编者按:本文由「高可用架构后花园」群讨论整理而成,后花园是一个面向架构师的增值服务,如需了解,请关注「高可用架构」后回复 VIP.                                                                                 问题的起源.

保证分布式系统数据一致性的6种方案

- - 互联网 - ITeye博客
摘要: 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性. 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要满足要么同时成功;要么同时失败. 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性. 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要满足要么同时成功;要么同时失败.

深入解析DC/OS 1.8 – 高可靠的微服务及大数据管理平台

- - zzm
大家好,欢迎大家参加这次DC/OS的技术分享. 先做个自我介绍,刘超,Linker Networks首席架构师,Open DC/OS社区贡献者,长期专注于OpenStack, Docker, Mesos等开源软件的企业级应用与产品化. 从事容器方面工作的朋友可能已经听说过DC/OS,往往大家误解DC/OS就是marathon + mesos,其实DC/OS包含很多的组件,DC/OS 1.8九月份发布了,此次分享给大家做一个介绍.

提交表单中有文件上传后台如何保证数据的一致性

- - 企业架构 - ITeye博客
在公司开发一个后台管理系统时有这样的需求:提交一个表单时,要把表单域内容和上传的文件内容(可以是多个上传文件)一并提交到后台去,并且数据库持久化失败后数据要回滚且文件不应该上传上去,如果文件上传失败同样数据库也要回滚.  Spring MVC的controller只是将参数包装成DTO,提交给service层一并处理文件上传和数据库保存操作.