关于MQ选型( 二 ) _消息队列

在早期的版本中，为了获得极致性能，在设计方面做了很多的牺牲，比如：
不保证消息的可靠性
可能会丢失消息
不支持集群
功能上较简陋
这些牺牲对于处理海量日志这个特定的场景都是可以接受的。这个时期的Kafka甚至不能称之为一个合格的消息队列。
但作为后起之秀。随后Kafka逐步补齐这些短板，你在网上搜到的很多消息队列的对比文章还在说Kafka不可靠，其实这种说法早已过时。当下的Kafka已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求（快手就在使用其作为消息队列）。

文章插图
优点
Kafka与周边生态系统的兼容性最好
尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持Kafka 。
Kafka使用Scala和Java语言开发
设计上大量使用了批量和异步的思想，这种设计使得Kafka能做到超高的性能。可维护性也好，会 java 即可。
Kafka的性能
尤其是异步收发的性能，三者中最好，但与并无量级差异，大约每秒钟可处理几十万条消息。
在有足够的客户端并发进行异步批量发送，并且开启压缩的情况下，Kafka的极限处理能力可以超过每秒2000万条消息。
缺点
但Kafka这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka并不会立即发送出去，而是要等一会儿攒一批再发送，在它的中，很多地方都会使用这种“先攒一波再一起处理”的设计。
当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka的时延反而会比较高。所以，Kafka不太适合在线业务场景。
其它MQ
最老牌的开源消息队列，十年前唯一可供选择的开源消息队列，目前已进入老年期，社区不活跃。无论是功能还是性能方面，都与现代的消息队列存在明显的差距，它存在的意义仅限于兼容那些还在用的爷辈儿系统。
严格来说并不能称之为一个消息队列，而是一个基于消息队列的多线程网络库，如果你的需求是将消息队列的功能集成到你的系统进程中，可以考虑使用。
是一个新兴的开源消息队列产品，最早是由Yahoo开发，目前处于成长期，流行度和成熟度相对没有那么高。与其他消息队列最大的不同是，采用存储和计算分离的设计，我个人非常喜欢这种设计，它有可能会引领未来消息队列的一个发展方向，建议你持续关注这个项目。
目前已经在使用的公司已经不少了,国内的话有下面几家:
涂鸦智能、腾讯计费系统、智联招聘、甜橙金融、EMQX 。
kafka、、、对比
选型总结
最早大家都用，但是现在用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，算了吧，不推荐
后来大家开始用，但语言阻止了大量的java工程师去深入研究和掌控他，几乎处于不可控，但是开源的，比较稳定支持，活跃度也高。如果消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，建议。
如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那的低延迟和金融级的稳定性是你需要的。
【关于MQ选型】如果需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那Kafka是最适合。