微服务架构 (九): 分布式微服务下的数据一致性

最新推荐文章于 2024-08-05 23:37:48 发布

u011790275

最新推荐文章于 2024-08-05 23:37:48 发布

阅读量7.5k

点赞数

文章标签：微服务

本文链接：https://blog.csdn.net/featuresoft/article/details/52268551

版权

本文探讨了在分布式微服务环境中如何通过BASE原则保持数据一致性。介绍了微服务间由于分布式部署导致的数据不一致性和软状态，并提出了四种架构设计方案：批量数据同步、周期性异步数据同步、请求基数据同步和事件基数据同步，分析了各自的优缺点。

摘要由CSDN通过智能技术生成

2016.8.21, 深圳, Ken Fang

微服务都拥有各自的数据库且微服务都是部署在一分布式的环境下的。所以, 微服务间要维持彼此间数据库中的数据的一致性, 便需采用:

BASE – Basic Availability, Soft State, Eventual Consistency。

分布式微服务采用 BASE, 以维持彼此间数据库中的数据的一致性, 主要的思路是: 当某一个微服务 A 改变了其自身数据库中的数据时, 因为, 微服务 A 与其他相关的微服务是分布式部署的, 也就是说, 其他的微服务并不会 (也没办法) 在与微服务 A 相同的数据库交易 (DBTransaction) 中, 知道必需针对自身的数据库, 也做出相对应的改变。

所以, 当微服务 A 改变了其自身数据库中的数据时, 其他相关的微服务, 并未能实时跟进作出相对应的改变; 此时, 整体微服务架构下的相关数据,便形成了不一致性; 我们便称这种不一致性的状态是: Soft State。

当整体微服务架构下的相关数据是 Soft State时, 便需经过一段时间; 也许是几分钟, 也许是一个晚上…等等; 整体微服务架构下的相关数据才能达到一致性。

当整体微服务架构下的相关数据是由 Soft State, 经过一段时间后, 整体微服务架构下的相关数据达到一致性, 我们便称这种一致性的状态是: Eventual Consistency。

举个例子说明下 BASE:

下表中有三个微服务。

三个微服务都同时各自拥有 Customer ID: ABC001 的客户资料。