Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

数据的「推」与「拉」

  理论上,对于「推」和「拉」的选择可以根据数据的更新频率决定。写频繁的数据应该用「拉」的,因为如果实时推送会造成大量的传输冗余。读频繁的数据则应该用「推」的,否则为了确保实时性就需要投入大量的传输成本来验证。但理论毕竟是理论,实际项目中的方案选择可没有那么简单。
  其实「推」与「拉」并不是同等的存在,很多时候「推」的开发和维护成本要比「拉」的成本高得多,这和程序的调用方式有关。一般的 RPC 调用都是基于请求和响应的,这决定了 RPC 调用更适合实现「拉」的逻辑。
  对于「推」的逻辑,推送方需要知道到底有哪些接收方。而且接收方并不总是在线,所以接收方每次上线还需要执行一次「拉」的操作来同步到最新状态。也就是说,如果想实现推的逻辑,服务不仅要实现一套「拉」的逻辑,还要有一套订阅和发布进制来实现。而且为了回收无效的订阅,还需要有注销订阅和健康检查等一系列行为。
  以上这一坨话听起来好像已经很复杂了,然而这只是最基本的而已。要实现一个完美的「推」,还要考虑上各个过程的延迟、推送失败、节点之间数据不同步的补偿机制等一系列繁琐的细节。
  虽然很多场景下「推」比「拉」更适合,但一些实现也会宁愿放弃实时性也不去实现真正的「推」。总之「推」是比「拉」复杂得多的东西,只有在能够接受这种维护成本的团队中才会考虑引入「推」,否则都会使用「拉」来实现。
网名:
23.20.64.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^