生产者在生产过程中的消息丢失
broker在故障后的消息丢失
消费者在消费过程中的消息丢失
ACK机制
ack有3个可选值，分别是1，0，-1。
ack=0：生产者在生产过程中的消息丢失
简单来说就是，producer发送一次就不再发送了，不管是否发送成功。
ack=1：broker在故障后的消息丢失
简单来说就是，producer只要收到一个分区副本成功写入的通知就认为推送消息成功了。这里有一个地方需要注
意，这个副本必须是leader副本。只有leader副本成功写入了，producer才会认为消息发送成功。
注意，ack的默认值就是1。这个默认值其实就是吞吐量与可靠性的一个折中方案。生产上我们可以根据实际情况进
行调整，比如如果你要追求高吞吐量，那么就要放弃可靠性。
ack=-1：生产侧和存储侧不会丢失数据
简单来说就是，producer只有收到分区内所有副本的成功写入的通知才认为推送消息成功了。
Offset机制
kafka消费者的三种消费语义
at-most-once：最多一次，可能丢数据
at-least-once：最少一次，可能重复消费数据
exact-once message：精确一次
Kafka是pull？push？以及优劣势分析
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不断在循环中轮询，直到新消息到达。
为了避免这点，Kafka有个参数可以让consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特
定的量这样就可以批量发
)！)
