push or pull 推取技术
来源:互联网 发布:sql查询用户名密码 编辑:程序博客网 时间:2024/06/05 16:28
无论是消息系统,还是配置管理中心,甚至存储系统,你都要面临这样一个选择,push模型(推) or pull模型(取)?对比如下:
push模型
描述:服务端主动发送数据给客户端 ;
实时性:较好,收到数据后可立即发送给客户端;
服务端状态:需要保存push状态,哪些客户端已经发送成功,哪些发送失败;
客户端状态:无需额外保存状态;
状态保存:集中式,集中在服务器端;
负载均衡:服务端统一处理和控制
其他:服务器端要做流量控制,无法最大化客户端的处理能力,其次,在客户端故障的情况下,无效的push对服务器端有一定的负载;
缺点方案:服务器端的状态存储是个难点,可以将这些状态转移到DB或者key-value存储,来减轻server压力。
——————————————————————————————————————————————————
pull模型
描述:客户端主动从服务端拉取数据,通常客户端会定时拉取;
实时性: 一般,取决于pull的间隔时间;
服务端状态: 服务端无状态;
客户端状态: 需保存当前拉取的信息的状态,以便在故障或者重启的时候恢复
状态保存:分布式,分散在各个客户端
负载均衡: 客户端之间做分配,需要协调机制,如使用zookeeper
其他:客户端的请求可能很多无效或者没有数据可供传输,浪费带宽和服务器处理能力;
缺点方案:针对实时性的问题,可以将push加入进来,push小数据的通知信息,让客户端再来主动pull。 针对无效请求的问题,可以设置逐渐延长间隔时间的策略,以及合理设计协议尽量缩小请求数据包来节省带宽。
在面对大量甚至海量客户端的时候,使用push模型,保存大量的状态信息是个沉重的负担,加上复制N份数据分发的压力,也会使得实时性这唯一的优点也被放小。使用pull模型,通过将客户端状态保存在客户端,大大减轻了服务器端压力,通过客户端自身做流量控制也更容易,更能发挥客户端的处理能力,但是需要面对如何在这些客户端之间做协调的难题。
(图:)点击打开链接- push or pull 推取技术
- observer, pull or push?
- Push or Pull
- PUSH PULL 技术
- push和pull技术对比
- push和pull技术对比
- push or pull 与hadoop 的机制
- HTTP 推技术(Murphy Push)
- 水晶报表的拉(Pull)和推(Push)模型
- 推挽(Push-Pull) vs 开漏(Open-Drain)
- 推挽(Push-Pull) vs 开漏(Open-Drain)
- GPIO:推挽(Push-Pull) vs 开漏(Open-Drain)
- push pull
- git push & git pull 推送/拉取分支
- git push & git pull 推送/拉取分支
- git push & git pull 推送/拉取分支
- 推式与拉式生产(Push and Pull Production)
- N沟开漏(open-drain)和推挽输出(push-pull)
- 试着做
- 相关文档模板
- 安装Ubuntu后Windows蓝屏问题的解决
- android onTouchEvent和setOnTouchListener中onTouch的区别
- 1013 Digital Roots
- push or pull 推取技术
- setTimeout与js引擎的异步执行
- extjs对话框集锦
- 学习如何在netfilter上开发一个自定义hook
- 相关业务知识
- 数据库的脏数据问题
- convex hull
- linux学习笔记
- c# 判断网络是否连接