一、kafka
1、不完全符合jms规范，注重吞吐量，类似udp 和 tcp
2、一般做大数据吞吐的管道 我们现在的用途就是负责在各个idc之间通信
3、量大对数据不是百分之百保证的，会有数据丢失，不是百分百送达（amq和rmq等有重发机制，而kafka没有）；在吞吐量有提升 ，在这方面就得有牺牲， 所以kafka适合大数据量流转， 比如日志数据 比如用作统计的数据。
二、activeMQ
ActiveMQ居于两者之间，类似于ZemoMQ，它可以部署于代理模式和P2P模式。类似于RabbitMQ，它易于实现高级场景，而且只需付出低消耗。它被誉为消息中间件的“瑞士军刀”。
三：RocketMQ（阿里官方指定消息中间件）
RocketMQ 是一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。同时，广泛应用于多个领域，包括异步通信解耦、企业解决方案、金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、移动应用、手游、视频、物联网、车联网等。
消息中间件使用的典型场景优四个
- 1.典型的异步处理
- 2.应用解耦
- 3.流量削锋
- 4.消息通讯四个场景
比如：今日头条的私信就是一个典型的消息通讯场景，因为消息通讯的数据不需要即使立即同步回来，不算是核心数据，可以延时通过异步的消息发送，这样可以降低系统的负荷。
所以，我们在架构设计的时候，有一个原则就是：消息原则上都是异步消息发送，除非涉及到交易的情况才考虑数据即使同步，否则能异步的都采用异步消息设计。
再比如：流量削锋的典型场景就有阿里的双11秒杀、团购抢购活动等。
应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。
- a、可以控制活动的人数
- b、可以缓解短时间内高流量压垮应用
用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。
秒杀业务根据消息队列中的请求信息，再做后续处理。
总结：
1.消息中间件的四个典型场景：典型的异步处理、应用解耦、流量削锋、消息通讯四个场景。
2.能异步就不要同步：能异步的消息原则都尽量采用异步的方式。
3.如果消息性能要求高，用rocketMQ与kafka可以更优，rocketMQ与kafka 比较就看技术选型了，各有利弊，看业务需要。
4.实现语言来看，RabbitMQ(阿里官方指定消息中间件)最高，原因是它的实现语言是天生具备高并发高可用的erlang语言。综合来看，RabbitMQ是首选。
5.典型的秒杀活动、抢购、消息通讯、邮件发送、电话短信等都是典型的采用消息中间件的业务场景。
本文由博客一文多发平台 OpenWrite 发布！
