RabbitMQ和kafka，Flume

我为什么要选择RabbitMQ ，RabbitMQ简介，各种MQ选型对比

https://www.sojson.com/blog/48.html

 

RabbitMq、ActiveMq、ZeroMq、kafka之间的比较，，

https://blog.csdn.net/qq_35873847/article/details/78737796

 

RabbitMQ 选型和对比

1.从社区活跃度

按照目前网络上的资料，RabbitMQ 、activeM 、ZeroMQ 三者中，综合来看，RabbitMQ 是首选。 

2.持久化消息比较

ZeroMq 不支持，ActiveMq 和RabbitMq 都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了，消息不会丢失的机制。

3.综合技术实现

可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。

RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。当然ZeroMq 也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。

4.高并发

毋庸置疑，RabbitMQ 最高，原因是它的实现语言是天生具备高并发高可用的erlang 语言。

5.比较关注的比较， RabbitMQ 和 Kafka

RabbitMq 比Kafka 成熟，在可用性上，稳定性上，可靠性上，  RabbitMq  胜于  Kafka  （理论上）。

另外，Kafka 的定位主要在日志等方面， 因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以 如果业务方面还是建议选择 RabbitMq 。

还有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出来很多。

选型最后总结：

如果我们系统中已经有选择  Kafka  ，或者   RabbitMq  ，并且完全可以满足现在的业务，建议就不用重复去增加和造轮子。

可以在  Kafka  和   RabbitMq  中选择一个适合自己团队和业务的，这个才是最重要的。但是毋庸置疑现阶段，综合考虑没有第三选择。

kafka

kafka是严格顺序保证的消息队列.kafka优势主要体现在吞吐量上，虽然可以通过策略实现数据不丢失，但从严谨性角度来讲，大不如rabbitmq.Kafka 的定位主要在日志等方面， 因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以 如果业务方面还是建议选择 RabbitMq 。

 

 

https://www.cnblogs.com/bobdeng/p/8431829.html

功能上，两者都是实现了AMQP协议。那么在使用上的最大区别是什么呢？如何根据自己的需求进行选型？

kafka是严格顺序保证的消息队列。即使在分布式环境下，也保证在同一分区内消息的顺序性。既然是顺序的，那么在同一个Topic下面，如果前面的消息没有消费完毕（收到回应），则不能读取下一条消息。那么在消费端，就变成了一个单线程操作，无法并发。虽然kafka可以通过分区实现并发，不过这个需要用多台kafka实现。

还有个办法是在消费kafka消息的时候，消费完立即交给线程池处理，这样可以极大提高并发性。不过这样带来的问题是，如果线程没有处理完机器挂了，就会出现消息丢失的情况，需要在设计上考虑到。

Rabbitmq不承诺消息的顺序性，因此可以并发多线程处理。在队列中不必排队。如果你对顺序处理没有要求，可以用Rabbitmq实现较大的并发。

kafka和rabbitmq对比(超详细，从实战维度比较)

https://blog.csdn.net/myhes/article/details/83247108
实际场景选择

在实际生产应用中，通常会使用kafka作为消息传输的数据管道，rabbitmq作为交易数据作为数据传输管道，主要的取舍因素则是是否存在丢数据的可能；rabbitmq在金融场景中经常使用，具有较高的严谨性，数据丢失的可能性更小，同事具备更高的实时性；而kafka优势主要体现在吞吐量上，虽然可以通过策略实现数据不丢失，但从严谨性角度来讲，大不如rabbitmq；而且由于kafka保证每条消息最少送达一次，有较小的概率会出现数据重复发送的情况；
 

 

Rabbitmq C++客户端（基于rabbitmq-c）

https://blog.csdn.net/LT_lover/article/details/80915711

 

消息中间件—RabbitMQ（集群原理与搭建篇

https://www.jianshu.com/p/6376936845ff

https://www.cnblogs.com/sunzhao/p/8336232.html

关于ActiveMQ、RocketMQ、RabbitMQ、Kafka一些总结和区别

https://www.cnblogs.com/xiapu5150/p/9927323.html

 

微服务中的Kafka与Micronaut

https://blog.csdn.net/Developlee/article/details/103175967?request_id=&utm_source=distribute.pc_feed.none-task

https://forum.huawei.com/enterprise/zh/thread-391447-1-1.html

Flume是一个分布式、可靠和高可用的海量日志聚合系统，可以简单的理解成数据采集工具，本身不具有数据存储功能，数据收集后存储在HDFS或kafka上。跟loader功能类似，Flume适用于实时，loader适用于大量离线数据。
kafka是一个分布式的、分区的、多副本的实时消息发布和订阅系统，生产者将消息发布到kafka，消费者从kafka订阅数据，kafka可以简单理解成一个消息中转系统，具有消息存储的能力，本身就是一个分布式存储系统。

Kafka如何保证消息的可靠性传输

https://www.cnblogs.com/windpoplar/p/10747344.html

1.消费端弄丢了数据

唯一可能导致消费者弄丢数据的情况，就是说，你消费到了这个消息，然后消费者那边自动提交了 offset，让 Kafka 以为你已经消费好了这个消息，但其实你才刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。

这不是跟 RabbitMQ 差不多吗，大家都知道 Kafka 会自动提交 offset，那么只要关闭自动提交 offset，在处理完之后自己手动提交 offset，就可以保证数据不会丢。但是此时确实还是可能会有重复消费，比如你刚处理完，还没提交 offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。

生产环境碰到的一个问题，就是说我们的 Kafka 消费者消费到了数据之后是写到一个内存的 queue 里先缓冲一下，结果有的时候，你刚把消息写入内存 queue，然后消费者会自动提交 offset。然后此时我们重启了系统，就会导致内存 queue 里还没来得及处理的数据就丢失了。

2.Kafka 弄丢了数据