消息队列（学习日志）

一，消息模式

基本分为两种模式：

1，点对点：消息生产者向消息队列中发送了一个消息之后，只能被一个消费者消费一次。也就是一条消息智能有一个人接收不能群发。

2，发布和订阅：消息生产者向频道发送一个消息之后，多个消费者可以从该频道订阅到这条消息并消费。（MQTT）

观察者模式就是点对点。
观察者模式与发布和订阅的区别：
观察者：消息生产者与消息消费者都知道对方的存在
发布和订阅：消息生产者不知道消息消费者的存在，因为存在多个消费者，通过频道进行通讯。在MQTT中通过主题进行通讯。

观察者模式是同步的，当事件触发时，主题会调用观察者的方法，然后等待方法返回（这个是必须等待的要不然不知道对方是否得到结果）；而发布与订阅模式是异步的，生产者向频道发送一个消息之后，就不需要关心消费者何时去订阅这个消息，可以立即返回。类似于消息会存放到服务器上。

二，使用场景

1，异步处理

异步处理：生产者，也就是发送者将消息发送给消息队列之后，不需要等待消息接受者把消息处理完，而是直接返回。消息接受者，也就是消费者，从消息队列里面，订阅消息后异步处理。

例如在注册流程中通常需要发送验证邮件来确保注册用户身份的合法性，可以使用消息队列发送验证邮件操作异步处理，用户在填写注册信息之后就可以进行注册，而将发送邮件验证这一消息发送到消息队列中。
就是说，发送邮件之后客户还要填写信息，服务器发送邮件是需要时间的，因此先把发送邮件这个需求记录下来，放到消息队列里面。（这也就是为啥发送验证短信都这么慢的原因了吧）
只有业务允许的条件下才可以使用这种模式。

2，流量削锋

在高并发的场景下，如果短时间有大量的请求到达会压垮服务器。
可以将请求发送到消息队列中，服务器按照其处理能力从消息队列中订阅消息进行处理。

3，应用解耦

如果模块之间不直接进行调用，模块之间耦合度就会很低，那么修改一个模块或者新增一个模块对其它模块的影响会很小，从而实现可扩展性。

通过使用消息队列，一个模块只需要向消息队列中发送消息，其它模块可以选择性地从消息队列中订阅消息从而完成调用。

这三个部分都是在说消息队列的好处。

三，可靠性

1，发送端的可靠性

发送端完成操作后一定能将消息成功发送到消息队列中。

实现方法：在本地数据库建一张消息表，将消息数据与业务数据保存在同一数据库实例里，这样就可以利用本地数据库的事务机制。事务提交成功后，将消息表中的消息转移到消息队列中，若转移消息成功则删除消息表中的数据，否则继续重传。也就是根据消息数据来修改业务数据，然后使消息数据与业务数据绑定一个事务，也就是这个消息数据必须与业务数据共同完成，不能说消息数据我看了，但是业务表没有更改。

2，接收端的可靠性

两种实现方法：
1，保证接收端处理消息的业务逻辑具有幂等性：只要具有幂等性，那么消费多少次消息，最后处理的结果都是一样的。
比如说注册成功，与两次注册成功修改的表的内容是一致的。

2，保证消息具有唯一编号，并使用一张日志表来记录已经消费的消息编号。
不进行重复消费。

那天突然被问到一个问题，当使用消息队列处理视频流中的帧时，你的消息不能被及时的处理而造成了堵塞，应该怎么处理（当时回答使用负载均衡和分布式被否定了），后来想了下，可以使用TCP里面的拥塞控制，也就是慢开始，拥塞避免这些方法进行结合。根据服务器的处理程度来对客户端的视频流进行有选择的处理。毕竟处理的是视频流，可以丢帧，更重要的是同步。虽然也不知道对不对，反正当时是啥都没答上来。