消息隊列與數據庫

  • Kafka架構原理【1】:
kafka架構
kafka架構

1、消費模式:producer使用push模式,consumer使用pull模式。

tips:如果採用 Push,消息消費的速率就完全由消費代理控制,一旦消費者發生阻塞,就會出現問題。

Kafka 採取拉取模型(Pull),由自己控制消費速度,以及消費的進度,消費者可以按照任意的偏移量進行消費。

2、broker和consumer使用zookeeper,producer可以指定多個broker的url,producer通過broker獲取整個集羣的broker列表信息,將broker源信息存入producer內存中。

producer刷新broker源信息的觸發方式:

1)producer向broker發送失敗時出發重新獲取broker源信息;

2)配置週期性刷新;

3、Topic 和 Partition:每一條消息都有一個 topic,Kafka 爲每個主題維護了分佈式的分區(Partition)日誌文件,分區的目的是爲了做負載均衡。

KAFKA維護一個Topic中的分區log,以順序追加的方式向各個分區中寫入消息,每個分區都是不可變的消息隊列。分區中的消息都是以k-v形式存在。k表示offset,稱之爲偏移量,一個64位整型的唯一標識,offset代表了Topic分區中所有消息流中該消息的起始字節位置。v就是實際的消息內容,每個分區中的每個offset都是唯一存在的,所有分區的消息都是一次寫入,在消息未過期之前都可以調整offset來實現多次讀取。

生產者會決定發送到哪個 Partition,如果沒有 Key 值則進行輪詢發送;如果有 Key 值,對 Key 值進行 Hash,然後對分區數量取餘,保證了同一個 Key 值的會被路由到同一個分區。對於分區可以有副本機制保證高可用。

4、冪等性:每個 Producer 在初始化的時候都會被分配一個唯一的 PID,對於每個唯一的 PID,Producer 向指定的 Topic 中某個特定的 Partition 發送的消息都會攜帶一個從 0 單調遞增的 Sequence Number。

如果消息序號比 Broker 維護的序號大一以上,說明中間有數據尚未寫入,也即亂序,此時 Broker 拒絕該消息,Producer 拋出 InvalidSequenceNumber。

如果消息序號小於等於 Broker 維護的序號,說明該消息已被保存,即爲重複消息,Broker 直接丟棄該消息,Producer 拋出 DuplicateSequenceNumber。

如果消息序號剛好大一,就證明是合法的。

5、事務:上面所說的都是在同一個 PID 下面,意味着必須保證在單個 Producer 中的同一個 Seesion 內,如果 Producer 掛了,被分配了新的 PID,這樣就無法保證了,所以 Kafka 中又有事務機制去保證。

1)在 Kafka 的事務中,應用程序必須提供一個唯一的事務 ID,即 Transaction ID,並且宕機重啓之後,也不會發生改變。Transactin ID 與 PID 可能一一對應,區別在於 Transaction ID 由用戶提供,而 PID 是內部的實現對用戶透明。

2)爲了 Producer 重啓之後,舊的 Producer 具有相同的 Transaction ID 失效,每次 Producer 通過 Transaction ID 拿到 PID 的同時,還會獲取一個單調遞增的 Epoch。由於舊的 Producer 的 Epoch 比新 Producer 的 Epoch 小,Kafka 可以很容易識別出該 Producer 是老的,Producer 並拒絕其請求。

3)該 Transaction Coordinator 服務器端的模塊用於管理 Producer 發送的消息的事務性,作用是保證操作的原子性,要麼全部成功,要麼全部失敗;有狀態的操作的恢復。通過維護 Transaction Log,該 Log 存於一個內部的 Topic 內。Transaction Log 的設計與 Offset Log 用於保存 Consumer 的 Offset 類似。

  • Kafka高性能【2】:

1、消息順序寫入磁盤。

2、消息集合在一起批量發送,這樣減少對磁盤IO的過度讀寫,而不是一次發送單個消息。

3、KAFKA採用由Producer,broker和consumer共享的標準化二進制消息格式,這樣數據塊就可以在它們之間自由傳輸,無需轉換,降低了字節複製的成本開銷。

4、Kafka重度依賴底層操作系統提供的PageCache功能。當上層有寫操作時,操作系統只是將數據寫入PageCache,同時標記Page屬性爲Dirty。當讀操作發生時,先從PageCache中查找,如果發生缺頁才進行磁盤調度,最終返回需要的數據。實際上PageCache是把儘可能多的空閒內存都當做了磁盤緩存來使用。

5、sendfile,只需要一次拷貝就行:允許操作系統將數據直接從頁緩存發送到網絡上。

這種頁緩存和sendfile組合,意味着KAFKA集羣的消費者大多數都完全從緩存消費消息,而磁盤沒有任何讀取活動。

6、批量壓縮,批量的消息可以通過壓縮的形式傳輸並且在日誌中也可以保持壓縮格式,直到被消費者解壓縮。

  • mysql鎖機制【3】:

MyISAM表鎖:表共享讀鎖(Table Read Lock)和表獨佔寫鎖(Table Write Lock),MyISAM默認加鎖。默認允許沒有空洞(即表的中間沒有被刪除的行),MyISAM允許在一個進程讀表的同時,另一個進程從表尾插入記錄。

InnoDB鎖:一是支持事務(TRANSACTION);二是採用了行級鎖。

1、行級鎖:共享鎖(s):

1)又稱讀鎖、排他鎖(X):又稱寫鎖;

2)如果當前事務也需要對該記錄進行更新操作,則很有可能造成死鎖,對於鎖定行記錄後需要進行更新操作的應用,應該使用SELECT… FOR UPDATE方式獲得排他鎖;

3)只有通過索引條件檢索數據,InnoDB才使用行級鎖,否則,InnoDB將使用表鎖! 

2、間隙鎖(Next-Key鎖)

當我們用範圍條件而不是相等條件檢索數據,並請求共享或排他鎖時,InnoDB會給符合條件的已有數據記錄的索引項加鎖;對於鍵值在條件範圍內但並不存在的記錄,叫做“間隙(GAP)”,InnoDB也會對這個“間隙”加鎖

 

 

【1】https://www.jianshu.com/p/4bf007885116    《Kafka的架構原理,你真的理解嗎?》

【2】http://rdcqii.hundsun.com/portal/article/709.html    《KAFKA:如何做到1秒發佈百萬級條消息》

【3】https://www.cnblogs.com/leedaily/p/8378779.html    《Mysql中的鎖機制》

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章