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