代码拉取完成，页面将自动刷新
同步操作将从 Java精选/Ebooks 强制同步，此操作会覆盖自 Fork 仓库以来所做的任何修改，且无法恢复！！！
确定后同步将在后台操作，完成时将刷新页面，请耐心等待。
kafka使用seek(TopicPartition, long)指定新的消费位置。
用于查找服务器保留的最早和最新的offset 的特殊的方法也可用。seekToBeginning(Collection)和seekToEnd(Collection)
Kafka Manager：应该算是最有名的专属Kafka监控框架了，是独立的监控系统。
Kafka Monitor：LinkedIn开源的免费框架，支持对集群进行系统测试，并实时监控测试结果。
CruiseControl：是LinkedIn公司开源的监控框架，用于实时监测资源使用率，以及提供常用运维操作等。无UI界面，只提供REST API。
JMX 监控：由于Kafka提供的监控指标都是基于JMX的，因此，市面上任何能够集成JMX的框架都可以使用，比如Zabbix和Prometheus。
已有大数据平台自己的监控体系：像Cloudera提供的CDH大数据平台等。
JMXTool：社区提供的命令行工具，能够实时监控JMX指标。此工具属于面试时加分项，知道的比较很少，而且会给人一种你对Kafka工具非常熟悉的感觉。关注Java精选公众号，面试题持续更新。如果暂时不了解它的用法，可以在命令行以无参数方式执行一下kafka-run-class.sh kafka.tools.JmxTool，学习下它的用法。
RabbitMQ保证消息的顺序性方式有两种：
1）拆分多个queue，每个queue对应一个consumer（消费者），就是多一些queue。
2）一个queue，对应一个consumer（消费者），然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理。
如果用户位于与broker不同的数据中心，则可能需要调优套接口缓冲区大小，以对长网络延迟进行摊销。
1、解耦
允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2、冗余
消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据 丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队 列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保 你的数据被安全的保存直到你使用完毕。
3、扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的， 只要另外增加处理过程即可。
4、灵活性 & 峰值处理能力
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不 常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪 费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负 荷的请求而完全崩溃。
5、可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合 度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复 后被处理。
6、顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的， 并且能保证数据会按照特定的顺序来处理。（Kafka 保证一个 Partition 内的消 息的有序性）
7、缓冲
有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度 不一致的情况。
8、异步通信
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允 许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放 多少，然后在需要的时候再去处理它们。
vhost可以理解为虚拟broker，即mini-RabbitMQ server。
其内部均含有独立的queue、exchange和binding等，但最重要的是其拥有独立的权限系统，可以做到vhost范围的用户控制。
当然，从RabbitMQ的全局角度，vhost可以作为不同权限隔离的手段。举一个典型的例子就是不同的应用可以跑在不同的vhost中。
从Kafka的生产者与消费者的角度来看待数据丢失的问题。
Producer
1、retries=Long.MAX_VALUE
设置retries为一个较大的值。这里的retries同样是Producer的参数，对应前面提到的Producer自动重试。当出现网络的瞬时抖动时，消息发送可能会失败，此时配置了retries>0的Producer能够自动重试消息发送，避免消息丢失。
2、acks=all
设置acks=all。acks是Producer的一个参数，代表了你对“已提交”消息的定义。如果设置成all，则表明所有副本Broker都要接收到消息，该消息才算是“已提交”。这是最高等级的“已提交”定义。
3、max.in.flight.requests.per.connections=1
该参数指定了生产者在收到服务器晌应之前可以发送多少个消息。它的值越高，就会占用越多的内存，不过也会提升吞吐量。把它设为1可以保证消息是按照发送的顺序写入服务器的，即使发生了重试。
4、Producer要使用带有回调通知的API，也就是说不要使用producer.send(msg)，而要使用producer.send(msg,callback)。
5、其他错误处理
使用生产者内置的重试机制，可以在不造成消息丢失的情况下轻松地处理大部分错误，不过仍然需要处理其他类型的错误，例如消息大小错误、序列化错误等等。
Consumer
1、禁用自动提交：enable.auto.commit=false
2、消费者处理完消息之后再提交offset
3、配置auto.offset.reset
这个参数指定了在没有偏移量可提交时(比如消费者第l次启动时)或者请求的偏移量在broker上不存在时(比如数据被删了)，消费者会做些什么。
这个参数有两种配置。一种是earliest：消费者会从分区的开始位置读取数据，不管偏移量是否有效，这样会导致消费者读取大量的重复数据，但可以保证最少的数据丢失。一种是latest(默认)，如果选择了这种配置，消费者会从分区的末尾开始读取数据，这样可以减少重复处理消息，但很有可能会错过一些消息。
Apache Kafka与传统的消息传递技术相比优势之处在于：
快速：单一的Kafka代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作。
可伸缩：在一组机器上对数据进行分区和简化，以支持更大的数据。
持久：消息是持久性的，并在集群中进行复制，以防止数据丢失。
设计：它提供了容错保证和持久性。
消息持久化的缺点是很消耗性能，因为要写入硬盘要比写入内存性能较低很多，从而降低了服务器的吞吐量。可使用固态硬盘来提高读写速度，以达到缓解消息持久化的缺点。
交换器（Exchange）
消息代理服务器中用于把消息路由到队列的组件。
队列（Queue）
用来存储消息的数据结构，位于硬盘或内存中。
绑定（Binding）
一套规则，告知交换器消息应该将消息投递给哪个队列。
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
