引言
前幾期的評(píng)測(cè)中营曼，我們對(duì)比了Kafka和RocketMQ的吞吐量和穩(wěn)定性乒验，本期我們要引入一個(gè)新的評(píng)測(cè)標(biāo)準(zhǔn)——軟件可靠性。
何為“可靠性”蒂阱？
先看下面這種情況：有A锻全，B兩輛越野汽車，在城市的周邊地區(qū)均能很好應(yīng)對(duì)泥濘的路況录煤。當(dāng)一同開去穿越西藏鳄厌，A車會(huì)因?yàn)槲鞑乇镜氐钠筒贿_(dá)標(biāo)，導(dǎo)致油路受阻無法點(diǎn)火妈踊，而B車順利完成了穿越了嚎。因此我們說，B車的可靠性比A車高廊营。
何為“軟件可靠性”歪泳？
“軟件的可靠性”就是考察軟件在各種異常突發(fā)的情況下的應(yīng)對(duì)能力。常見的軟件異常有：磁盤損壞露筒、進(jìn)程意外退出呐伞、宿主機(jī)宕機(jī)等情況。
何為“消息中間件的可靠性”慎式？
對(duì)于消息中間件來說伶氢，“可靠性”最直接的指標(biāo)就是——消息數(shù)據(jù)不丟失趟径。此外，消息不重投癣防、服務(wù)一主多備等特性也可以用來評(píng)估可靠性蜗巧。
那么Kafka和RocketMQ（以下簡稱RMQ）在可靠性上孰優(yōu)孰劣呢？和我們走進(jìn)本期的測(cè)試比拼吧劣砍！
在消息收發(fā)的過程中惧蛹，分別模擬Broker服務(wù)進(jìn)程被Kill、物理機(jī)器掉電的異常場(chǎng)景刑枝，多次實(shí)驗(yàn)，查看極端情況下消息系統(tǒng)的可靠性迅腔。
以下場(chǎng)景使用多個(gè)發(fā)送端向一個(gè)Topic發(fā)送消息装畅，發(fā)送方式為同步發(fā)送，分區(qū)數(shù)為8沧烈，只啟動(dòng)一個(gè)訂閱者掠兄。
在消息收發(fā)過程中，利用Kill -9 命令使Broker進(jìn)程終止锌雀，然后重新啟動(dòng)蚂夕，得到可靠性數(shù)據(jù)如下：
注：以上測(cè)試場(chǎng)景中Kafka的異步刷盤間隔為1秒鐘，同步發(fā)送需設(shè)置request.required.acks=1腋逆，否則會(huì)出現(xiàn)消息丟失婿牍。
在Broker進(jìn)程被終止重啟，Kafka和RMQ都能保證同步發(fā)送的消息不丟惩歉，因?yàn)檫M(jìn)程退出后操作系統(tǒng)能確保將該進(jìn)程遺留在內(nèi)存的數(shù)據(jù)刷到磁盤上等脂。實(shí)驗(yàn)中，Kafka出現(xiàn)了極少量的消息重復(fù)撑蚌。再次可以確定此場(chǎng)景中上遥，二者的可靠性都很高。
在消息收發(fā)過程中争涌，直接拔掉Broker所在的宿主機(jī)電源粉楚，然后重啟宿主機(jī)和Broker應(yīng)用。因受到機(jī)房斷電限制亮垫，我們?cè)诒緢?chǎng)景測(cè)試中使用的是普通PC機(jī)器模软。得到可靠性數(shù)據(jù)如下：
測(cè)試發(fā)現(xiàn)，即使在并發(fā)很低的情況下包警，Kafka和RMQ都無法保證掉電后不丟消息撵摆。這個(gè)時(shí)候，就需要改變刷盤策略了害晦。我們把刷盤策略由“異步刷盤”變更為“同步刷盤”特铝，就是說暑中，讓每一條消息都完成存儲(chǔ)后才返回，以保證消息不丟失鲫剿。
注：關(guān)于兩種刷盤模式的詳細(xì)區(qū)別可以參照文檔最下方的說明
重新執(zhí)行上面的測(cè)試鳄逾，得到數(shù)據(jù)如下：
首先，設(shè)置同步刷盤時(shí)灵莲，二者都沒出現(xiàn)消息丟失的情況雕凹。限于我們使用的是普通PC機(jī)器，兩者吞吐量都不高政冻。此時(shí)Kafka的最高TPS僅有500條/秒枚抵，RMQ可以達(dá)到4000條/秒，已經(jīng)是Kafka的8倍明场。
為什么Kafka的吞吐量如此低呢汽摹？因?yàn)镵afka本身是沒有實(shí)現(xiàn)任何同步刷盤機(jī)制的，就是說在這種場(chǎng)景下測(cè)試苦锨，Kafka注定是要丟消息的逼泣。但要想做到每一條消息都在落盤后才返回，我們可以通過修改異步刷盤的頻率來實(shí)現(xiàn)舟舒。設(shè)置參數(shù)log.flush.interval.messages=1拉庶，即每條消息都刷一次磁盤。這樣的做法秃励，Kafka也不會(huì)丟消息了氏仗，但是頻繁的磁盤讀寫直接導(dǎo)致性能的下降。
另外莺治，二者在服務(wù)恢復(fù)后廓鞠，均出現(xiàn)了消息重復(fù)消費(fèi)的情況，這說明消費(fèi)位點(diǎn)的提交并不是同步落盤的谣旁。不過床佳，幸好Kafka和RMQ都提供了自定義消費(fèi)位點(diǎn)的接口，來避免大量的重復(fù)消費(fèi)榄审。
在Broker進(jìn)程被Kill的場(chǎng)景砌们， Kafka和RocketMQ都能在保證吞吐量的情況下，不丟消息搁进，可靠性都比較高浪感。
在宿主機(jī)掉電的場(chǎng)景，Kafka與RocketMQ均能做到不丟消息饼问，此時(shí)Kafka的吞吐量會(huì)急劇下跌影兽，幾乎不可用。RocketMQ則仍能保持較高的吞吐量莱革。
在單機(jī)可靠性方面峻堰，RocketMQ綜合表現(xiàn)優(yōu)于Kafka讹开。
服務(wù)端為單機(jī)部署，機(jī)器配置如下：
應(yīng)用版本：
同步刷盤是在每條消息都確認(rèn)落盤了之后才向發(fā)送者返回響應(yīng)捐名；而異步刷盤中旦万，只要消息保存到Broker的內(nèi)存就向發(fā)送者返回響應(yīng)，Broker會(huì)有專門的線程對(duì)內(nèi)存中的消息進(jìn)行批量存儲(chǔ)镶蹋。所以異步刷盤的策略下成艘，當(dāng)機(jī)器突然掉電時(shí)，Broker內(nèi)存中的消息因無法刷到磁盤導(dǎo)致丟失贺归。
