kafka是2023年12月份開源的專案，採用scala語言編寫，使用了多種效率優化機制，整體架構比較新穎（push/pull），更適合異構集群。
設計目標：
(1) 資料在磁碟上的訪問代價為o(1)
(2) 高吞吐率，在普通的伺服器上每秒也能處理幾十萬條訊息
(3) 分布式架構，能夠對訊息分割槽
(4) 支援將資料並行的載入到hadoop
架構：
kafka實際上是乙個訊息發布訂閱系統。producer向某個topic發布訊息，而consumer訂閱某個topic的訊息，進而一旦有新的關於某個topic的訊息，broker會傳遞給訂閱它的所有consumer。 在kafka中，訊息是按topic組織的，而每個topic又會分為多個partition，這樣便於管理資料和進行負載均衡。同時，它也使用了zookeeper進行負載均衡。
kafka中主要有三種角色，分別為producer，broker和consumer。
(1) producer
producer的任務是向broker傳送資料。
kafka提供了兩種producer介面，一種是low_level介面，使用該介面會向特定的broker的某個topic下的某個partition傳送資料；
另一種那個是high level介面，該介面支援同步/非同步傳送資料，基於zookeeper的broker自動識別和負載均衡（基於partitioner）。
其中，基於zookeeper的broker自動識別值得一說。producer可以通過zookeeper獲取可用的broker列表，也可以在zookeeper中註冊listener，該listener在以下情況下會被喚醒：
a．新增乙個broker
b．刪除乙個broker
c．註冊新的topic
d．broker註冊已存在的topic
當producer得知以上時間時，可根據需要採取一定的行動。
0.8.0版本後，producer不再通過zookeeper連線broker, 而是通過brokerlist（192.168.0.1:9092,192.168.0.2:9092,192.168.0.3:9092配置和zookeeper時很像吶）直接和broker連線，只要能和乙個broker連線上就能夠獲取到集群中其他broker上的資訊
(2) broker
broker採取了多種策略提高資料處理效率，包括sendfile和zero copy等技術。
(3) consumer
consumer的作用是將日誌資訊載入到**儲存系統上。kafka提供了兩種consumer介面，
一種是low level的，它維護到某乙個broker的連線，並且這個連線是無狀態的，即，每次從broker上pull資料時，都要告訴broker資料的偏移量。
另一種是high-level 介面，它隱藏了broker的細節，允許consumer從broker上pull資料而不必關心網路拓撲結構。
更重要的是，對於大部分日誌系統而言，consumer已經獲取的資料資訊都由broker儲存，而在kafka中，由consumer自己維護所取資料資訊。
kafka是如何實現其高吞吐率及高可用行的？
kafka的集群有多個broker伺服器組成，每個型別的訊息被定義為topic，同一topic內部的訊息按照一定的key和演算法被分割槽(partition)儲存在不同的broker上，訊息生產者producer和消費者consumer可以在多個broker上生產/消費topic
以高吞吐率作為第一設計原則，kafka的結構設計在很多方面都做了激進的取捨。
① 極簡的資料結構和應用模式
訊息佇列是以log檔案的形式儲存，訊息生產者只能將訊息新增到既有的檔案尾部，沒有任何id資訊用於訊息的定位，完全依靠檔案內的位移，因此訊息的使用者只能依靠檔案位移順序讀取訊息，這樣也就不需要維護複雜的支援隨即讀取的索引結構。
kafka broker完全不維護和協調多使用者使用訊息的行為模式，consumer自己維護位移用來索引訊息,consumer將位移維護在zookeeper中，預設1分鐘自動提交一次，也可以手動commitoffset
topic最小的併發訪問單位就是partition分割槽，同一使用者組內（group.id）的所有使用者只能有乙個訪問同一分割槽，從0.8.0版本開始，分割槽個數是可以動態增加，可以通過增加分割槽數來優化傳送效能。
此外分割槽也帶來乙個問題就是訊息只是分割槽內部有序而不是全域性有序的。如果需要全域性有序，應用需要自己靠別的機制來保證。
使用pull模式拉取訊息，訊息的使用情況，比如是否還有consumer沒有讀取，是否重複讀取(改進中)等，在broker端也完全不跟蹤維護，訊息的過期處理簡單的由定時器定時刪除（比如保留7天），或者只保留最近100g的資料，由此簡化各種訊息跟蹤維護的開銷。
②追求最大化的資料傳輸效率
生產者和消費者可以批量讀寫訊息減少rpc開銷
使用zero copy在核心層直接將檔案內容傳送給網路socket，避免應用層資料拷貝
在傳輸訊息前，對資料進行壓縮
③激進的記憶體管理模式
kafka不在jvm程序內部維護訊息cache，訊息直接從檔案中讀寫，完全依賴作業系統在檔案系統層面的cache，避免在jvm中管理cache帶來的額外資料結構開銷和gc帶來的效能代價。基於批量處理和順序讀寫的應用模式，最大化利用檔案系統的cache機制和規避檔案讀寫相對記憶體讀寫的效能代價。對系統頁面快取的需求大。
④高可用性
kafka的0.8.0版本topic開始支援replicas。
bin/kafka-create-topic.sh --replica 3 --partition 8 --topic test --zookeeper localhost:2181
topic:test的每個partition會有3個備份,均衡負載在broker集群，其中乙個leader，其他2個follower做備胎，leader負責message的讀寫。leader和follower的資訊會記錄在zookeeper中，如果作為leader的broker掛了，zookeeper會在2個follower中選舉乙個做leader,用來讀寫message。leader收到producer傳送的message後，會有獨立的執行緒把massage同步到follower。
⑤資料一致性
之前提到replica不為1的情況下，原leader失去訊號， zookeeper會選舉乙個follower作為新的leader代替原leader的讀寫工作。
那麼怎麼保證原來leader和新leader之間的資料一致性呢？
kafka producer的ack有3中機制，初始化producer時的producerconfig可以通過配置request.required.acks不同的值來實現。
此選項提供最低的延遲但最弱的耐久性保證（當伺服器發生故障時某些資料會丟失，如leader已死，但producer並不知情，發出去的資訊broker就收不到）。
此選項提供了更好的耐久性為客戶等待伺服器確認請求成功（被寫入死亡leader但尚未複製將失去了唯一的訊息）。
-1：這意味著producer在follower副本確認接收到資料後才算一次傳送完成。
此選項提供最好的耐久性，我們保證沒有資訊將丟失，只要至少乙個同步副本保持存活。
三種機制，效能依次遞減 (producer吞吐量降低)，資料健壯性則依次遞增。
MapReduce核心思想
mapreduce核心程式設計思想，如圖1 1所示。圖1 1 mapreduce核心程式設計思想 1 分布式的運算程式往往需要分成至少 2個階段。2 第乙個階段的 maptask 併發例項，完全並行執行，互不相干。3 第二個階段的 reducetask 併發例項互不相干，但是他們的資料依賴於上乙個階...
Spring核心思想
spring三大核心思想分別是 控制反轉 ioc 依賴注入 di 面向切面程式設計 aop ioc 控制反轉 將元件間的關係從程式內部轉移至外部容器 xml檔案 中進行管理。di 依賴注入 元件間的依賴關係由系統執行期間決定。外部容器將帶有依賴關係的目標物件例項動態注入到系統中的各個元件中。ioc與...
ERP的核心思想
erp enterprise resource planning，企業資源計畫系統 的概念，是美國gartner group公司於1990年提出的，其確切定義是 mrp 企業製造資源計畫 下一代的製造業系統和資源計畫軟體。除了mrp 已有的生產資源計畫，製造 財務 銷售 採購等功能外，還有質量管理，...