03 分布式 05 消息中间件：消息中间件入门
1、是什么
1.1. Java Message Service
JMS即Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。
JMS允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。
1.2. 在提到JMS时，我们通常会说到一些术语
解释如下：
（1）消息中间件（JMS Provider) ： 指提供了对JMS协议的第三方组件，比如ActiveMQ就是一个消息中间件，另外比较知名的还有KFA, Rabbit MQ等。
（2）消息模式：分为点对点（Point to Point，即P2P）和发布/订阅（Pub/Sub)，对应的数据结构分别是队列（Queue)和主题（Topic)
（3）消息（Message): 通信内容的载体，其结构主要分为消息头，属性和消息体，并且根据存储结构的不同分为好几种，后面会详细提到。
（4）消息生产者：产生消息的一方，在P2P模式下，指消息发送者(Sender)，在P/S模式下指消息发布者(Publisher)
（5）消息消费者：接收消息的一方，对应于两种模式分别是消息接收者（Receiver）和消息订阅者(Subscriber)
1.3. JMS消息模型(即点对点和发布订阅模型)
（1）Point-to-Point(P2P)
（2）Publish/Subscribe(Pub/Sub)
2、 为什么用
部分业务，不用实时RPC，而使用消息中间件异步处理。
（1）解耦模块；
（2）异步调用；
（3）消息持久化；
（4）消息削峰。
3、 怎么用
3.1. 消息中间件对比
消息中间件区分，转自：中华石杉Java工程师面试突击
3.1.1 ActiveMQ
单机吞吐量：万级
topic数量都吞吐量的影响：
时效性：ms级
可用性：高，基于主从架构实现高可用性
消息可靠性：有较低的概率丢失数据
功能支持：MQ领域的功能极其完备
总结：
非常成熟，功能强大，在早些年业内大量的公司以及项目中都有应用。
偶尔会有较低概率丢失消息。
现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本。
主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用。
3.1.2. RabbitMQ
单机吞吐量：万级
topic数量都吞吐量的影响：
时效性：微秒级，延时低是一大特点。
可用性：高，基于主从架构实现高可用性。
消息可靠性：
功能支持：基于erlang开发，所以并发能力很强，性能极其好，延时很低。
总结：
erlang语言开发，性能极其好，延时很低；
吞吐量到万级，MQ功能比较完备 。
开源提供的管理界面非常棒，用起来很好用。
社区相对比较活跃，几乎每个月都发布几个版本分。
在国内一些互联网公司近几年用rabbitmq也比较多一些 但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。
erlang开发，很难去看懂源码，基本职能依赖于开源社区的快速维护和修复bug。
rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。
3.1.3. RocketMQ
单机吞吐量：十万级
topic数量都吞吐量的影响：topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降。可支持大量topic是一大优势。
时效性：ms级。
可用性：非常高，分布式架构。
消息可靠性：经过参数优化配置，消息可以做到0丢失。
功能支持：MQ功能较为完善，还是分布式的，扩展性好。
总结：
接口简单易用，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景。
而且一个很大的优势在于，源码是java，我们可以自己阅读源码，定制自己公司的MQ，可以掌控。
社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码。
3.1.4. Kafka
单机吞吐量：十万级，最大的优点，就是吞吐量高。
topic数量都吞吐量的影响：topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源。
时效性：ms级。
可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用。
消息可靠性：经过参数优化配置，消息可以做到0丢失。
功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用。
总结：
kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。
同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量。
kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略。
3.1.5. 最后
（1）一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃。ActiveMQ缺点：根据其他用户反馈，会出莫名其妙的问题，切会丢失消息。其重心放到activemq6.0产品—apollo上去了，目前社区不活跃，且对 5.x 维护较少；Activemq 不适合用于上千个队列的应用场景。
（2）后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高。RabbitMQ缺点：erlang语言难度较大。集群不支持动态扩展。
（3）而用RocketMQ，现在确实越来越多的公司使用，确实很不错，但是要想好社区万一突然黄掉的风险。Apache顶级项目。RocketMQ缺点：产品较新，文档比较缺乏。没有在 mq核心中去实现JMS 等接口，对已有系统而言不能兼容。阿里内部还有一套未开源的 MQ API，这一层 API可以将上层应用和下层 MQ 的实现解耦（阿里内部有多个 mq的实现，如 notify、作者 何鹏 关注分布式存储与计算相关框架，包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等 [email protected]，metaq2.x，rocketmq 等），使得下面 mq 可以很方便的进行切换和升级而对应用无任何影响，目前这一套东西未开源。
（4）如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择。
Rocketmq 的前身为 metaq， metaq 的第一个版本是可以看成是 linkedin 的 kafka（scala）的 java 版本，并对其增加了事务的支持。 rocketmq 为 metaq3.0， 相比于原始 kafka，其擅长点出了原始的 log collecting 之外，还增加诸如HA、 事务等特性，使得从功能点上讲， 可以替代传统大部分 MQ。
目前已经在阿里开始大规模应用，并且预计未来会逐渐在阿里取代 notify， meta 2.x 以前的所有队列。 由于rocketmq 还比较新，且官方没有给出相应的 benchmark。 而 rocketmq 社区主要活跃者均是中国国内人员，因此不便于直接对比 rocketmq 和其他队列。在这里用 kafka 和其他队列进行对比， rocketmq 的性能比 kafka 还要好一些。
Kafka需要依赖Zookeeper。Rocketmq不需要，自身实现了Nameserver。
在Kafka里面，Maser/Slave是选举出来的！！！RocketMQ不需要选举！！！
在Kafka里面，Maser/Slave是选举出来的！！！RocketMQ不需要选举！！！
在Kafka里面，Maser/Slave是选举出来的！！！RocketMQ不需要选举！！！
重要的话说三遍。具体来说，在Kafka里面，Master/Slave的选举，有2步：第1步，先通过ZK在所有机器中，选举出一个KafkaController；第2步，再由这个Controller，决定每个partition的Master是谁，Slave是谁。
这里的Master/Slave是动态的，也就是说：当Master挂了之后，会有1个Slave切换成Master。
而在RocketMQ中，不需要选举，Master/Slave的角色也是固定的。当一个Master挂了之后，你可以写到其他Master上，但不会说一个Slave切换成Master。
这种简化，使得RocketMQ可以不依赖ZK就很好的管理Topic/queue和物理机器的映射关系了，也实现了高可用。