代码拉取完成，页面将自动刷新
同步操作将从 dearHaoGeGe/Ebooks 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
RabbitMQ使用ack消息确认的方式保证每个消息都能被消费，开发者可根据自己的实际业务，选择channel.basicAck()方法手动确认消息被消费。
ProducerRecord内部数据结构：
-- Topic （名字） -- PartitionID ( 可选) -- Key[( 可选 ) -- Value
提供三种构造函数形参：
ProducerRecord(topic, partition, key, value)
ProducerRecord(topic, key, value)
ProducerRecord(topic, value)
第一种分区策略：指定分区号，直接将数据发送到指定的分区中。
第二种分区策略：没有指定分区号，指定数据的key值，通过key取上hashCode进行分区。
第三种分区策略：没有指定分区号，也没有指定key值，直接轮循进行分区。
第四种分区策略：自定义分区。
和 MQTT 的事务定义一样都是3种。
1）最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输。
2）最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输。
3）精确的一次（Exactly once）: 不会漏传输也不会重复传输，每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的。
将auto.commit.offset设为false，然后在处理一批消息后commitSync()或者异步提交commitAsync()即：
ConsumerRecords<> records = consumer.poll();
for(ConsumerRecord<> record : records){
try{
consumer.commitSync();
}
}
可靠性
RabbitMQ使用一些机制来保证可靠性，如持久化、传输确认及发布确认等。
灵活的路由
在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能，RabbitMQ己经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个交换器绑定在一起，也可以通过插件机制来实现自己的交换器。
扩展性
多个RabbitMQ节点可以组成一个集群，也可以根据实际业务情况动态地扩展集群中节点。
高可用性
队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队列仍然可用。
多种协议
RabbitMQ除了原生支持AMQP协议，还支持STOMP，MQTT等多种消息中间件协议。
多语言客户端
RabbitMQ几乎支持所有常用语言，比如Java、Python、Ruby、PHP、C#、JavaScript等。
管理界面
RabbitMQ提供了一个易用的用户界面，使得用户可以监控和管理消息、集群中的节点等。
插件机制
RabbitMQ提供了许多插件，以实现从多方面进行扩展，当然也可以编写自己的插件。
RabbitMQ 要实现消息持久化，必须满足以下 4 个条件：
1、投递消息的时候durable设置为true，消息持久化，代码：channel.queueDeclare(x, true, false, false, null)，第2个参数设置为true持久化；
2、设置投递模式deliveryMode设置为2（持久），代码：channel.basicPublish(x, x, MessageProperties.PERSISTENTTEXTPLAIN,x)，第3个参数设置为存储纯文本到磁盘；
3、消息已经到达持久化交换器上；
4、消息已经到达持久化的队列。
如果用户位于与broker不同的数据中心，则可能需要调优套接口缓冲区大小，以对长网络延迟进行摊销。
Kafka是分布式发布-订阅消息系统，它最初是由LinkedIn公司开发的，之后成为Apache项目的一部分，Kafka是一个分布式，可划分的，冗余备份的持久性的日志服务，它主要用于处理流式数据。
Apach Kafka是一款分布式流处理框架，用于实时构建流处理应用。它有一个核心的功能广为人知，即作为企业级的消息引擎被广泛使用。
RabbitMQ 消费类型也就是交换器（Exchange）类型有以下四种：
direct：轮询方式。
headers：轮询方式，允许使用header而非路由键匹配消息，性能差，几乎不用。
fanout：广播方式，发送给所有订阅者。
topic：匹配模式，允许使用正则表达式匹配消息。
RabbitMQ默认的是direct方式。
Kafka最初考虑的问题是，customer应该从brokes拉取消息还是brokers将消息推送到consumer，也就是pull还push。在这方面，Kafka遵循了一种大部分消息系统共同的传统的设计：producer将消息推送到broker，consumer从broker拉取消息。
一些消息系统比如Scribe和Apache Flume采用了push模式，将消息推送到下游的consumer。这样做有好处也有坏处：由broker决定消息推送的速率，对于不同消费速率的consumer就不太好处理了。消息系统都致力于让consumer以最大的速率最快速的消费消息，但不幸的是，push模式下，当broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。最终Kafka还是选取了传统的pull模式。
Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker拉取数据。Push模式必须在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免consumer崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull模式下，consumer就可以根据自己的消费能力去决定这些策略。
Pull有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到t达。为了避免这点，Kafka有个参数可以让consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发送)。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。