原文链接 译者：flystarfly

介绍

使用消息代理（如RabbitMQ）的系统按定义分发。 由于发送的协议方法（消息）不能保证到达对方或被成功处理，所以发布者和消费者都需要一个交付和处理确认的机制。 RabbitMQ支持的一些消息协议提供了这样的功能。 本指南涵盖AMQP 0-9-1中的特性，但其他协议（STOMP，MQTT等）中的思路大致相同。

从消费者（consumers）投递rabbitmq代理(broker)的处理确认被认为是AMQP 0-9-1协议中的确认; rabbitmq代理(broker)对发布者(publishers)的确认被称作发布者确认(publisher confirms)
阅读全文

原文链接 译者：flystarfly

该文阅读自RabbitMQ官方网站，分享好文给大家

你在Rabbit有一个队列，然后一些消费者从这个队列中消费。如果你根本没有设置QoS（basic.qos），那么Rabbit会把所有的队列消息都按照网络和客户端允许的速度推送给客户端。消费者将会飞速增加它们的内存占用，因为它们将所有消息都缓存在自己的RAM中。如果您询问Rabbit，队列可能会显示为空，但会有大量在客户端中，正准备由客户端应用程序处理的消息未被确认。如果您添加新的消费者，则队列中不会有消息发送给新的消费者。即使有其他消费者可用于更快地处理这样的消息，它们也只是在现有的客户端缓存，并且可能在那里很长一段时间。这是相当次优的。

因此，默认的QoS预取设置为客户提供了无限的缓冲区，这可能导致不良的行为和性能。但是，怎样的QoS预取缓冲区大小才是您应该设置的？设置的目的是让消费者保持工作饱和状态，同时尽量减少客户端的缓冲区大小，以便更多的消息留在Rabbit的队列中，来可供新消费者使用，或在消费者空闲时发送给消费者。
阅读全文

原文链接 译者： flystarfly

原文链接 译者：flystarfly

2. APIs

Kafka包含四种核心的API:

1. Producer API支持应用将数据流发送到Kafka集群的主题。
2. Consumer API支持应用从Kafka集群的主题中读取数据流。
3. Streams API支持数据流从输入主题转化到输出主题。
4. Connect API支持实现持续地从一些源系统或应用划入Kafka或者从Kafka推入一些源系统或应用的接口。

阅读全文

作者:flystarfly

通过spring tools suite新建一个spring project。带maven的即可

pom.xml文件配置

阅读全文

原文链接 译者：flystarfly

原文链接 译者：flystarfly

原文链接 译者：flystarfly

2.1. 连接持久性

一个主机与另一个主机建立连接的过程是相当复杂的，并且涉及两个端点之间的多个分组交换，这可能相当耗时。尤其是对于较小的HTTP消息来说，连接握手的开销是很大的。如果打开的连接能够重用于执行多次请求，就可以实现更高的数据吞吐量。

HTTP/1.1协议规定每个缺省的HTTP连接都可以重用于多次请求。 符合HTTP/1.0协议的端点同样可以通过一种机制明示它们的优先权来维持连接的可用性并将其用于多次请求。
HTTP代理还可以维持空闲连接存活一段时间，以防后续请求需要用到同一目标主机的连接。 通常称维持连接存活的能力为连接持久性，HttpClient完全支持这种能力。

阅读全文

原文链接 译者：flystarfly

原文链接 译者：flystarfly

原文链接 译者：flystarfly

原文链接 译者：flystarfly

原文链接 译者：flystarfly

原文链接 译者：flystarfly

参考文档