0.11 版本之前保證的語義是：至少一次 至少一次的解釋 可以做到消息不丟失--> 可以做到發送成功的消息一定可以被消費到。 不能做到消息不重覆。 ## 發送成功的消息，表示業務邏輯認為此消息已發送成功，即send方法已執行完成。 丟消息場景 非同步發送端： a：send之後，等待發送的時候down（ ...
0.11 版本之前保證的語義是：至少一次
至少一次的解釋
可以做到消息不丟失--> 可以做到發送成功的消息一定可以被消費到。
不能做到消息不重復。
## 發送成功的消息，表示業務邏輯認為此消息已發送成功，即send方法已執行完成。
丟消息場景
異步發送端：
a：send之後，等待發送的時候down（消息在緩沖區中），導致消息丟失。
b：send時，緩沖區已滿，導致消息丟棄。
同步（異步）發送端：
a：有限的重試
服務端Leader down時，因為有與zk的超時timeout，導致在timeout之後才會進行切換， 如果重試次數 * 重試間隔 < zk session timeout + 切換耗時，則消息會丟失。
b：ack ！= -1
ack = 0 的場景，不需服務端確認，發送後，Leader down，導致消息丟失。
ack = 1 的場景，只需要Leader確認，Leader收到消息後，未同步到Replica之前，Leader down，導致消息丟失。
服務端：
a：min.insync.replicas < 2 且 unclean.leader.election.enable = true
min.insync.replicas < 2 的場景下，如果副本均落後Leader，在Leader down時，根據臟選開關，會選擇落後的副本作為新的Leader，則落後的數據會丟失。
消費端：
a：自動offset提交
消息處理失敗，但是offset也提交了，對業務來說消息丟失。
b：先手動提交offset，後處理消息
先提交offset，後處理消息，但是處理邏輯失敗，對業務來說消息丟失。
