From c841d19f0db665cee5d75144b8b72fcd749797ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E6=96=B9=E5=9C=86?= <374072213@qq.com>
Date: Mon, 26 Jun 2023 17:38:40 +0800
Subject: [PATCH] =?UTF-8?q?=E5=8E=BB=E6=8E=89=E5=A4=9A=E4=BD=99=E7=9A=84?=
 =?UTF-8?q?=E2=80=9D=E5=9C=A8=E2=80=9C?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ch12.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ch12.md b/ch12.md
index 6f30dba..74c0bac 100644
--- a/ch12.md
+++ b/ch12.md
@@ -377,7 +377,7 @@ Unix 和关系数据库以非常不同的哲学来处理信息管理问题。Uni
 
 一些应用（如即时消息传递与在线游戏）已经具有这种 “实时” 架构（在低延迟交互的意义上，不是在 “[响应时间保证](ch8.md#响应时间保证)” 中的意义上）。但我们为什么不用这种方式构建所有的应用？
 
-挑战在于，关于无状态客户端和请求 / 响应交互的假设已经根深蒂固地植入在在我们的数据库、库、框架以及协议之中。许多数据存储支持读取与写入操作，为请求返回一个响应，但只有极少数提供订阅变更的能力 —— 请求返回一个随时间推移的响应流（请参阅 “[变更流的 API 支持](ch11.md#变更流的API支持)” ）。
+挑战在于，关于无状态客户端和请求 / 响应交互的假设已经根深蒂固地植入在我们的数据库、库、框架以及协议之中。许多数据存储支持读取与写入操作，为请求返回一个响应，但只有极少数提供订阅变更的能力 —— 请求返回一个随时间推移的响应流（请参阅 “[变更流的 API 支持](ch11.md#变更流的API支持)” ）。
 
 为了将写路径延伸至终端用户，我们需要从根本上重新思考我们构建这些系统的方式：从请求 / 响应交互转向发布 / 订阅数据流【27】。更具响应性的用户界面与更好的离线支持，我认为这些优势值得我们付出努力。如果你正在设计数据系统，我希望你对订阅变更的选项留有印象，而不只是查询当前状态。