一：kafka 和 rabbitmq区别

1、吞吐量：

kafka吞吐量更高：
　　1）Zero Copy机制，内核copy数据直接copy到网络设备，不必经过内核到用户再到内核的copy，减小了copy次数和上下文切换次数，大大提高了效率。
　　2）磁盘顺序读写，减少了寻道等待的时间。
　　3）批量处理机制，服务端批量存储，客户端主动批量生产数据/消费数据，消息处理效率高。
　　4）存储具有O(1)的复杂度，读取因为分区和segment，是O(log(n))的复杂度。
　　5）分区机制，有助于提高吞吐量。

2、有序：

kafka是分区有序的，而rabbitmq没法保证顺序

rabbitmq服务器按照顺利保留消息到队列，如果有多个consumer来消费队列中的消息，服务器会按接收消息的顺序向外提供消息，但是，尽管服务器是按照顺序提供消息，但是消息传递到每一个consumer是异步的，这可能会导致消费的consumer获取到消息的时间可能比后消费的consumer获取到消息的时间长，导致不能保证顺序性

rabbitmq要保证消息有序可以在运用层面，通过在消息实体中增加：版本号 & 状态机 & msgid & parent_msgid，通过 parent_msgid 判断消息的顺序（需要全局存储，记录消息的执行状态）。
比如下单操作，下单成功之后，会发布创建订单和扣减库存消息，但扣减库存消息执行会先于创建订单消息，也就说前者执行成功之后，才能执行后者。
所以在创建订单消息中的parent_msgid就是扣减库存消息id，这样在执行创建订单时，先去查询partent_magid（也就是扣减库存消息id）是否执行成功。

3、可靠性

rabbitmq可靠性更好：
　　1）确认机制（生产者和exchange，消费者和队列）；
　　2）支持事务，但会造成阻塞；
　　3）委托（添加回调来处理发送失败的消息）和备份交换器（将发送失败的消息存下来后面再处理）机制；

kafka：
　　1）没有消息确认机制，kafka是通过consumer提交消息消费的offset来控制消息消费的。
　　2）0.11.0之后支持事务

4：持久化

RabbitMQ对于queue中的message的保存方式有两种方式：disc（磁盘持久化）和ram（内存）；
不管是持久化的消息还是非持久化的消息都可以被写入到磁盘。持久化的消息在到达队列时就被写入到磁盘，并且如果可以，持久化的消息也会在内存中保存一个备份，这样就可以提高一定的性能，当内存吃紧的时候会从内存中清除。
非持久化的消息一般只保存在内存中，在内存吃紧的时候会被换入到磁盘中，以节省内存空间。这两种类型的消息的落盘处理都在RabbitMQ的“持久层”中完成。

消息持久化的好处是在RabbitMQ服务器挂了后，message仍然可以在重启之后恢复；
非持久化的消息则不会恢复，但是RabbitMQ处理message的效率要高很多；

5、集群负载

kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。

rabbitMQ的负载均衡需要单独的loadbalancer进行支持。

6、应用场景：

RabbitMQ：用于实时的，对可靠性要求较高的消息传递上。
kafka：用于处于活跃的流式数据，大数据量的数据处理上。

7、：RabbitMq exchange类型

• Fanout Exchange：将 Message 广播到所有绑定的 Queue 中
• Direct Exchange：根据 RoutingKey 来路由消息
• Topic Exchange：通过 RoutingKey 来路由消息，区别在于Direct Exchange 对 RoutingKey 是精确匹配，而 Topic Exchange 支持模糊匹配

二：kafka的架构 组件

Topic：是一个高层次的抽象概念，kafka按照Topic分类来维护消息；
Producter：将发布publish消息到Topic的进程称之为生产者producter；
Consumer：将订阅subscribe topic 并且处理Topic中消息的进程称之消费者consumer；
Broker：kafka以集群的方式运作，集群中的每一台服务器称之为一个代理broker；
Zookeeper：存储topic信息，和元数据信息，新建的topic都会在zookeeper中存在

image.png

三：kafka的安全性和可靠性如何保证

