【消息队列】对于消息队列设计的思考

1.消息可靠性如何保证？

(1)消息的可靠性处理，确认ACK，如果没有ACK就超时重传；
(2)定义序列号，消息序列号是连续的，中间如果发现消息不连续的时候就知道丢了消息；
(3)备份；
(4)持久化RocketMQ.

2.如何从消息的吞吐量方面来设计符合需求的消息队列？

ZeroMQ支持的是百万级别的，RocketMQ支持的是几十万的.
思考：
(1)REQ-ACK模式，能否做到高吞吐量呢？它有什么优点呢？
   这种情况下，能保证的是消息不丢，但是高吞吐量可能就没有办法保证.
   优点就是低时延和确保消息可达.
(2)多次send一次ack的话，能提高吞吐量；
(3)有些MQ说自己的响应速度是毫秒级别和微妙级别的时候,可以注意批量消息传递这个概念，
   批量意味着吞吐量相对较大，但是响应相对较慢.
   可以禁用Nagle算法，开启Quick-Ack.

nagle算法和延迟ACK

3.消息队列的基本概念和原理

ZeroMQ的tcp连接是要求服务器端首先启动的.

rqbbitmq本身是点对点通信，但是可以通过交换机来实现一对多的通信.

消息来的时候，要去应答一下，如果确保客户端的消息不丢失，可以通过配置持久化的功能来实现消息的可靠性.

之后消息处理完再去做应答，保证消息可以处理好.

3.7 发布订阅模型和生产者消费者模型

3.8 消息的同步和异步收发

同步：消息的收发支持同步收发的方式。
同时还有另一种同步方式：同步收发场景下，消息生产者和消费者双向应答模式，例如：
张三写封信送到邮局中转站，然后李四从中转站获得信，然后在写一份回执信，放到中
转站，然后张三去取，当然张三写信的时候就得写明回信地址.
消息的接收如果以同步的方式(Pull)进行接收，如果队列中为空，此时接收将处于同步
阻塞状态，会一直等待，直到消息的到达.
异步：消息的收发同样支持异步方式：异步发送消息，不需要等待消息队列的接收确认；
异步接收消息，以Push的方式触发消息消费者接收消息.

问题：为什么采用发消息异步的方式？
因为如果发一次应答一次,吞吐量肯定会低.比如说数据要持久化，不可能每一条消息都
刷一次硬盘，应该是多条消息刷一次盘.所以我们一般采取的是批量持久化和批量应答.
吞吐量和响应速度是鱼和熊掌，不可兼得.如以下情况：
(1)如果想要发送的消息立刻得到响应，那么响应速度是有了，但是吞吐量就不能保证了.
(2)如何想要批量传送消息，那么吞吐量能够上去，但是时效性就会差一些.

4.可供选择的消息队列产品

 

5.问题

5.1 这些队列都是发布订阅模式吗？

不是的，这些队列大部分都支持配置，可以选择是使用发布订阅模式还是使用生产消费者模式.

6.关键字解释

时延