消息中间件概述

消息中间件解决了什么问题：

          消息中间件更多的用于系统之间的解耦以及操作的异步.

1.JMS消息模型：Queue(点对点)和Topic(发布/订阅)

       1.1 Queue模型：消息从发送端发送出来时不能确定最终会被那个应用消费，但是可以明确的是只有一个应用会去消费这条消息。

      1.2 Topic模型：接收消息的应用1和应用2是可以独立收到所有到达Topic的消息的。

2.消息订阅者订阅消息的方式：非持久订阅和持久订阅

       2.1 非持久订阅：消息接收者和消息中间件之间的消息订阅的关系的存续，与消息接收者自身是否处于运行状态有直接关系。即，当消息接受者停止运行时，这时的消息是不会为消息接收者保留的。

       2.2持久订阅：消息订阅关系一旦建立，除非应用显示地取消订阅关系，否则这个订阅关系将一直存在。如果消息接收者应用停止，那么这个消息也会保留，等待下次应用启动后再投递给消息接收者。

3.使用消息中间所面对的问题：

      3.1 如何解决消息发送一致性：即，业务逻辑执行与发送消息的一致。

             3.1.1解决方案:将要发送的消息存放到Mysql中，存放表结构是：id、消息发送状态（0：未发送mq,1:发送到mq）、消息内容等字段，然后启动一个Task扫这张表中未发送的数据，发送数据到MQ。

      3.2 保证消息可靠性的做法：

             3.2.1 消息发送端可靠性的保证：解决方案如3.1.1

             3.2.2 消息存储的可靠性保证：消息持久化到关系型数据库、NoSql等存储介质中，或者基于双机内存的消息存储。存放到关系型数据库中的表结构实例见：237页

            3.2.3 消息投递的可靠性保证：

                 消息接收者需要特别注意的是，不能在收到消息，业务没有处理完成时就去确认消息。此外，需要特别注意的仍然是消            息接受者在处理消息的过程中对于异常的处理，千万不要吃掉异常然后确认消息处理成功，这样就会“丢”消息了。

               JMS的消息确认方式：

                    3.2.3.1：Auto_AckNowLedge:这是自动确认的方式，就是说当JMS的接收者收到消息后，JMS的客户端会自动进行                      确认。但是确认时可能消息还没来得及处理或者尚未处理完成，所以这种确认方式对于消息投递处理来说是不可靠的。

                    3.2.3.2：Client_AckNowLedge:这是客户端自己确认的方式，也就是说客户端如果要确认消息处理成功，告诉服务端                      确认信息时，需要主动调用Message接口的acknowledge()方法以进行消息接收成功的确认。

                    3.2.3.3：Dups_Ok_AckNowLedge:这种方式是在消息接收方的消息处理函数执行结束后进行确认，一方面保证了消                      息一定是处理结束后才进行确认，另外一方面也不需要客户端主动调用Message接口的acknowledge()方法了。

   3.3  订阅者视角的消息重复的产生和应对：解决方案，在消息接收者的消息处理逻辑中进行幂等验证。