浅谈MQ

MQ？what？

MQ被程序员叫做消息中间件，字面意思用来处理处于两方中间消息的一个工具，异步RPC（远程过程调用）。

yes/no

优点：以高并发、高流量系统为出发点，如果数据量并不大使用MQ反而带来后期维护的困难等问题。

1. 降低系统耦合度
2. 消息可靠传递
3. 可以广播传递消息
4. 达到流量削峰

缺点：

1. 系统可用性降低
2. 系统复杂度提高
3. 数据一致性降低

MQ组成

Brocker：消息服务器，用来处理消息的服务器。

Producer：消息生产者

Consumer：消息消费者

Topic：主题，用于发布订阅等模式。

Queue：队列

Message：消息体

RabbitMQ

rabbitMQ是常见的MQ，使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。

应用场景模拟

一个电商项目存在高并发，分布式架构。MQ在其中可以用到子系统之间的互相通讯和流量削峰等。假设在一个秒杀场景，同时秒杀请求10000，而商品只有100个。应该怎么设计这个MQ呢？

这里面要主义的问题有很多。首先肯定是生产借口生成了10000个请求，交给mq,mq再交给消费接口。这里秒就会出现库存、消息丢失等问题。

关于库存我是这么设计的首先库存有100个那么下单时给MQ设计最大的请求为200，达到这个数就直接返回库存不足。实际上库存是不减的在支付时在MQ中按顺序拿请求去访问数据库，这时数据库可以加锁保证不出现多卖的现象（因为已经将数据保持在了一定程度数据库的压力并不大，所以可以加锁处理），支付成功后再减库存。

消息丢失无非三各阶段：

丢失在生产阶段rabbitMQ中有confirm机制可解决这一问题在生产者那里设置开启 confirm 模式之后，你每次写的消息都会分配一个唯一的 id，然后如果写入了 RabbitMQ 中，RabbitMQ 会给你回传一个 ack 消息，告诉你说这个消息 ok 了。如果 RabbitMQ 没能处理这个消息，会回调你的一个 nack 接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息 id 的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。

事务机制和 cnofirm 机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是 confirm 机制是异步的，你发送个消息之后就可以发送下一个消息，然后那个消息 RabbitMQ 接收了之后会异步回调你的一个接口通知你这个消息接收到了。

在MQ中一般不会出现消息丢失，可以在里面进行持久化，而且开启了confirm和持久化就算服务器挂了重启后仍然会获取原来的数据，在这也可以用redis给MQ做一个备份。

消费者消息丢失：关闭自动ack，只有消费者消费成功再手动ack。

待续。。。