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

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 的客户资料。

微服务

Customer ID

customer information

ABC001

customer wish list

ABC001

customer preference

ABC001

当 customer information 微服务, 被其外部的使用者介面要求: 删去 Customer ID: ABC001 时, customer information 微服务便删去了自身数据库中的 Customer ID: ABC001 的数据。但是, customer wish list 微服务与 customer preference 微服务, 因为, 无法与 customer information 微服务同属于同一个数据库交易 (DB Transaction) 中, 所以, customer wish list 微服务与 customer preference 微服务, 并未实时跟进删除自身数据库中的 Customer ID: ABC001 的数据。

这时, 整体微服务架构下的相关数据, 便形成了如下表中的不一致性; 此时, 整体微服务架构下的相关数据的状态是: Soft State。      

微服务

Customer ID

customer information

ABC001  [已删除]

customer wish list

ABC001   [未删除]

customer preference

ABC001   [未删除]

架构师在 BASE下, 便能采取以下的四种架构设计方案, 使整体微服务架构下的相关数据从 Soft State 时, 经过一段时间后; 也许是几分钟, 也许是一个晚上…等等; 最终, 使得整体微服务架构下的相关数据, 达到一致性; Eventual Consistency。

A.      Batch Data Synchronization:

顾名思义此设计方案, 便是执行一批处理; 也许, 是在夜间执行 :

1.       删除 customer wish list 微服务的数据库中的 Customer ID:ABC001的数据。

2.       删除 customer preference 微服务的数据库中的 Customer ID:ABC001 的数据。

架构师在采用此方案时,必需先行确认: 未维持数据一致性的微服务; customer wish list 微服务与 customer preference 微服务; 是可以接受从 Soft State 到 Eventual Consistency, 需经过一段较长的时间的; 也许是一天, 或甚至是更久。

另外, 架构师在采用此方案时, 也应该清楚的知道: 此设计方案将使得各微服务间的数据库, 因为, 批处理而形成了 “藕合”。

这就代表著, 有任何一个微服务在数据库表节构上的任何的变更, 都将会造成批处理代码 (脚本) 维护上的工作量; 假如, 某一个产品拥有上百或上千个微服务时, 则批处理代码 (脚本) 维护的工作量, 往往会是一不小的负担。

B.      Periodic Async Data Synchronization:

每隔一特定的周期时间; 5分钟, 10 分钟, 一小时…等等; 执行一批处理:

1.       检查 customer information 微服务, customer wish list 微服务, customer preference 微服务, 是否有变更各自所拥有的数据库的数据; 假如, 没有变更, 便进入到下一个周期。

2.       在下一个批处理检查周期到来前, customer information 微服务, 被其外部的使用者介面要求: 删去 Customer ID: ABC001。

3.       下一个批处理检查周期到来, 批处理便执行:

            i.    删除 customer wish list 微服务的数据库中的 Customer ID:ABC001的数据。

            ii.   删除 customer preference 微服务的数据库中的 Customer ID:ABC001 的数据。

此设计方案, 虽缩短了从 Soft State 到 Eventual Consistency, 所需经过的时间, 但, 也是与 Batch Data Synchronization 有著一样的问题: 各微服务间的数据库, 因为, 批处理而形成了 “藕合”。

C.      Request-Based Data Synchronization:

当 customer information 微服务, 被其外部的使用者介面要求: 删去 Customer ID: ABC001时, customer information 微服务便删去了自身数据库中的 Customer ID: ABC001 的数据, 并同时以同步或异步远程调用的方式调用 customer wish list 微服务与 customer preference 微服务; 要求 customer wish list 微服务与 customer preference 微服务, 删除 Customer ID: ABC001。

此设计方案虽因为微服务间直接的同步或异步远程的调用, 而不存在著各微服务间数据库藕合的问题, 但是, 也存在著其他的问题:

1.       当 customer information 微服务, 删去了自身数据库中的 Customer ID: ABC001 的数据后, customer information 微服务便必需要知道, 它需同步或异步远程调用哪些的微服务? 假如, customer information 微服务少调用了一个微服务, 则将使得整体微服务的数据, 很难再维持一致性; 因为, 这样的缺陷, 有时在数百, 甚至是数千个的微服务当中, 是相当不容易被定位到的。

