应用消息中间件设计能够解决哪些实际问题？

消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。消息中间件到底该如何使用，什么时候使用这是一个问题，胡乱地使用消息中间件增长了系统的复杂度，若是用很差消息中间件还不如不用。

消息队列通信模式

• 点对点通信

点对点方式是最为传统和常见的通信方式，它支持一对1、一对多、多对多、多对一等多种配置方式，支持树状、网状等多种拓扑结构。

• 多点广播

MQ适用于不一样类型的应用。其中重要的，也是正在发展中的是"多点广播"应用，即可以将消息发送到多个目标站点(DestinationList)。可使用一条MQ指令将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息。MQ不只提供了多点广播的功能，并且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户时，MQ将消息的一个复制版本和该系统上接收者的名单发送到目标MQ系统。目标MQ系统在本地复制这些消息，并将它们发送到名单上的队列，从而尽量减小网络的传输量。

• 发布/订阅(Publish/Subscribe)模式

发布/订阅功能使消息的分发能够突破目的队列地理指向的限制，使消息按照特定的主题甚至内容进行分发，用户或应用程序能够根据主题或内容接收到所须要的消息。发布/订阅功能使得发送者和接收者之间的耦合关系变得更为松散，发送者没必要关心接收者的目的地址，而接收者也没必要关心消息的发送地址，而只是根据消息的主题进行消息的收发。在MQ家族产品中，MQEventBroker是专门用于使用发布/订阅技术进行数据通信的产品，它支持基于队列和直接基于TCP/IP两种方式的发布和订阅。

• 群集(Cluster)

为了简化点对点通信模式中的系统配置，MQ提供Cluster(群集)的解决方案。群集相似于一个域(Domain)，群集内部的队列管理器之间通信时，不须要两两之间创建消息通道，而是采用群集(Cluster)通道与其它成员通信，从而大大简化了系统配置。此外，群集中的队列管理器之间可以自动进行负载均衡，当某一队列管理器出现故障时，其它队列管理器能够接管它的工做，从而大大提升系统的高可靠性。

使用消息队列的理由

过去几年中，咱们一直在使用、构建和宣传消息队列，咱们认为它们是很使人敬畏的，这也不是什么秘密。咱们相信对任何架构或应用来讲，消息队列都是一个相当重要的组件，下面是十个理由:

• 1. 1解耦

在项目启动之初来预测未来项目会碰到什么需求，是极其困难的。消息队列在处理过程当中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这容许你独立的扩展或修改两边的处理过程，只要确保它们遵照一样的接口约束。

• 1.2 冗余

有时在处理数据的时候处理过程会失败。除非数据被持久化，不然将永远丢失。消息队列把数据进行持久化直到它们已经被彻底处理，经过这一方式规避了数据丢失风险。在被许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除以前，须要你的处理过程明确的指出该消息已经被处理完毕，确保你的数据被安全的保存直到你使用完毕。

• 1.3 扩展性

由于消息队列解耦了你的处理过程，因此增大消息入队和处理的频率是很容易的；只要另外增长处理过程便可。不须要改变代码、不须要调节参数。扩展就像调大电力按钮同样简单。

• 1.4 灵活性 & 峰值处理能力

当你的应用上了Hacker News的首页，你将发现访问流量攀升到一个不一样寻常的水平。在访问量剧增的状况下，你的应用仍然须要继续发挥做用，可是这样的突发流量并不常见；若是为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列可以使关键组件顶住增加的访问压力，而不是由于超出负荷的请求而彻底崩溃。请查看咱们关于峰值处理能力的博客文章了解更多此方面的信息。

• 1.5可恢复性

当体系的一部分组件失效，不会影响到整个系统。消息队列下降了进程间的耦合度，因此即便一个处理消息的进程挂掉，加入队列中的消息仍然能够在系统恢复后被处理。而这种容许重试或者延后处理请求的能力一般是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。

• 1.6送达保证

消息队列提供的冗余机制保证了消息能被实际的处理，只要一个进程读取了该队列便可。在此基础上，IronMQ提供了一个"只送达一次"保证。不管有多少进程在从队列中领取数据，每个消息只能被处理一次。这之因此成为可能，是由于获取一个消息只是"预约"了这个消息，暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息，不然这个消息会被放回队列中去，在一段可配置的时间以后可再次被处理。

• 1.7排序保证

在许多状况下，数据处理的顺序都很重要。消息队列原本就是排序的，而且能保证数据会按照特定的顺序来处理。IronMO保证消息浆糊经过FIFO（先进先出）的顺序来处理，所以消息在队列中的位置就是从队列中检索他们的位置。

• 1.8缓冲

在任何重要的系统中，都会有须要不一样的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列经过一个缓冲层来帮助任务最高效率的执行–写入队列的处理会尽量的快速，而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流通过系统的速度。

• 1.9 理解数据流

