代码拉取完成，页面将自动刷新
同步操作将从 Java精选/Ebooks 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
Kafka是分布式发布-订阅消息系统，它最初是由LinkedIn公司开发的，之后成为Apache项目的一部分，Kafka是一个分布式，可划分的，冗余备份的持久性的日志服务，它主要用于处理流式数据。
Apach Kafka是一款分布式流处理框架，用于实时构建流处理应用。它有一个核心的功能广为人知，即作为企业级的消息引擎被广泛使用。
如果用户位于与broker不同的数据中心，则可能需要调优套接口缓冲区大小，以对长网络延迟进行摊销。
获取topic主题的列表命令：
bin/kafka-topics.sh --list --zookeeper localhost:2181
vhost可以理解为虚拟broker，即mini-RabbitMQ server。
其内部均含有独立的queue、exchange和binding等，但最重要的是其拥有独立的权限系统，可以做到vhost范围的用户控制。
当然，从RabbitMQ的全局角度，vhost可以作为不同权限隔离的手段。举一个典型的例子就是不同的应用可以跑在不同的vhost中。
RabbitMQ 消费类型也就是交换器（Exchange）类型有以下四种：
direct：轮询方式。
headers：轮询方式，允许使用header而非路由键匹配消息，性能差，几乎不用。
fanout：广播方式，发送给所有订阅者。
topic：匹配模式，允许使用正则表达式匹配消息。
RabbitMQ默认的是direct方式。
由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。
RabbitMQ使用信道的方式来传输数据。
信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。
1、吞吐量
kafka吞吐量更高： 1）Zero Copy机制，内核copy数据直接copy到网络设备，不必经过内核到用户再到内核的copy，减小了copy次数和上下文切换次数，大大提高了效率。 2）磁盘顺序读写，减少了寻道等待的时间。 3）批量处理机制，服务端批量存储，客户端主动批量pull数据，消息处理效率高。 4）存储具有O(1)的复杂度，读物因为分区和segment，是O(log(n))的复杂度。 5）分区机制，有助于提高吞吐量。
2、可靠性
rabbitmq可靠性更好： 1）确认机制（生产者和exchange，消费者和队列）； 2）支持事务，但会造成阻塞； 3）委托（添加回调来处理发送失败的消息）和备份交换器（将发送失败的消息存下来后面再处理）机制；
3、高可用
1）rabbitmq采用mirror queue，即主从模式，数据是异步同步的，当消息过来，主从全部写完后，回ack，这样保障了数据的一致性。 2）每个分区都可以有一个或多个副本，这些副本保存在不同的broker上，broker信息存储在zookeeper上，当broker不可用会重新选举leader。 kafka支持同步负责消息和异步同步消息（有丢消息的可能），生产者从zk获取leader信息，发消息给leader，follower从leader pull数据然后回ack给leader。
4、负责均衡
1）kafka通过zk和分区机制实现：zk记录broker信息，生产者可以获取到并通过策略完成负载均衡；通过分区，投递消息到不同分区，消费者通过服务组完成均衡消费。 2）需要外部支持。
5、模型
1）rabbitmq： producer，broker遵循AMQP（exchange，bind，queue），consumer； broker为中心，exchange分topic，direct，fanout和header，路由模式适合多种场景； consumer消费位置由broker通过确认机制保存；
2）kafka： producer，broker，consumer，未遵循AMQP； consumer为中心，获取消息模式由consumer自身决定； offset保存在消费者这边，broker无状态； 消息是名义上的永久存储，每个parttition按segment保存自己的消息为文件（可配置清理周期）； consumer可以通过重置offset消费历史消息； 需要绑定zk；
1、生产者丢数据
生产者的消息没有投递到MQ中怎么办？从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。
transaction机制就是说，发送消息前，开启事物(channel.txSelect())，然后发送消息，如果发送过程中出现什么异常，事物就会回滚(channel.txRollback())，如果发送成功则提交事物(channel.txCommit())。
然而缺点就是吞吐量下降了。因此，按照博主的经验，生产上用confirm模式的居多。一旦channel进入confirm模式，所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个Ack给生产者(包含消息的唯一ID)，这就使得生产者知道消息已经正确到达目的队列了.如果rabiitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。
2、消息队列丢数据
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。
那么如何持久化呢，这里顺便说一下吧，其实也很容易，就下面两步
1）将queue的持久化标识durable设置为true,则代表是一个持久的队列
2）发送消息的时候将deliveryMode=2
这样设置以后，rabbitMQ就算挂了，重启后也能恢复数据。在消息还没有持久化到硬盘时，可能服务已经死掉，这种情况可以通过引入mirrored-queue即镜像队列，但也不能保证消息百分百不丢失（整个集群都挂掉）
3、消费者丢数据
启用手动确认模式可以解决这个问题
1）自动确认模式，消费者挂掉，待ack的消息回归到队列中。消费者抛出异常，消息会不断的被重发，直到处理成功。不会丢失消息，即便服务挂掉，没有处理完成的消息会重回队列，但是异常会让消息不断重试。
2）手动确认模式，如果消费者来不及处理就死掉时，没有响应ack时会重复发送一条信息给其他消费者；如果监听程序处理异常了，且未对异常进行捕获，会一直重复接收消息，然后一直抛异常；如果对异常进行了捕获，但是没有在finally里ack，也会一直重复发送消息(重试机制)。
3）不确认模式，acknowledge="none" 不使用确认机制，只要消息发送完成会立即在队列移除，无论客户端异常还是断开，只要发送完就移除，不会重发。
Kafka中体现零拷贝使用场景的地方有两处：基于mmap的索引和日志文件读写所用的TransportLayer。
基于mmap的索引
索引都是基于MappedByteBuffer的，也就是让用户态和内核态共享内核态 的数据缓冲区，此时，数据不需要复制到用户态空间。不过，mmap 虽然避免了不必要的 拷贝，但不一定就能保证很高的性能。在不同的操作系统下，mmap 的创建和销毁成本可 能是不一样的。很高的创建和销毁开销会抵消 零拷贝 带来的性能优势。由于这种不确 定性，在Kafka中，只有索引应用了mmap，最核心的日志并未使用mmap机制。
日志文件读写所用的TransportLayer
TransportLayer是Kafka传输层的接口。它的某个实现类使用了FileChannel的transferTo方法。该方法底层使用sendfile实现了零拷贝。对Kafka而言，如果I/O通道使用普通的PLAINTEXT，那么，Kafka就可以利用零拷贝特性，直接将页缓存中的数据发送到网卡的 Buffer 中，避免中间的多次拷贝。相反，如果I/O通道启用了SSL，那么，Kafka便无法利用零拷贝特性了。
消息持久化的缺点是很消耗性能，因为要写入硬盘要比写入内存性能较低很多，从而降低了服务器的吞吐量。可使用固态硬盘来提高读写速度，以达到缓解消息持久化的缺点。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
