去掉多余的”在“

This commit is contained in:
方圆 2023-06-26 17:38:40 +08:00 committed by GitHub
parent e72a594c64
commit c841d19f0d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

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