From 0b1590302868b4074b20bd5d31a2944e6bb9eca0 Mon Sep 17 00:00:00 2001 From: Zhaoyang Date: Sat, 1 Jan 2022 10:21:22 +0800 Subject: [PATCH] Update ch12.md --- ch12.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch12.md b/ch12.md index e41ac27..e0fce77 100644 --- a/ch12.md +++ b/ch12.md @@ -373,7 +373,7 @@ Unix和关系数据库以非常不同的哲学来处理信息管理问题。Unix 最近用于开发有状态的客户端与用户界面的工具，例如如Elm语言【30】和Facebook的React，Flux和Redux工具链，已经通过订阅表示用户输入或服务器响应的事件流来管理客户端的内部状态，其结构与事件溯源相似（请参阅“[事件溯源](ch11.md#事件溯源)”）。 -将这种编程模型扩展为：允许服务器将状态变更事件推送到客户端的事件管道中，是非常自然的。因此，状态变化可以通过**端到端（end-to-end）** 的写路径流动：从一个设备上的交互触发状态变更开始，经由事件日志，并穿过几个衍生数据系统与流处理器，一直到另一台设备上的用户界面，而有人正在观察用户界面上的状态变化。这些状态变化能以相当低的延迟传播 —— 比如说，在一秒内从一端到另一端。 +将这种编程模型扩展为：允许服务器将状态变更事件推送到客户端的事件管道中，是非常自然的。因此，状态变化可以通过**端到端（end-to-end）** 的写路径流动：从一个设备上的交互触发状态变更开始，经由事件日志，并穿过几个衍生数据系统与流处理器，一直到观察另一台设备上状态的人的用户界面。这些状态变化能以相当低的延迟传播 —— 比如说，在一秒内从一端到另一端。 一些应用（如即时消息传递与在线游戏）已经具有这种“实时”架构（在低延迟交互的意义上，不是在“[响应时间保证](ch8.md#响应时间保证)”中的意义上）。但我们为什么不用这种方式构建所有的应用？