kafka中controller的作用_Kafka 常见问题汇总
Kafka 如何做到高吞吐、低延遲呢？
這里提下 Kafka 寫數據的大致方式：先寫操作系統的頁緩存(Page Cache),然后由操作系統自行決定何時刷到磁盤。
因此 Kafka 達到高吞吐、低延遲的原因主要有以下 4 點：
- 頁緩存是在內存中分配的，所以消息寫入的速度很快。
- Kafka 不必和底層的文件系統進行交互，所有繁瑣的 I/O 操作都由操作系統來處理。
- Kafka 采用追加寫的方式，避免了磁盤隨機寫操作。
- 使用以 sendfile 為代表的零拷貝技術提高了讀取數據的效率。
PS: 使用頁緩存而非堆內存還有一個好處，就是當 Kafka broker 的進程崩潰時，堆內存的數據會丟失，但是頁緩存的數據依然存在，重啟 Kafka broker 后可以繼續提供服務。
2. Kafka 的 producer 工作流程？
3. Kafka 的 consumer 工作流程？
4. 重要參數有哪些？
- acks = 0 : 不接收發送結果
- acks = all 或者 -1: 表示發送消息時，不僅要寫入本地日志，還要等待所有副本寫入成功。
- acks = 1: 寫入本地日志即可，是上述二者的折衷方案，也是默認值。
- 默認為 0，即不重試，立即失敗。一個大于 0 的值，表示重試次數。
- 指定 producer 端用于緩存消息的緩沖區的大小，默認 32M；適當提升該參數值，可以增加一定的吞吐量。
- producer 會將發送分區的多條數據封裝在一個 batch 中進行發送，這里的參數指的就是 batch 的大小。該參數值過小的話，會降低吞吐量，過大的話，會帶來較大的內存壓力。默認為 16K，建議合理增加該值。
5. 丟失數據的場景？
- consumer 端：不是嚴格意義的丟失，其實只是漏消費了。
設置了 auto.commit.enable=true ，當 consumer fetch 了一些數據但還沒有完全處理掉的時候，剛好到 commit interval 觸發了提交 offset 操作，接著 consumer 掛掉。這時已經fetch的數據還沒有處理完成但已經被commit掉，因此沒有機會再次被處理，數據丟失。 - producer 端：
I/O 線程發送消息之前，producer 崩潰， 則 producer 的內存緩沖區的數據將丟失。
6. producer 端丟失數據如何解決？
- 同步發送，性能差，不推薦。
- 仍然異步發送，通過“無消息丟失配置”(來自胡夕的《Apache Kafka 實戰》)極大降低丟失的可能性：
7. consumer 端丟失數據如何解決？
enable.auto.commit=false 關閉自動提交位移，在消息被完整處理之后再手動提交位移
8. 重復數據的場景？
網絡抖動導致 producer 誤以為發送錯誤，導致重試，從而產生重復數據，可以通過冪等性配置避免。
9. 分區策略(即生產消息時如何選擇哪個具體的分區)？
- 指定了 key ，相同的 key 會被發送到相同的分區；
- 沒有指定 key，通過輪詢保證各個分區上的均勻分配。
10. 亂序的場景？
消息的重試發送。
11. 亂序如何解決？
參數配置 max.in.flight.requests.per.connection = 1 ，但同時會限制 producer 未響應請求的數量，即造成在 broker 響應之前，producer 無法再向該 broker 發送數據。
12. 如何選擇 Partiton 的數量？
- 在創建 Topic 的時候可以指定 Partiton 數量，也可以在創建完后手動修改。但 Partiton 數量只能增加不能減少。中途增加 Partiton 會導致各個 Partiton 之間數據量的不平等。
- Partition 的數量直接決定了該 Topic 的并發處理能力。但也并不是越多越好。Partition 的數量對消息延遲性會產生影響。
- 一般建議選擇 Broker Num * Consumer Num ，這樣平均每個 Consumer 會同時讀取 Broker 數目個 Partition ， 這些 Partition 壓力可以平攤到每臺 Broker 上。
13. 可重試的異常情況有哪些？
- 分區的 leader 副本不可用，一般發生再 leader 換屆選舉時。
- controller 當前不可用，一般是 controller 在經歷新一輪的選舉。
- 網絡瞬時故障。
14. controller 的職責有哪些？
在 kafka 集群中，某個 broker 會被選舉承擔特殊的角色，即控制器(controller)，用于管理和協調 kafka 集群，具體職責如下：
- 管理副本和分區的狀態
- 更新集群元數據信息
- 創建、刪除 topic
- 分區重分配
- leader 副本選舉
- topic 分區擴展
- broker 加入、退出集群
- 受控關閉
- controller leader 選舉
15. leader 掛了會怎樣？(leader failover)
當 leader 掛了之后，controller 默認會從 ISR 中選擇一個 replica 作為 leader 繼續工作，條件是新 leader 必須有掛掉 leader 的所有數據。
如果為了系統的可用性，而容忍降低數據的一致性的話，可以將 unclean.leader.election.enable = true ，開啟 kafka 的"臟 leader 選舉"。當 ISR 中沒有 replica，則會從 OSR 中選擇一個 replica 作為 leader 繼續響應請求，如此操作提高了 Kafka 的分區容忍度，但是數據一致性降低了。
16. broker 掛了會怎樣？(broker failover)
broker上面有很多 partition 和多個 leader 。因此至少需要處理如下內容：
- 更新該 broker 上所有 follower 的狀態
- 從新給 leader 在該 broker 上的 partition 選舉 leader
- 選舉完成后，要更新 partition 的狀態，比如誰是 leader 等
kafka 集群啟動后，所有的 broker 都會被 controller 監控，一旦有 broker 宕機，ZK 的監聽機制會通知到 controller， controller 拿到掛掉 broker 中所有的 partition，以及它上面的存在的 leader，然后從 partition的 ISR 中選擇一個 follower 作為 leader，更改 partition 的 follower 和 leader 狀態。
17. controller 掛了會怎樣？(controller failover)
- 由于每個 broker 都會在 zookeeper 的 "/controller" 節點注冊 watcher，當 controller 宕機時 zookeeper 中的臨時節點消失
- 所有存活的 broker 收到 fire 的通知，每個 broker 都嘗試創建新的 controller path，只有一個競選成功并當選為 controller。
18. Zookeeper 為 Kafka 做了什么？
19. Page Cache 帶來的好處。
Linux 總會把系統中還沒被應用使用的內存挪來給 Page Cache，在命令行輸入free，或者 cat /proc/meminfo，“Cached”的部分就是 Page Cache。
Page Cache 中每個文件是一棵 Radix 樹(又稱 PAT 位樹, 一種多叉搜索樹)，節點由 4k 大小的 Page 組成，可以通過文件的偏移量(如 0x1110001)快速定位到某個Page。
當寫操作發生時，它只是將數據寫入 Page Cache 中，并將該頁置上 dirty 標志。
當讀操作發生時，它會首先在 Page Cache 中查找，如果有就直接返回，沒有的話就會從磁盤讀取文件寫入 Page Cache 再讀取。
可見，只要生產者與消費者的速度相差不大，消費者會直接讀取之前生產者寫入Page Cache的數據，大家在內存里完成接力，根本沒有磁盤訪問。
而比起在內存中維護一份消息數據的傳統做法，這既不會重復浪費一倍的內存，Page Cache 又不需要 GC (可以放心使用60G內存了)，而且即使 Kafka 重啟了，Page Cache 還依然在。
出處：http://dwz.date/bvVf
總結
以上是生活随笔為你收集整理的kafka中controller的作用_Kafka 常见问题汇总的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 图像处理、语音处理的应用及前沿技术_人工
- 下一篇： 学完python_学完Python都可以