
将事件驱动架构与现有系统集成
|
49
间歇捕获
数据只能在间歇性轮询中同步,这样对同一个记录的多次独立变更只能体现为一个
事件。
生产资源消耗
查询使用底层系统资源来执行,这会在生产系统上造成不可接受的时延。使用只读副本
可以减轻此问题,但会带来额外的财务成本和系统复杂性。
数据变更导致的查询性能变化
查询和返回的数据量取决于对底层数据所做的变更。在最坏的情况下,每次都会更改整
个数据集。如果某次查询在下一次查询开始时仍未结束,则会出现竞争状态。
4.5
使用变更数据捕获日志解放数据
解放数据的另一种模式是使用数据存储底层的
变更数据
捕获日志(
MySQL
中叫
二进制
日
志,
PostgreSQL
中
叫
预写式
日志)作为信息源。这是一种只追加数据的日志结构,它会详
细记录被跟踪的数据集随时间推移所发生的所有变更。这些变更既包括对记录的创建、删
除和更新,也包括对数据集及其
schema
的创建、删除和更新。
变更数据捕获的技术选项比基于查询的捕获要少。不是所有的数据存储都有实现一份关
于数据变更的持久日志,而在那些支持此能力的数据存储中,也不是全部都有现成的
连接器可用于提取数据。这种方法主要适用于选择型的关系型数据库,比如
MySQL
和
PostgreSQL
,
但是任何具有一套完整的变更日志的数据存储都适用此方法。许多其他现代
数据存储有公开事件
API
,此
API
可充当物理预写入日志的代理
。例如,
MongoDB
提供
了一个变更流接口,而
Couchbase
通过其内部复制协议提供了复制访问。
数据存储的日志不太可能包括从开始到现在的所有变更 ...