kafka是目前應對大資料需求下支援高吞吐量，高可用性，大資料量的訊息佇列。靈活使用kafka的特性可以解決很多實際的業務問題.
kafka是採用集群部署可以橫向擴充套件的架構。
說到集群就不得不說一下分布式，兩者都有壓力分攤為設計目的。簡單說一下對集群和分布式的理解。
集群：通過分流資料達到壓力分攤的目的。同一功能模組，多例項部署模式。可以簡單理解為功能相同，資料分流處理的架構。擴充套件方式為橫向擴充套件，一般擴充套件能力比較強。
分布式：通過拆分為多個功能模組，從而實現系統壓力的分攤.可以簡單理解為功能不同，但資料流相同的架構。擴充套件方式為縱向擴充套件，一般在系統架構設計完後就固定了。業務系統設計成分布式之後，隨之而來的乙個問題就是各個分布式模組之間通訊，訊息佇列的應用就不可少了。對於解耦各模組的訊息隊裡而言，kafka是個不錯的選擇。
然後說一下kafka設計理念相關的概念
producer:生產者，傳送資料到kafka集群的程式。
consumer:消費者，從kafka消費資料的程式。
topic：佇列，一般乙個topic裡面放置的資料是同一業務型別。應用場景：通過不同的佇列來區分業務資料。
group：分組，對於同乙份資料一般有兩種消費方式，重複消費和分流消費。通過group就可以事項這兩種不同的模式。在同乙個分組的消費者是分流消費，份數不同分組的消費者是重複消費。應用場景：對同乙份業務資料，如果有不同的處理，使用重複消費；如果要進行集群分壓，可以採用分流方式。
對於kafka簡單使用而言，知道這兩個概念就可以了。但是要使用kafka的高階功能，還需要繼續深入學習...
partition:分割槽，是topic儲存資料的重要概念,資料分塊。分割槽的多寡，需要按照業務需求設定，影響消費者和生產者。對於消費者而言，乙個消費者可以對於多個分割槽，但是乙個分割槽只能對應乙個消費者，最理想的情況就是乙個分割槽對應乙個消費者。不當的分割槽數會帶來效能上的浪費，反例1：乙個消費者，100個分割槽，那麼這個消費者每次消費的時候就要輪詢（簡單理解為輪詢策略）100個分割槽的資料，對這100個分割槽消費的切換就是額外的效能浪費。反例2：10個消費者，乙個分割槽，那麼其中9個消費者都是拿不到資料的，傻傻杵在哪兒。
生產者往kafka傳送資料，可以指定具體要傳送哪個分割槽，也可以指定傳送多個分割槽的策略。現舉一例：有時候處理業務資料需要嚴格按照時序，kafka中怎麼實現呢，就是topic只建立乙個分割槽，這樣在消費的時候就可以保證訊息的順序和傳送的時候一致了。
replication factor：複製因子，也可以通俗說成用於備份數。對於一些系統，不僅僅要考慮效能還要考慮高可用，也就是要求系統對故障和錯誤有一定的抵抗能力。kafka就是通過複製因子實現部分高可用功能的。這部分高可用簡單講一下，在建立topic的時候指定的複製因子的個數就是當前topic資料的副本數，而這些副本會落到集群不同的機器上，一旦其中一台機器宕機，只要還存有乙個副本，這部分資料就不會丟失。前面說到的集群也是高可用的實現，集群中乙個節點宕機，其他節點依然可以提供服務。
每取得些許進步，都是站在巨人的肩膀上。
每取得些許進步，都像個撿到貝殼的孩子。
每次總結都有額外的收穫。
關於開發者證書,自己的理解
code signing identity 裡面太多證書,想清理怎麼辦在鑰匙串找到多餘的刪除掉即可.provisioning profile 裡面的描述檔案太多怎麼辦,關掉xcode.資料夾目錄 user 你的使用者名稱 library mobiledevice provisioning profi...
開發者註冊
最近在被react native打包虐了乙個多星期 昨天終於搞定了 現在把打包的過程以及遇到的坑整理出來做個筆記 希望能給遇到相同問題的小夥伴們乙個參考。第一步 材料準備 1 乙個已付費的開發者賬號 蘋果開發者賬號的型別如下表 根據自己的需求以及實際情況選擇申請 附上不同證書的區別，請根據自己的需求...
Kafka 基礎概念理解
producer 訊息生產者，向 kafka broker 發訊息的客戶端。consumer 訊息消費者，從 kafka broker 取訊息的客戶端。consumer group 消費者組 cg 消費者組內每個消費者負責消費不同分割槽的資料，提高消費能力。乙個分割槽只能由組內乙個消費者消費，消費者...