消息队列——介绍，应用，功能及常见问题解决方案.pdfVIP

消息队列——介绍，应⽤，功能及常见问题解决⽅案 ⼀、简单介绍 消息队列，⼀般我们会简称它为MQ(Message Queue)，队列是⼀种先进先出的数据结构。 消息队列可以简单理解为： 1. 把要传输的数据放在队列中。 2. 把数据放到消息队列叫做⽣产者 3. 从消息队列⾥边取数据叫做消费者 ⼆、为什么使⽤消息队列（⾯试必问） （1）降低系统耦合性 举个例⼦： 1. 现在我有⼀个系统A，系统A可以产⽣⼀个userId，然后，现在有系统B和系统C都需要这个userId去做相关的操作，系统A给系统B和 系统C传⼊userId。好，现在问题解决了。 2. 然后，某⼀天，系统B的负责⼈告诉系统A的负责⼈，现在系统B的SystemBNeed2do(String userId)这个接⼝不再使⽤了，让系统 A别去调它了。于是，系统A的负责⼈说好的，那我就不调⽤你了。，于是就把调⽤系统B接⼝的代码给删掉了。 3. ⼜过了⼏天，系统D的负责⼈接了个需求，也需要⽤到系统A的userId，于是就跑去跟系统A的负责⼈说： “⽼哥，我要⽤到你的 userId，你调⼀下我的接⼝吧”。于是系统A说： “没问题的，这就搞” 4. 然后，⼜过了⼏天，系统E的负责⼈过来了，告诉系统A，需要userId。⼜过了⼏天，系统B的负责⼈过来了，告诉系统A，还是重新 掉那个接⼝吧。⼜过了⼏天，系统F的负责⼈过来了，告诉系统A，需要userId。 5. 最后，系统A的负责⼈，总是改来改去，特别闹⼼，就跑路了。 然后，公司招来⼀个⼤佬，⼤佬经过⼏天熟悉，上来就说：将系统A的userId写到消息队列中，这样系统A就不⽤经常改动了。为什么呢？ 1. 系统A将userId写到消息队列中，系统C和系统D从消息队列中拿数据。 2. 系统A只负责把数据写到队列中，谁想要或不想要这个数据(消息)，系统A⼀点都不关⼼。即便现在系统D不想要userId这个数据了， 系统B⼜突然想要userId这个数据了，都跟系统A⽆关，系统A⼀点代码都不⽤改。 3. 系统D拿userId不再经过系统A，⽽是从消息队列⾥边拿。系统D即便挂了或者请求超时，都跟系统A⽆关，只跟消息队列有关。 4. 这样⼀来，系统A与系统B、C、D都解耦了。 总结来说 模块之间不存在直接调⽤，那么新增模块或者修改模块就对其他模块影响较⼩，这样系统的可扩展性⽆疑更好⼀些。 消息队列使利⽤发布-订阅模式⼯作，消息发送者（⽣产者）发布消息，⼀个或多个消息接受者（消费者）订阅消息。 消息发送者（⽣产 者）和消息接受者（消费者）之间没有直接耦合，消息发送者将消息发送⾄分布式消息队列即结束对消息的处理，消息接受者从分布式消息 队列获取该消息后进⾏后续处理，并不需要知道该消息从何⽽来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业 务没有任何影响，从⽽实现⽹站业务的可扩展性设计。 另外为了避免消息队列服务器宕机造成消息丢失，会将成功发送到消息队列的消息存储在消息⽣产者服务器上，等消息真正被消费者服务器 处理后才删除消息。在消息队列服务器宕机后，⽣产者服务器会选择分布式消息队列服务器集群中的其他服务器发布消息。 不要认为消息队列只能利⽤发布-订阅模式⼯作，只不过在解耦这个特定业务环境下是使⽤发布-订阅模式的。 除了发布-订阅模式，还有点对点订阅模式 （⼀个消息只有⼀个消费者），我们⽐较常⽤的是发布-订阅模式。 另外，这两种消息模型是 JMS 提供的，AMQP 协议还提供了 5 种消息模型。 （2）通过异步处理提⾼系统性能（削峰、减少响应所需时间） 在不使⽤消息队列服务器的时候，⽤户的请求数据直接写⼊数据库，在⾼并发的情况下数据库压⼒剧增，使得响应速度变慢。但是在使⽤消 息队列之后，⽤户的请求数据发送给消息队列之后⽴即 返回，再由消息队列的消费者进程从消息队列中获取数据，异步写⼊数据库。由于 消息队列服务器处理速度快于数据库（消息队列也⽐数据库有更好的伸缩性），因此响应速度得到⼤幅改善。 消息队列具有很好的削峰作⽤的功能——即通过异步处理，将短时间⾼并发产⽣的事务消息存储在消息队列中，从⽽削平⾼峰期的并发事 务。 因为⽤户请求数据写⼊消息队列之后就⽴即返回给⽤户了，但是请求数据在后续的业务校验、写数据库等操作中可能失败。因此使⽤消息队 列进⾏异步处理之后，需要适当修改业务流程进⾏配合，⽐如⽤户在提交订单之后，订单数据写⼊消息队列，不能⽴即返回⽤户订单提交成 功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚⾄出库后