訊息
kafka可以替代更傳統的訊息**。訊息**的使用有多種原因（將處理與資料生成器分離，緩衝未處理的訊息等）。與大多數訊息傳遞系統相比，kafka具有更好的吞吐量，內建分割槽，複製和容錯功能，這使其成為大規模訊息處理應用程式的理想解決方案。
根據我們的經驗，訊息傳遞的使用通常相對較低，但可能需要較低的端到端延遲，並且通常取決於kafka提供的強大的耐用性保證。
在這個領域，kafka可與傳統的訊息傳遞系統（如activemq或 rabbitmq）相媲美。
**活動跟蹤
kafka的原始用例是能夠將使用者活動跟蹤管道重建為一組實時發布 - 訂閱源。這意味著站點活動（頁面檢視，搜尋或使用者可能採取的其他操作）將發布到中心主題，每個活動型別包含乙個主題。這些供稿可用於訂購一系列用例，包括實時處理，實時監控以及載入到hadoop或離線資料倉儲系統以進行離線處理和報告。
活動跟蹤通常非常高，因為為每個使用者頁面檢視生成了許多活動訊息。
度量
kafka通常用於運營監控資料。這涉及從分布式應用程式聚合統計資訊以生成運算元據的集中式提要。
日誌聚合
許多人使用kafka作為日誌聚合解決方案的替代品。日誌聚合通常從伺服器收集物理日誌檔案，並將它們放在**位置（可能是檔案伺服器或hdfs）進行處理。kafka抽象出檔案的細節，並將日誌或事件資料更清晰地抽象為訊息流。這允許更低延遲的處理並更容易支援多個資料來源和分布式資料消耗。與scribe或flume等以日誌為中心的系統相比，kafka提供了同樣出色的效能，由於複製而具有更強的耐用性保證，以及更低的端到端延遲。
流處理
許多kafka使用者在處理由多個階段組成的管道時處理資料，其中原始輸入資料從kafka主題中消費，然後聚合，豐富或以其他方式轉換為新主題以供進一步消費或後續處理。例如，用於推薦新聞文章的處理管道可以從rss訂閱源抓取文章內容並將其發布到「文章」主題; 進一步處理可以對此內容進行規範化或重複資料刪除，並將已清理的文章內容發布到新主題; 最終處理階段可能會嘗試向使用者推薦此內容。此類處理管道基於各個主題建立實時資料流的圖形。從0.10.0.0開始，這是乙個輕量級但功能強大的流處理庫，名為kafka streams 在apache kafka中可用於執行如上所述的此類資料處理。除了kafka streams之外，其他開源流處理工具包括apache storm和 apache samza。
活動採購
事件源是一種應用程式設計風格，其中狀態更改被記錄為按時間排序的記錄序列。kafka對非常大的儲存日誌資料的支援使其成為以這種風格構建的應用程式的出色後端。
提交日誌
kafka可以作為分布式系統的一種外部提交日誌。該日誌有助於在節點之間複製資料，並充當故障節點恢復其資料的重新同步機制。kafka中的日誌壓縮功能有助於支援此用法。在這種用法中，kafka類似於apache bookkeeper專案。
生產：
基本流程是這樣的：
建立一條記錄，記錄中乙個要指定對應的topic和value，key和partition可選。 先序列化，然後按照topic和partition，放進對應的傳送佇列中。kafka produce都是批量請求，會積攢一批，然後一起傳送，不是調send()就進行立刻進行網路發包。
如果partition沒填，那麼情況會是這樣的：
key有填 按照key進行雜湊，相同key去乙個partition。（如果擴充套件了partition的數量那麼就不能保證了） key沒填 round-robin來選partition
這些要發往同乙個partition的請求按照配置，攢一波，然後由乙個單獨的執行緒一次性發過去。
api
有high level api，替我們把很多事情都幹了，offset，路由啥都替我們幹了，用以來很簡單。
還有****** api，offset啥的都是要我們自己記錄。
partition
當存在多副本的情況下，會盡量把多個副本，分配到不同的broker上。kafka會為partition選出乙個leader，之後所有該partition的請求，實際操作的都是leader，然後再同步到其他的follower。當乙個broker歇菜後，所有leader在該broker上的partition都會重新選舉，選出乙個leader。（這裡不像分布式檔案儲存系統那樣會自動進行複製保持副本數）
然後這裡就涉及兩個細節：怎麼分配partition，怎麼選leader。
關於partition的分配，還有leader的選舉，總得有個執行者。在kafka中，這個執行者就叫controller。kafka使用zk在broker中選出乙個controller，用於partition分配和leader選舉。
partition的分配
將所有broker（假設共n個broker）和待分配的partition排序
將第i個partition分配到第（i mod n）個broker上 （這個就是leader）
將第i個partition的第j個replica分配到第（(i + j) mode n）個broker上
leader容災
controller會在zookeeper的/brokers/ids節點上註冊watch，一旦有broker宕機，它就能知道。當broker宕機後，controller就會給受到影響的partition選出新leader。controller從zk的/brokers/topics/[topic]/partitions/[partition]/state中，讀取對應partition的isr（in-sync replica已同步的副本）列表，選乙個出來做leader。
選出leader後，更新zk，然後傳送leaderandisrrequest給受影響的broker，讓它們改變知道這事。為什麼這裡不是使用zk通知，而是直接給broker傳送rpc請求，我的理解可能是這樣做zk有效能問題吧。
如果isr列表是空，那麼會根據配置，隨便選乙個replica做leader，或者乾脆這個partition就是歇菜。如果isr列表的有機器，但是也歇菜了，那麼還可以等isr的機器活過來。
多副本同步
這裡的策略，服務端這邊的處理是follower從leader批量拉取資料來同步。但是具體的可靠性，是由生產者來決定的。
生產者生產訊息的時候，通過request.required.acks引數來設定資料的可靠性。
消費
訂閱topic是以乙個消費組來訂閱的，乙個消費組裡面可以有多個消費者。同乙個消費組中的兩個消費者，不會同時消費乙個partition。換句話來說，就是乙個partition，只能被消費組裡的乙個消費者消費，但是可以同時被多個消費組消費。因此，如果消費組內的消費者如果比partition多的話，那麼就會有個別消費者一直空閒。
MQ專案用例總結
問 先說說你們的專案當時為什麼要用mq？mq是怎麼部署的？集群架構？高可用是如何保證的？rocketmq的核心架構原理是什麼？它的工作原理？如果傳送到rocketmq的訊息丟失了，要怎麼辦？因為生產者和消費者所在的專案不在一起，所以我在a專案中用了同乙個生產者，也使用了同乙個topic,但tag不一...
業務用例和系統用例
拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件...
業務用例和系統用例
業務用例與系統用例具有同樣的特徵，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。這形成了系統用例和使用者用例之間的合作。但這樣帶來了兩個壞訊息。第乙個壞訊息 編寫者和讀者經常把二者弄混，可能把系統行為放入業務用例中，也可能把業務操作歸於系統用例。如果能夠商量著去...