kafka通過topic來分主題存放資料，主題內有分割槽，分割槽可以有多個副本，分割槽的內部還細分為若干個segment。
所謂的分割槽其實就是在kafka對應儲存目錄下建立的資料夾，資料夾的名字是主題名加上分割槽編號，編號從0開始。
所謂的segment其實就是在分割槽對應的資料夾下產生的檔案。
乙個分割槽會被劃分成大小相等的若干segment，這樣一方面保證了分割槽的資料被劃分到多個檔案中保證不會產生體積過大的檔案；另一方面可以基於這些segment檔案進行歷史資料的刪除，提高效率。
乙個segment又由乙個.log和乙個.index檔案組成。
1．.log
.log檔案為資料檔案用來存放資料分段資料。
2．.index
.index為索引檔案儲存對對應的.log檔案的索引資訊。
在.index檔案中，儲存了對對應.log檔案的索引資訊，通過查詢.index檔案可以獲知每個儲存在當前segment中的offset在.log檔案中的開始位置，而每條日誌有其固定格式，儲存了包括offset編號、日誌長度、key的長度等相關資訊，通過這個固定格式中的資料可以確定出當前offset的結束位置，從而對資料進行讀取。
3．命名規則
這兩個檔案的命名規則為：
partition全域性的第乙個segment從0開始，後續每個segment檔名為上乙個segment檔案最後一條訊息的offset值，數值大小為64位，20位數字字元長度，沒有數字用0填充。
開始讀取指定分割槽中某個offset對應的資料時，先根據offset和當前分割槽的所有segment的名稱做比較，大資料培訓確定出資料在哪個segment中，再查詢該segment的索引檔案，確定當前offset在資料檔案中的開始位置，最後從該位置開始讀取資料檔案，在根據資料格式判斷結果，獲取完整資料。
在kafka中維護了乙個ar列表，包括所有的分割槽的副本。ar又分為isr和osr。
ar = isr + osr。
ar、isr、osr、leo、hw這些資訊都被儲存在zookeeper中。
1．isr
isr中的副本都要同步leader中的資料，只有都同步完成了資料才認為是成功提交了，成功提交之後才能供外界訪問。
在這個同步的過程中，資料即使已經寫入也不能被外界訪問，這個過程是通過leo-hw機制來實現的。
2．osr
osr內的副本是否同步了leader的資料，不影響資料的提交，osr內的follower盡力的去同步leader，可能資料版本會落後。
最開始所有的副本都在isr中，在kafka工作的過程中，如果某個副本同步速度慢於replica.lag.time.max.ms指定的閾值，則被踢出isr存入osr，如果後續速度恢復可以回到isr中。
3．leo
logendoffset：分割槽的最新的資料的offset，當資料寫入leader後，leo就立即執行該最新資料。相當於最新資料標識位。
4．hw
highwatermark：只有寫入的資料被同步到所有的isr中的副本後，資料才認為已提交，hw更新到該位置，hw之前的資料才可以被消費者訪問，保證沒有同步完成的資料不會被消費者訪問到。相當於所有副本同步資料標識位。
在leader宕機後，只能從isr列表中選取新的leader，無論isr中哪個副本被選為新的leader，它都知道hw之前的資料，可以保證在切換了leader後，消費者可以繼續看到hw之前已經提交的資料。
所以leo代表已經寫入的最新資料位置，而hw表示已經同步完成的資料，只有hw之前的資料才能被外界訪問。
5．hw截斷機制
如果leader宕機，選出了新的leader，而新的leader並不能保證已經完全同步了之前leader的所有資料，只能保證hw之前的資料是同步過的，此時所有的follower都要將資料截斷到hw的位置，再和新的leader同步資料，來保證資料一致。
當宕機的leader恢復，發現新的leader中的資料和自己持有的資料不一致，此時宕機的leader會將自己的資料截斷到宕機之前的hw位置，然後同步新leader的資料。宕機的leader活過來也像follower一樣同步資料，來保證資料的一致性。
通過以上的講解，已經可以保證kafka集群內部的可靠性，但是在生產者向kafka集**送時，資料經過網路傳輸，也是不可靠的，可能因為網路延遲、閃斷等原因造成資料的丟失。
kafka為生產者提供了如下的三種可靠性級別，通過不同策略保證不同的可靠性保障。
其實此策略配置的就是leader將成功接收訊息資訊響應給客戶端的時機。
通過request.required.acks引數配置：
1：生產者傳送資料給leader，leader收到資料後傳送成功資訊，生產者收到後認為傳送資料成功，如果一直收不到成功訊息，則生產者認為傳送資料失敗會自動重發資料。
當leader宕機時，可能丟失資料。
0：生產者不停向leader傳送資料，而不需要leader反饋成功訊息。
這種模式效率最高，可靠性最低。可能在傳送過程中丟失資料，也可能在leader宕機時丟失資料。
-1：生產者傳送資料給leader，leader收到資料後要等到isr列表中的所有副本都同步資料完成後，才向生產者傳送成功訊息，如果乙隻收不到成功訊息，則認為傳送資料失敗會自動重發資料。
這種模式下可靠性很高，但是當isr列表中只剩下leader時，當leader宕機讓然有可能丟資料。
此時可以配置min.insync.replicas指定要求觀察isr中至少要有指定數量的副本，預設該值為1，需要改為大於等於2的值
這樣當生產者傳送資料給leader但是發現isr中只有leader自己時，會收到異常表明資料寫入失敗，此時無法寫入資料，保證了資料絕對不丟。
雖然不丟但是可能會產生冗餘資料，例如生產者傳送資料給leader，leader同步資料給isr中的follower，同步到一半leader宕機，此時選出新的leader，可能具有部分此次提交的資料，而生產者收到失敗訊息重發資料，新的leader接受資料則資料重複了。
當leader宕機時會選擇isr中的乙個follower成為新的leader，如果isr中的所有副本都宕機，怎麼辦？
有如下配置可以解決此問題：
unclean.leader.election.enable=false
策略1：必須等待isr列表中的副本活過來才選擇其成為leader繼續工作。
unclean.leader.election.enable=true
策略2：選擇任何乙個活過來的副本，成為leader繼續工作，此follower可能不在isr中。
策略1，可靠性***，但是可用性低，只有最後掛了leader活過來kafka才能恢復。
策略2，可用性高，可靠性沒***，任何乙個副本活過來就可以繼續工作，但是有可能存在資料不一致的情況。
at most once：訊息可能會丟，但絕不會重複傳輸。
at least once：訊息絕不會丟，但可能會重複傳輸。
exactly once：每條訊息肯定會被傳輸一次且僅傳輸一次。
kafka最多保證at least once，可以保證不丟，但是可能會重複，為了解決重複需要引入唯一標識和去重機制，kafka提供了guid實現了唯一標識，但是並沒有提供自帶的去重機制，需要開發人員基於業務規則自己去重。
Kafka的儲存機制以及可靠性
kafka通過topic來分主題存放資料，主題內有分割槽，分割槽可以有多個副本，分割槽的內部還細分為若干個segment。所謂的分割槽其實就是在kafka對應儲存目錄下建立的資料夾，資料夾的名字是主題名加上分割槽編號，編號從0開始。所謂的segment其實就是在分割槽對應的資料夾下產生的檔案。乙個分...
Kafka訊息可靠性
如果mq沒有類似資料庫事務結構和保證，是不可能達到訊息投遞100 可靠的，極端情況下訊息投遞要麼丟失或重複。下面咋們從producer，broker，consumer的角度分析一下kafka中會出現哪些情況。目前生產者傳送訊息 request.required.acks 有三種方式。acks 0 p...
ActiveMQ可靠性機制
訊息的簽收 acknowledgment 客戶端成功接收一條訊息的標誌是這條訊息被簽收。成功接收一條訊息一般包括如下三個階段 1 客戶端接收訊息 2 客戶端處理訊息 3 訊息被簽收 簽收可以由activemq發起，也可以由客戶端發起，取決於session簽收模式的設定。在帶事務的session中，簽...