XeLabs/ddia
2
0
Fork 0
mirror of https://github.com/Vonng/ddia.git synced 2026-06-25 19:06:55 +08:00
Code Issues Projects Releases Wiki Activity

Update ch12.md

Browse source
This commit is contained in:
Zhaoyang 2022-01-01 10:21:22 +08:00 committed by GitHub
parent 9e68549a46
commit 0b15903028
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
ch12.md
View file

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