Kafka、rabbitmq及rocketmq的区别

Kafka、rabbitmq及rocketmq的区别

Kafka采用拉取（pull）方式消费消息，吞吐量相对更高，适用于海量数据收集与传递场景，通常用于日志采集和集中分析。

RabbitMq在吞吐量方面略有逊色，但支持更多的消息队列功能。

RocketMQ出自 阿里公司的开源产品，用java语言实现。在设计时参考了Kafka，并且做出了自己的一些改进。在阿里集团被广泛应用于订单、交易充值、消息推送、日志流式处理、binglog分发等场景。

以下分别从性能、数据可靠性、服务可用性、功能等方面进行具体分析 性能：

QPS：吞吐量 Broker：服务器

消息中间件的性能主要衡量吞吐量，Kafka的吞吐量比RabbitMq要高出1~2个数量级，RabbitMq的单机QPS在万级别，Kafka的单机QPS能够达到百万级别。RocketMq单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节，Kafka如果开启幂等、事务等功能，性能也会有所降低。

TPS：每秒的事务数量

幂等性：由于Producer在生产发送消息时，难免会重复发送消息。Producer进行retry时会产生重试机制，发送消息重复。而引入幂等性后，重复的消息只会生成一条有效的消息。

kafka的事务：与数据库的事务类似，Kafka中的事务属性是指一系列的Producer生产消息和消费消息提交Offsets的 *** 作在一个事务中，即原子性 *** 作，对应的结果是同时失败或者同时成功。 *** 作数据库中的事务指一系列的增删改查，对Kafka来说， *** 作事务是指一些列的生产和消费等原子性 *** 作。

数据可靠性：

Kafka与RabbitMQ都具备多副本机制，数据可靠性较高。RocketMQ支持异步刷盘、同步刷盘、同步Replication、异步Replication。

Replication：复制

服务可用性：

Kafka采用集群部署，分区与多副本的设计，使得单节点宕机对服务无影响，且支持消息容量的线性提升。RabbitMQ支持集群部署，集群节点数量有多种规格。RocketMQ是分布式架构，可用性高。

功能：

Kafka与RabbitMQ都是比较主流的两款消息中间件，具备消息传递的基本功能，但在一些特殊的功能方面存在差异，RocketMQ在阿里集团内部有大量的应用在使用。

rabbitmq如果保证消息不丢失？ 消息丢失情况：

 

第一种：生产者弄丢了数据。生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能。 第二种：RabbitMQ 弄丢了数据。MQ还没有持久化自己挂了 第三种：消费端弄丢了数据。刚消费到，还没处理，结果进程挂了，比如重启了。

解决方案：

 

一：针对生产者

方案1：开启RabbitMQ事务

可以选择用 RabbitMQ 提供的事务功能，就是生产者发送数据之前开启 RabbitMQ 事务channel.txSelect，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务channel.txRollback，然后重试发送消息；如果收到了消息，那么可以提交事务channel.txCommit。

// 开启事务
channel.txSelect
try {
    // 这里发送消息
} catch (Exception e) {
    channel.txRollback
​
    // 这里再次重发这条消息
}
// 提交事务
channel.txCommit

缺点：rabbitMq事务机制是同步的，如果提交一个事务之后会阻塞在那里，采用这种方式基本上吞吐量会下来因为太消耗性能了。

方案2：使用/confirm/i机制

事务机制和/confirm/i机制最大的不同在于，事务机制是同步的，提交一个事务之后会阻塞在那儿。但是/confirm/i机制是异步的，你发送这个消息之后就可以发送下一个消息然而那个消息rabbitMq接受了之后会异步回调你的一个接口通知这个消息接受到了。

一、生产者的/confirm/i模式

通过生产者的确认模式我们是要保证消息准确到达Broker端，而与AMQP事务不同的是/confirm/i是针对一条消息，而事务是可以针对多条消息的。