消息中间件随着分布式系统的发展变得越来越火，下面就学习课程过程对消息中间件进行记录
文章除了记录课堂的内容还有自己的理解，写完后感觉比较啰嗦，不够清晰明了，毕竟本人水平没有讲课的老师高，等回头自己水平可以了会考虑回来精简一下
概念：（大部分内容引用自：享学课堂课件）
其实并没有标准定义。一般认为，消息中间件属于分布式系统中一个子系统，关注于数据的发送和接收，利用高效可靠的异步消息传递机制对分布 式系统中的其余各个子系统进行集成。
高效：对于消息的处理处理速度快。
可靠：一般消息中间件都会有消息持久化机制和其他的机制确保消息不丢失。
异步：指发送完一个请求，不需要等待返回，随时可以再发送下一个请求，既不需要等待。
一句话总结，我们消息中间件不生产消息，只是消息的搬运工
为什么要用消息中间件？
最初系统设计都是一个整体，业务相对简单，一个war 就可以部署使用，不涉及系统之间通信问题，
但是随着计算机技术的发展， 系统数据量越来越大，业务越来越复杂，一个系统就变得越来越臃肿，难以维护，所以出现了分布式概念，将一个大系统根据业务模块
拆分成多个子系统，每个子系统分别负责不同的业务职能，这时就出现了系统与系统之间的数据频繁交互情况，RPC 就是用来做系统间数据交互，但是由于系统之间直接数据交互依赖性太强，一个子系统出现问题，
它对应的数据交互就会出现问题进而整个系统的出现问题，而且随着系统的不断拓展，子系统越来越多，不同系统之间数据进行交互，越来越混乱，难以管理和维护
所以提出了消息中间件的概念：
无论多少子系统，消息中间件根据与自己的交互情况分成两部分，消息生产者和消息消费者
消息生产者：系统向中间件发送数据，此时系统为生产者
消息消费者：系统向中间件请求数据，此时系统为消费者
当然同一个系统同时存在请求数据和发送数据的情况，那他即时生产者还是消费者（不同的业务场景下角色不一样罢了）
消息中间件出现解决的问题：
1、统一对系统间数据交换进行管理，使得系统间的逻辑层次划分家清晰明了
2、通过消息中间件中进行数据分析统计更加方便
3、解耦合，系统之间通过媒介（消息中间件）间接通信，降低了系统之间的相互依赖
4、异步通信，系统之间交互无需等待对方的回复，只要将消息成功发送到中间件即可（可独立的进行自己的业务，降低系统间依赖）
5、缓冲能力，消息中间件像是一个巨大的蓄水池，将高峰期大量的请求存储下来慢慢交给后台进行处理，避免了大数据量的系统交互出现的系统崩溃问题，对于秒杀业务来说尤为重要。
6、伸缩性，是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。衡量架构是否高伸缩性的主要标准就是：是否可用多台服务器构建集群，
是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制 。
7、扩展性，主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品的透明无影响，不需要任何改动或者很少改动集邮业务功能就可以上线新产品。
消息中间件和RPC（远程系统调用）区别——RPC 就是实现了子系统之间的直接数据交互
1、RPC 同步的，消息中间件是异步的
2、RPC 系统间依懒性太强，消息中间件系统间依赖性较低
消息中间件使用场景（详细解释消息中间件优势的应用）：
1、异步处理
用户注册业务：用户注册，邮件通知，短信通知
传统的业务操作：系统需要先进行用户注册，然后邮件通知，短信通知，三个功能执行完成后，返回结果
消息中间件：系统进行用户注册，然后将注册消息写入消息中间件，然后返回结果，（邮件通知和短信通知——自行进行不影响注册功能具体业务）
优势：将依赖性不强的业务异步处理，提高了业务执行效率
2、应用解耦
客户下单订单生成，库存锁定
传统业务：客户下单完成后，去锁定库存，库存锁定失败，则订单失败
消息中间件：客户下单完成后，将库存锁定消息存入中间件，返回订单成功， ——库存锁定自行执行
优势：增强了用户体验，提高了工作效率
3、流量消峰
订票网站在春节期间特别繁忙，同一时间请求量会非常大，容易引起系统崩溃，
消息中间件可以将某一时刻大量的请求平缓的传送到处理系统，避免系统挂掉
优势：避免服务器崩溃，增长服务器使用寿命，
4、日志处理
日志处理是指将消息队列用在日志处理中，比如 Kafka 的应用，解决大量日志传输的问题。架构简化如下：
日志采集客户端，负责日志数据采集，定时写入 Kafka 队列：Kafka 消息队列，负责日志数据的接收，存储和转发；日志处理应用：订阅并消费 kafka 队列中的日志数据；
消息中间件将日志采集过程和日志处理过程分开，
5、消息通讯
消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。
比如实现点对点消息队列，或者聊天室等。 点对点通讯：客户端 A 和客户端 B 使用同一队列，进行消息通讯。
聊天室通讯：客户端 A，客户端 B，客户端 N 订阅同一主题，进行消息发布和接收。实现类似聊天室效果。
常用消息中间件对比：（引自享学课件）
如果一般的业务系统要引入 MQ，怎么选型： 用户访问量在 ActiveMQ 的可承受范围内，而且确实主要是基于解耦和异步来用的，可以考虑 ActiveMQ，也比较贴近 Java 工程师的使用习惯，但是 ActiveMQ 现在停止维护了，同时 ActiveMQ 并发不高，所以业务量一定的情况下可以考虑使用。
RabbitMQ 作为一个纯正血统的消息中间件，有着高级消息协议 AMQP 的完美结合，在消息中间件中地位无可取代，但是 erlang 语言阻止了我们去深 入研究和掌控，对公司而言，底层技术无法控制，但是确实是开源的，有比较稳定的支持，活跃度也高。 对自己公司技术实力有绝对自信的，可以用 RocketMQ 。
所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 ActiveMQ、RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，几乎是全世界这个领域的事实性规范。
整体上来看，使用文件系统的消息中间件（kafka、rokcetMq）性能是最好的，所以基于文件系统存储的消息中间件是发展趋势。（从存储方式和效 率来看 文件系统>KV 存储>关系型数据库）