生產者在生產過程中的消息丟失
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阻塞知道新消息到達(當然也可以阻塞知道消息的數量達到某個特
定的量這樣就可以批量發
)！)
