mirror of
https://github.com/DocsHome/microservices.git
synced 2025-12-08 19:25:13 +00:00
update content
This commit is contained in:
parent
bb00a28f55
commit
cb396f60b2
@ -69,4 +69,26 @@ View,并为每个 Customer 存储一个文档。Customer Order View Query Serv
|
||||
在事件驱动架构中,同样存在着原子更新数据库和发布事件相关问题。例如,Order Service 必须在 ORDER 表中插入一行数据,并发布 Order Created 事件。这两个操作必须原子完成。如果在更新数据库后但在发布事件之前发生服务崩溃,系统将出现不一致性。确保原子性的标准方法是使用涉及到数据库和 Message Broker 的分布式事务。然而,由于上述原因,如 CAP 定理,这并不是我们想做的。
|
||||
|
||||
## 5.4、使用本地事务发布事件
|
||||
实现原子性的一种方式是应用程序使用[仅涉及本地事务的多步骤过程](http://queue.acm.org/detail.cfm?id=1394128)来发布事件。诀窍在于存储业务实体状态的数据库中有一个用作消息队列的 EVENT 表。应用程序开始一个(本地)数据库事务,更新业务实体状态,将事件插入到 EVENT 表中,之后提交事务。一个单独的应用程序线程或进程查询 EVENT 表,将事件发布到 Message Broker,然后使用本地事务将事件标记为已发布。 设计如图 5-6 所示。
|
||||
|
||||

|
||||
|
||||
Order Service 将一行记录插入到 ORDER 表中,并将一个 Order Created 事件插入到 EVENT 表中。Event Publisher(事件发布者)线程或进程从 EVENT 表中查询未发布的事件,之后发布这些事件,最后更新 EVENT 表以将事件标记为已发布。
|
||||
|
||||
这种方法有好有坏。好处是它保证了被发布的事件每次更新都不依赖于 2PC。此外,应用程序发布业务级事件,这些事件可以消除了推断需要。这种方法的缺点是它很容易出错,因为开发人员必须要记得发布事件。这种方法的局限性在于,由于其有限的事务和查询功能,在使用某些 NoSQL 数据库时,实现起来将是一大挑战。
|
||||
|
||||
该方法通过让应用程序使用本地事务更新状态和发布事件来消除对 2PC 的依赖。现在我们来看一下通过应用程序简单地更新状态来实现原子性的方法。
|
||||
|
||||
## 5.5、挖掘数据库事务日志
|
||||
不依靠 2PC 来实现原子性的另一种方式是使用线程或进程发布事件,该线程或进程对数据库的事务或者提交日志进行挖掘。当应用程序更新数据库时,更改信息被记录到数据库的事务日志中。Transaction Log Miner 线程或进程读取事务日志并向 Message Broker 发布事件。设计如图 5-7 所示。
|
||||
|
||||

|
||||
|
||||
使用这种方法的一个示例是 LinkedIn Databus 开源项目。Databus 挖掘 Oracle 事务日志并发布与更改相对应的事件。LinkedIn 使用 Databus 保持与记录系统一致的各种派生数据存储。
|
||||
|
||||
另一个例子是 AWS DynamoDB 中的流机制,它是一个托管的 NoSQL 数据库。DynamoDB 流包含在过去 24 小时内对 DynamoDB 表中的项进行的时间排列的更改顺序(创建、更新和删除操作)。应用程序可以从流中读取这些更改,例如,将其作为事件发布。
|
||||
|
||||
事务日志挖掘有各种好处与坏处。一个好处是它能保证被发布的事件每次更新都不依赖于 2PC。事务日志挖掘还可以通过将事件发布与应用程序的业务逻辑分离来简化应用程序。一个主要的缺点是事务日志的格式对于每个数据库来说都是专有的,您甚至可以在数据库版本之间进行更改。而且,从事务日志中记录的低级别更新可能难以对高级业务事件进行逆向工程。
|
||||
|
||||
事务日志挖掘消除了应用程序在做一件事时对 2PC 的依赖:更新数据库。现在我们来看看另一种可以消除更新并仅依赖于事件的不同方式。
|
||||
**待续……**
|
||||
@ -60,8 +60,8 @@
|
||||
- [5.1、微服务与分布式数据管理问题](5-event-driven-data-management-for-microservices.md#51微服务与分布式数据管理问题)
|
||||
- [5.2、事件驱动架构](5-event-driven-data-management-for-microservices.md#52事件驱动架构)
|
||||
- [5.3、实现原子性](5-event-driven-data-management-for-microservices.md#53实现原子性)
|
||||
- 5.4、使用本地事务发布事件
|
||||
- 5.5、挖掘数据库事务日志
|
||||
- [5.4、使用本地事务发布事件](5-event-driven-data-management-for-microservices.md#54使用本地事务发布事件)
|
||||
- [5.5、挖掘数据库事务日志](5-event-driven-data-management-for-microservices.md#55挖掘数据库事务日志)
|
||||
- 5.6、使用事件溯源
|
||||
- 5.7、总结
|
||||
- 微服务实战:NGINX 与存储优化
|
||||
|
||||
BIN
resources/5-6.png
Normal file
BIN
resources/5-6.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 156 KiB |
BIN
resources/5-7.png
Normal file
BIN
resources/5-7.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 147 KiB |
Loading…
x
Reference in New Issue
Block a user