1.什么是消息队列？

1.消息队列是一个队列，先进先出，你无法读取消息队列中间的消息，只能按照顺序，从消息队列的头一个接一个的读，

2,要控制消息队列的权限，example：msmq，加入建立完消息队列但是不给消息队列的权限上加上用户的话，那么这个用户是不可以想这个消息队列发送消息的。

3.消息队列是要分事务性和非事务性的。

2.为什么要使用消息队列？什么情况下会使用消息队列？

个人理解是：实时性要求不高、而且耗时的任务，是队列的最佳应用场景。

example1：在网战注册一个账号，当信息入库注册成功后网站需要发送一个邮件激活，这个激活邮件其实并不是需要实时响应的，没有必要卡在注册页面等待邮件的发送成功，再说发送邮件本身就是一个很耗时的操作（需要第三方smtp服务器），此时选择消息队列去处理。注册完成之后，想消息队列中投递一个消息，消息的内容包含我要发送邮件的一些设置，发送时间，重试次数等消息属性，这里的入库（可以是入库、写入缓存redis）是要消息进入一个实体的队列。其中应该有一进程（消费者）一直在后台运行，它不断地轮询消息队列中的消息（按时间顺序，队列是先进先出），看有没有达到执行条件的，如果有就取出一条，根据消息的配置去执行任务，如果成功，就销毁这条消息，继续轮询，如果失败，则重试，直到达到重试次数，这是用户已经收到注册成功的提示，但是已经去做其他事情了，邮件来了之后，点击邮件激活，注册成功。这个例子是消息队列的一个典型应用。

example2：点赞。这个在高并发的情况下很容易造成数据库链接占满 ，导致整个网站响应缓慢，所以想到解决数据库压力的问题，方法有两种：planA、提高数据库本身的能力（如：增大数据库的连接数量、读写分离等），但数据库的连接数量总是有限的，到达了极限是没有办法再提升的了，此时要考虑planB：释放数据库的压力。将压力转移到缓存里面。用户的点赞到来，我只是讲点赞请求投递到消息队里面，后续的点赞请求可以将消息合并，即只更新点赞数，不产生新的任务，此时有个进程在不断的轮询消息队列，将点赞消息消耗，并将值更新到数据库里面，这样就有效降低了数据库的压力，因为在缓存层将数个数据库更新请求合并成一个，大大提高了效率，降低了负载。

3.应用场景

下面说一下消息队列的具体应用场景

（1）异步处理

还是上述提到的注册发送邮件的例子，用户注册后，需要发注册邮件和注册短信。传统的做法有两种1.串行的方式；2.并行方式。

串行方式：

将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。用时150ms

并行方式：

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

引入消息队列：

将非必须的业务逻辑，异步处理。用时55ms，改造后的架构如下：

可以明显看出消息队列比串行提高了3倍，比并行提高了两倍。

2.应用解耦

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

传统模式的特点：

1）加入库存系统无法访问，则订单减库将失败，从而导致订单失败；

2）订单系统与库存系统耦合；

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

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单成功。

库存系统：订阅下单的消息，采取拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。

假如：在下单时库存系统不能正常使用，也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。

3.流量削峰

流量削峰一般也是消息队列的常用场景，一般在秒杀或团抢活动中应用广泛。

应用场景：秒杀活动，一般会因为流量暴增，应用挂掉。为解决这个问题一般会在前端加入消息队列。    

1.可以控制活动的人数

2.可以缓解短时间内高流量压跨应用。

1）用户的请求，服务器接收后首先写入消息队列。假如消息队列长度超过最大长度，则直接抛弃用户请求或跳转到错误页面；

2）秒杀业务根据消息队列中的请求信息，再做后续处理。

4.日志处理

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

1）日志采集客户端，负责日志数据采集，定时接受写入Kafka消息队列。

2）Kafka消息队列，负责日志数据的接收、存储、和转发；

3）日志处理应用：订阅并消费Kafka队列中的日志数据。

下图是新浪Kafka日志处理应用案例：

(1)Kafka：接收用户日志的消息队列。

(2)Logstash：做日志解析，统一成JSON输出给Elasticsearch。

(3)Elasticsearch：实时日志分析服务的核心技术，一个schemaless，实时的数据存储服务，通过index组织数据，兼具强大的搜索和统计功能。

(4)Kibana：基于Elasticsearch的数据可视化组件，超强的数据可视化能力是众多公司选择ELK stack的重要原因。

（1）Kafka：接收用户日志的消息队列。

（2）Logstash：做日志解析，统一成JSON输出给Elasticsearch。

（3）Elasticsearch：实时日志分析服务的核心技术。一个schemaless实时的数据存储服务，通过index组织数据，兼具强大的搜索和统计功能。

（4）Kibana：基于ElasticSearch的数据可视化组件，超强的数据可视化能力是众多公司选择ElasticSearch的重要原因。

5.消息通讯

消息通讯是指消息队列一般都内置了高效的通讯机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等。

点对点通讯：

客户端A与客户端B同时使用同一队列，进行消息通讯。

聊天室通讯：

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

以上实际是消息队列的两种消息模式，点对点和订阅发布模式。