这是我参与「第五届青训营 」伴学笔记创作活动的第 6 天
业界热门的一些消息队列：
kafka：分布式的、分区的、多副本的日志提交服务，高吞吐场景下发挥较为出色 RocketMQ：低延迟、强一致、高性能和高可靠、万亿级容量和灵活的可扩展性，在实时场景中运用较广 除了上面两种大家可能经常听到或者看到的以外，还有Pulsar和BMQ，以及RabbitMQ，最后这个我之前有学过，但还是不太理解消息队列，写入笔记记录一下。
kafka常见的使用场景有哪些？
1、搜索服务
2、直播服务
3、订单服务
4、支付服务
5、一些日志信息或者用户行为也会放入消息队列当中
kafka的基本概念：
Topic: 逻辑队列，不同Topic可以建立不同的Topic Cluster: 物理集群，每个集群中可以建立多个不同的Topic Producer: 生产者，负责将业务消息发送到Topic中 Consumer：消费者，负责消费Topic中的消息 ConsumerGroup: 消费者组，不同组Consumer消费进度互不干涉
为什么kafka能支撑高吞吐？
通过压缩减少消息大小，对消息进行批量处理，从而加强发送能力并在写入磁盘时采用顺序写入，提高写入效率。
其实我一直好奇，kafka那么强，没有什么缺点吗？
老师在最后进行了说明，解开了我的疑惑，原来kafka没有自己的缓存，完全依赖于Page Cache，并且会在同一个场景下，某一个partition的数据过多，导致负载不均衡，为了解决这个办法，就需要复制数据，从而增加时间成本，进而引起人力成本过高导致运维成本大大增加。
同时因为负载不均衡的场景，解决方案变得复杂，有时候会感到付出和产出不太成正比，除上述问题以外，如果Controller和Coordinator和Broker在同一进程中时，大量IO会造成性能下降，这就感觉很致命。
总结：
没有任何技术是完美的，消息队列也一样，优缺点需要开发人员衡量，可以根据业务不同，选择相对合适的消息队列。
