From 2db8227dca2cea300a6ee6fa32aa5f50549aec23 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=ADng=20Y=C3=A0om=C3=ADng?= <86768220+spike014@users.noreply.github.com> Date: Tue, 4 Apr 2023 15:59:40 +0800 Subject: [PATCH 1/2] =?UTF-8?q?refactor(cp11):=20update=20#=E5=8F=98?= =?UTF-8?q?=E6=9B=B4=E6=95=B0=E6=8D=AE=E6=8D=95=E8=8E=B7=E7=9A=84=E5=AE=9E?= =?UTF-8?q?=E7=8E=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 原文: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. 现有:像消息代理一样,变更数据捕获通常是异步的:记录数据库系统不会等待消费者应用变更再进行提交。 建议:类似于消息代理,变更数据捕获通常是异步的,即系统记录数据库在提交变更之前不会等待消费者应用变更。 是否翻译为以上形式,保留原文意思,更容易理解?我第一次读到这里读了几次没反应过来。 --- ch11.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch11.md b/ch11.md index d20c8f5e..7b8f2bfc 100644 --- a/ch11.md +++ b/ch11.md @@ -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#复制延迟问题)”)。 #### 初始快照 From 6449ab38dae0ac4b4ea8dff53629a09cfa8bc0c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?L=C3=ADng=20Y=C3=A0om=C3=ADng?= <86768220+spike014@users.noreply.github.com> Date: Tue, 4 Apr 2023 16:03:59 +0800 Subject: [PATCH 2/2] Update ch11.md --- ch11.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch11.md b/ch11.md index 7b8f2bfc..92f75c98 100644 --- a/ch11.md +++ b/ch11.md @@ -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#复制延迟问题)”)。 #### 初始快照