• 1、可靠性：主从架构的副本机制来保证的，每个partition的日志log分布在kafka集群中的不同broker上，每个broker可以请求备份其他broker上的partition数据，kafka集群支持配置一个partition备份的数量，即多个副本。一主多从，当主挂掉以后，多个partition分区通过zookeeper重新选举leader

• 2、安全性：time-base消息保存策略，默认是7天，就是说不管你消费不消费，我总是保存7天的日志数据
  partition是一个有序的message序列，这些message按顺序添加到一个叫做commit log的文件中，每个partition中的消息都有一个唯一的编号，称之为offset，用来唯一标识某个分区中的message；每个partition，都对应一个commit-log，一个partition中的message的offset都是唯一的，但是不同的partition中的message的offset可能是相同。

问题四：kakfa吞吐量大 原因？？

kafka消息是保存在日志文件中的，客户端不断的去读，IO操作，为啥性能还是很高效

• 顺序读写：随机读写IO性能性能很差，但是顺序读写性能很好（kafka给出的测试数据，顺序读写比随机读写快了近6000倍）；

• 零拷贝：正常情况下的文件操作流程，比如程序把一个文件发送到网络中，首先先把文件读到内核空间缓冲区，然后再读到用户空间缓存区，然后再写到内存空间缓冲区，最后再发送到网络中，如下

image.png

而零拷贝，数据不再复制到用户缓存去，是在Linux kernel（内核）2.2之后出现的，减少了一次读取，一个写入的操作，但是多了一次从读缓冲区（read buffer）中的数据拷贝到的网络缓冲区（socket buffer）的过程，如下

image.png

更详细的零拷贝知识见这里
零拷贝

• 文件分段
  kafka的队列topic被分为了多个区partition，每个partition又分为了多个段segment，所以一个topic中的消息实际上是保存在N个片段文件中的，通过分段的方式，每次文件操作都是对一个小文件的操作，非常快速

image.png

• 批量发送
  kafka允许进行批量发送消息，先将消息缓存在内存中，然后批量发送出去。比如可以指定缓存的消息达到某个量的时候就发出去，或者缓存了固定的时间后就发出去。

• 数据压缩
  kafka支持对消息集合进行压缩，producer可以通过gzip或snappy格式对消息集合进行压缩
  producer压缩之后，在consumer需进行解压，虽然增加了CPU的工作，但是对大数据处理上，瓶颈在网络上而不是CPU，所以是很值得

• kafka集群，在配置的时间范围内，维护所有的由producter生成的消息，而不管这些消息有没有被消费。例如日志保留时间（log retention）时间被设置为2天，kafka会维护最近2天生产的所有消息，而2天前的消息会被丢弃。kafka的性能与保留的数据量的大小没有关系，因此保存大量的数据（日志信息）不会有什么影响。

四：kafka有序么

partition有序，如果一个topic有多个partition，则只有在partition内才有序，如果要保证topic有序，则设置成一个partition；一个partition对应一个commit-log日志文件

五：kafka如何保证消息不被重复消费

重复消费：同一条消息被消费者消费了多次
解决方法：

• 1、kafka自带的消费机制
  kafka是通过offset来保证消息不被重复消费的，在consumer消费了数据之后，每隔一段时间，会把自己消费过的消息的offset提交一下，表示consumer已经消费过了。
  但是如果consumer已经消费过了，but，还没来得及提交offset，这时候突然挂掉了，再次重启继续从kafka拉取数据时，会重复消费刚才已经消费过的消息，这时候就需要在consumer来保证不能重复消费了，
• 2、通过保证消费者的幂等性（重复消费不会产生问题）来保证
  比如：
  1.我们可以先把数据写入redis，然后来一条数据先去redis中查询，如果没有，则set，如果有，说明重复消费，不处理；
  2.或者我们在数据库中建立一张消息临时表，把接收的消息写入临时表中，如果有消息到来，先去临时表中查询（消息要有唯一id），这样做的好处是可以管理消息的生命周期，当消费者消费后，把表中消息的状态变更为已消费，同时定期删除。

六：kafka分区leader选举原理

主要是利用了多个从节点向zookeeper创建临时节点，如果创建成功，则从节点为主节点，而其他从节点则从临时节点中读取主节点信息（类似分布式锁）

image.png