在一个分布式系统里，要获得一个关于用户操做会用多长时间及其缘由的整体印象，是个巨大的挑战。消息系列经过消息被处理的频率，来方便的辅助肯定那些表现不佳的处理过程或领域，这些地方的数据流都不够优化。

• 1.10 异步通讯

不少时候，你不想也不须要当即处理消息。消息队列提供了异步处理机制，容许你把一个消息放入队列，但并不当即处理它。你想向队列中放入多少消息就放多少，而后在你乐意的时候再去处理它们。

消息队列应用场景

如下介绍消息队列在实际应用中经常使用的使用场景。异步处理，应用解耦，流量削锋和消息通信四个场景。

异步处理

如下介绍消息队列在实际应用中经常使用的使用场景。异步处理，应用解耦，流量削锋和消息通信四个场景。

• 场景说明： 用户注册后，须要发注册邮件和注册短信。传统的作法有两种 1.串行的方式；2.并行方式.

• 串行方式： 将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务所有完成后，返回给客户端。

• 并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差异是，并行的方式能够提升处理的时间

假设三个业务节点每一个使用50毫秒钟，不考虑网络等其余开销，则串行方式的时间是150毫秒，并行的时间多是100毫秒。
由于CPU在单位时间内处理的请求数是必定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100）
小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？

引入消息队列，将不是必须的业务逻辑，异步处理。改造后的架构以下：

应用解耦

• 场景说明： 用户下单后，订单系统须要通知库存系统。传统的作法是，订单系统调用库存系统的接口。以下图：

• 传统模式的缺点： 假如库存系统没法访问，则订单减库存将失败，从而致使订单失败，订单系统与库存系统耦合

如何解决以上问题呢？引入应用消息队列后的方案，以下图：

• 订单系统： 用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操做假如：在下单时库存系统不能正常使用。也不影响正常下单，由于下单后，订单系统写入消息队列就再也不关心其余的后续操做了。实现订单系统与库存系统的应用解耦

流量削锋

流量削锋也是消息队列中的经常使用场景，通常在秒杀或团抢活动中使用普遍。应用场景：秒杀活动，通常会由于流量过大，致使流量暴增，应用挂掉。为解决这个问题，通常须要在应用前端加入消息队列。

a、能够控制活动的人数
b、能够缓解短期内高流量压垮应用

用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。
秒杀业务根据消息队列中的请求信息，再作后续处理

日志处理

日志处理是指将消息队列用在日志处理中，好比Kafka的应用，解决大量日志传输的问题。架构简化以下

日志采集客户端，负责日志数据采集，定时写受写入Kafka队列
Kafka消息队列，负责日志数据的接收，存储和转发
日志处理应用：订阅并消费kafka队列中的日志数据

消息通信

消息通信是指，消息队列通常都内置了高效的通讯机制，所以也能够用在纯的消息通信。好比实现点对点消息队列，或者聊天室等

点对点通信：

客户端A和客户端B使用同一队列，进行消息通信。

聊天室通信：

客户端A，客户端B，客户端N订阅同一主题，进行消息发布和接收。实现相似聊天室效果。

以上实际是消息队列的两种消息模式，点对点或发布订阅模式。模型为示意图，供参考。

消息中间件使用案例

电商系统

消息队列采用高可用，可持久化的消息中间件。好比Active MQ，Rabbit MQ，Rocket Mq。

1. 应用将主干逻辑处理完成后，写入消息队列。消息发送是否成功能够开启消息的确认模式。（消息队列返回消息接收成功状态后，应用再返回，这样保障消息的完整性）
2. 扩展流程（发短信，配送处理）订阅队列消息。采用推或拉的方式获取消息并处理。
3. 消息将应用解耦的同时，带来了数据一致性问题，能够采用最终一致性方式解决。好比主数据写入数据库，扩展应用根据消息队列，并结合数据库方式实现基于消息队列的后续处理。

日志收集系统

分为Zookeeper注册中心，日志收集客户端，Kafka集群和Storm集群（OtherApp）四部分组成。

• Zookeeper注册中心： 提出负载均衡和地址查找服务日志收集客户端*：用于采集应用系统的日志，并将数据推送到kafka队列Kafka集群：接收，路由，存储，转发等消息处理Storm集群：与OtherApp处于同一级别，采用拉的方式消费队列中的数据

如下是新浪kafka日志处理应用案例：

1. Kafka ：接收用户日志的消息队列
2. Logstash：作日志解析，统一成JSON输出给Elasticsearch
3. Elasticsearch ：实时日志分析服务的核心技术，一个schemaless，实时的数据存储服务，经过index组织数据，兼具强大的搜索和统计功能
4. Kibana ：基于Elasticsearch的数据可视化组件，超强的数据可视化能力是众多公司选择ELK stack的重要缘由

写在最后：

欢迎你们关注我新开通的公众号【风平浪静如码】，海量Java相关文章，学习资料都会在里面更新，整理的资料也会放在里面。

以为写的还不错的就点个赞，加个关注呗！点关注，不迷路，持续更新！！！