2.       customer wish list 微服务与customer preference 微服务, 将必需要负责处理自身数据库上的事务; 如:回退、确认是否有回传数据库处理确认的信息给 customer information 微服务…等等。这将增加 customer wish list 微服务与 customer preference 微服务在开发与测试上的复杂度。

3.       当 customer information 微服务是采用同步调用 customer wish list 微服务与 customer preference 微服务时, customer information 微服务将必需等待 customer wish list 微服务与 customer preference 微服务回传数据库处理确认的信息, 才能向其外部的使用者介面确认: Customer ID: ABC001 的数据已被成功的删除。而这将使得 customer information 微服务的外部使用者介面, 将花费时间等待; 在性能上可能会有一不好的使用者体验。

4.       customer wish list 微服务与 customer preference 微服务都有著重复的代码, 处理著自身数据库上相同的事务。

D.      Event-Based Data Synchronization:

在微服务的架构中置入 Message Queue; 如:JMS, RabbitMQ。

当 customer information 微服务, 被其外部的使用者介面要求: 删去 Customer ID: ABC001时, customer information 微服务便删去了自身数据库中的 Customer ID: ABC001 的数据, 并同时送出个事件到 Message Queue中; 宣告了customer information 微服务, 刚刚删去了CustomerID: ABC001。

而因为 customer wish list 微服务与 customer preference 微服务订阅了此事件, 所以, customer wish list 微服务与 customer preference 微服务, 便会因为此事件, 而被触发并删除了自身数据库中的 Customer ID: ABC001 的数据。

这设计方案的优点是显而易见的:

customer information 微服务、customer wish list 微服务、customer preference 微服务之间是完全解藕的; 微服务间不存在著数据库间的藕合, 微服务间也不需知道对方是谁?

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT技术精选文摘

程序员必知必会的那些邪恶的脚本

set -o errexit 等价于 set -e,表示有任何错误(命令的返回状态非 0 )时即退出。

1152
来自专栏好好学java的技术栈

java中高级大公司多线程面试题

lock接口在多线程和并发编程中最大的优势是它们为读和写分别提供了锁,它能满足你写像ConcurrentHashMap这样的高性能数据结构和有条件的阻塞。Jav...

892
来自专栏Java架构

Java 10正式发布,最新特性全解读

1734
来自专栏Java成长之路

使用并行流还是CompletableFuture(四)

我们知道,对集合进行计算,可以使用并行和异步的CompletableFuture操作,都可以加快其处理,那么到底该使用并行还是异步呢?

1665
来自专栏数据小魔方

R语言爬虫实战——网易云课堂数据分析课程板块数据爬取

R语言的爬虫生态虽然与Python相比要弱小很多,but,如果你真的想要用R干一些有趣的事情,那么R语言目前所具有的的网络爬取工具也能给你带来很多方便。 今天...

3594
来自专栏友弟技术工作室

程序员必知必会的那些邪恶的脚本

朝圣 前言 程序员必须掌握一定的运维知识。本文通过一些邪恶,搞破坏的方式。教会你一些危险的脚本操作。 附赠 运维意识与运维规范 1.线上操作规范 ...

3337
来自专栏WebHub

用Node.JS分析steam所有的游戏!

最近 Steam 玩得比较多,早晨突然想到一个有趣的问题:买下 Steam 所有游戏要花多少钱?

1452
来自专栏腾讯Bugly的专栏

【MIG专项测试组】腾讯手机管家实战分析:内存突增是为神马?

应用版本升级后使用内存突增?如何跟踪?这次MIG专项测试组为大家分享内存问题跟踪实战过程! MIG专...

3314
来自专栏CSDN技术头条

NewSQL数据库大对象块存储原理与应用

一、前言 企业内容管理(EnterpriseContent Management,ECM)系统是一种管理非结构化内容的系统,传统代表为EMC Document...

2295
来自专栏杨建荣的学习笔记

shell脚本心得(r2笔记58天)

零零星星的接触到写一些shell也有一些日子了,发现自己已经犯了不少的错误,自我总结下。 选择合适的shell shell本身有很多种,大体有如下的几种。 /...

2868

扫码关注云+社区