document/ddia
2
0
Fork 0
mirror of https://github.com/Vonng/ddia.git synced 2024-12-06 15:20:12 +08:00
Code Issues Packages Projects Releases Wiki Activity

refactor(cp11): update #变更数据捕获的实现

Browse Source 
原文：Like message brokers, change data capture is usually asynchronous: the system of
record database does not wait for the change to be applied to consumers before com‐
mitting it.

现有：像消息代理一样，变更数据捕获通常是异步的：记录数据库系统不会等待消费者应用变更再进行提交。

建议：类似于消息代理，变更数据捕获通常是异步的，即系统记录数据库在提交变更之前不会等待消费者应用变更。

是否翻译为以上形式，保留原文意思，更容易理解？我第一次读到这里读了几次没反应过来。
This commit is contained in:
Líng Yàomíng 2023-04-04 15:59:40 +08:00 committed by GitHub
parent 209e9dc0a1
commit 2db8227dca
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
ch11.md
View File

@ -260,7 +260,7 @@ Apache Kafka 【17,18】、Amazon Kinesis Streams 【19】和 Twitter 的 Distri
LinkedIn 的 Databus【25】，Facebook 的 Wormhole【26】和 Yahoo! 的 Sherpa【27】大规模地应用这个思路。 Bottled Water 使用解码 WAL 的 API 实现了 PostgreSQL 的 CDC【28】，Maxwell 和 Debezium 通过解析 binlog 对 MySQL 做了类似的事情【29,30,31】，Mongoriver 读取 MongoDB oplog【32,33】，而 GoldenGate 为 Oracle 提供类似的功能【34,35】。
像消息代理一样，变更数据捕获通常是异步的：记录数据库系统不会等待消费者应用变更再进行提交。这种设计具有的运维优势是，添加缓慢的消费者不会过度影响记录系统。不过，所有复制延迟可能有的问题在这里都可能出现（请参阅 “[复制延迟问题](ch5.md#复制延迟问题)”）。
类似于消息代理，变更数据捕获通常是异步的：系统记录数据库在提交变更之前不会等待消费者应用变更。这种设计具有的运维优势是，添加缓慢的消费者不会过度影响记录系统。不过，所有复制延迟可能有的问题在这里都可能出现（请参阅 “[复制延迟问题](ch5.md#复制延迟问题)”）。
#### 初始快照