ActiveMQ中拉模式与推模式
拉模式(点对点消息)
如果没有消费者在监听队列，消息将保留在队列中，直至消息消费者连接到队列为止。在这种模型中，消息不是自动推动给消息消费者的，而是要由消息消费者从队列中请求获得。
推模式(发布订阅消息)
- 在该模型中，消息会自动广播，消息消费者无须通过主动请求或轮询主题的方法来获得新的消息。
- 消息队列比较核心的应用场合有三个：解耦、异步和削峰
- 在消息队列中一种常用的消息推送类型是推拉模式
推拉模式对比
| 对比项 | push模型 | pull模型 |
|---|---|---|
| 描述 | 服务端主动发送数据到客户端 | 客户端主动从服务端拉取数据，通常客户端会定时拉取 |
| 定时性 | 较好，收到数据后即可发送给客户端 | 一般，取决于pull的间隔时间 |
| 服务端状态 | 需要保存push状态，哪些客户端已经发送成功，哪些发送失败 | 服务端无状态 |
| 客户端状态 | 无需额外保存状态 | 需要保存当前拉取信息的状态，以便于在故障或者重启的时候恢复 |
| 状态保存 | 集中式，集中在服务端 | 分布式，分散在客户端 |
| 负载均衡 | 服务端统一处理和控制 | 客户端之间分配，需要协调机制，比如 zk |
| 其他 | 服务端需要做流量控制，无法最大化客户端处理能力， 其他在客户端故障情况下，无效的push对服务端有一定负载 |
客户端的请求可能是很多无效或者没有数据可供传输 ，浪费带宽和服务器处理能力 |
| 方案缺点 | 服务端的状态存储是个难点，可以将这些状态转移到DB或者key-value存储，来减轻server压力 | 针对实时性问题，可以将push加入进来，push小数据的通知信息，让客户端再来主动pull。 针对无效请求的问题，可以设置逐渐延长间隔时间的策略，以及合理设计协议尽量缩小请求数据包来节省带宽 |
具体的比较
Push模式
推模式是服务器端根据用户需要，由目的、按时将用户感兴趣的信息主动发送到用户的客户端
Push优点：
- 对用户要求低，方便用户获取需要的信息
- 及时性好，服务器端即使地向客户端推送更行的动态信息
Push缺点：
不能确保发送成功：Push模式采用广播方式，只有服务器端和客户端在同一个频道上，推模式才有效，用户才能接收到信息
没有信息状态跟踪：Push模式采用开环控制技术，一个信息推送后的状态，比如客户端是否接收等，无从得知
针对性较差：推送的信息可能并不能满足客户端的个性化需求。
Pull模式
拉模式是客户端主动从服务器端获取信息
Pull优点：
- 针对性强，能满足客户端的个性化需求
- 信息传输量较小，网络中传输的知识客户端的请求和服务器端对该请求的响应
- 服务器端的任务轻。服务器端只是被动接收查询，对客户端的查询请求做出响应
Pull缺点：
- 实时较差，针对于服务器端实时更新的信息，客户端难以获取实时信息
- 对于客户端用户的要求较高，需要对服务器端具有一定的了解。