掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
RocketMQ分布式消息中間件(核心原理與最佳實踐) 版權信息
- ISBN：9787121392672
- 條形碼：9787121392672 ; 978-7-121-39267-2
- 裝幀：一般膠版紙
- 冊數：暫無
- 重量：暫無
- 所屬分類：>>
RocketMQ分布式消息中間件(核心原理與最佳實踐) 本書特色
適讀人群 ：對RocketMQ有了解、使用的經驗后，想要深入源碼而無從下手的人員。 ?? 希望學習消息隊列和分布式系統的開發人員。 ?? 企業消息中間件維護和支持人員。 ?? RocketMQ代碼貢獻者。 ?? 支持開源的技術工作者。編輯推薦 權威：Apache RocketMQ Committer編著 實用：本書分享筆者近年來在企業中治理RocketMQ的經驗和所踩的坑 全面：筆者根據實踐整理了RocketMQ的核心組件配置項和其說明，包含： Namesrv全部配置項（17個） Broker全部配置項（141個） Prometheus Exporter核心監控指標（82個） 圖文+源碼：大量圖文+代碼快分析，讀者更易理解RocketMQ原理與代碼實現邏輯
RocketMQ分布式消息中間件(核心原理與最佳實踐) 內容簡介
本書源碼以RocketMQ 4.2.0和RocketMQ 4.3.0為基礎，從RocketMQ的實際使用到RocketMQ的源碼分析，再到RocketMQ企業落地實踐方案，逐步講解。使讀者由淺入深地了解RocketMQ。本書在源碼分析過程中，先講整體流程，再按模塊、步驟進行詳細講解，希望讀者在閱讀時能舉一反三，能知其然且知其所以然。本書總共九章，分為五部分，部分講解消息隊列入門和RocketMQ生產、消費原理與很好實踐；第二部分從整體角度講解RocketMQ架構；第三部分講解RocketMQ各個組件的基本原理；第四部分深入RocketMQ，講解如何閱讀源代碼、如何進行企業實踐；第五部分是附錄，包含Namesrv、Broker的核心參數配置說明和Exporter監控指標注釋。希望讀者在平時的工作中能熟悉、借鑒、參考RocketMQ的很好設計理念，在技術能力上更進一步，在工作中更好地服務公司。希望讀者在平時的工作中能熟悉、借鑒、參考RocketMQ的很好設計理念，在技術能力上更進一步，在工作中更好地服務公司。
RocketMQ分布式消息中間件(核心原理與最佳實踐) 目錄
目 錄
第1章 RoketMQ綜述 1
1．1 什么是消息隊列 2
1．2 為什么需要消息隊列 4
1．2．1 削峰填谷 4
1．2．2 程序間解耦 5
1．2．3 異步處理 6
1．2．4 數據的*終一致性 6
1．3 常見消息隊列 7
1．4 RocketMQ的發展史與未來 9
1．4．1 RocketMQ的發展史 9
1．4．2 Apache RocketMQ的未來 11
第2章 RocketMQ的生產者原理和*佳實踐 14
2．1 生產者原理 15
2．1．1 生產者概述 15
2．1．2 消息結構和消息類型 16
2．1．3 生產者高可用 17
2．2 生產者啟動流程 22
2．3 消息發送流程 32
2．4 發送消息*佳實踐 36
2．4．1 發送普通消息 36
2．4．2 發送順序消息 37
2．4．3 發送延遲消息 37
2．4．4 發送事務消息 38
2．4．5 發送單向消息 40
2．4．6 批量消息發送 41
2．5 生產者*佳實踐總結 42
第3章 RocketMQ的消費流程和*佳實踐 44
3．1 消費者概述 45
3．1．1 消費流程 45
3．1．2 消費模式 46
3．1．3 可靠消費 48
3．2 消費者啟動機制 50
3．3 消費者的Rebalance機制 58
3．4 消費進度保存機制 65
3．5 消費方式 70
3．5．1 Pull消費流程 71
3．5．2 Push消費流程 72
3．6 消息過濾 86
3．6．1 為什么要設計過濾功能 86
3．6．2 RocketMQ支持消息過濾 86
3．7 消費者*佳實踐總結 91
第4章 RocketMQ架構和部署*佳實踐 94
4．1 RocketMQ架構 95
4．2 常用的部署拓撲和部署實踐 96
4．2．1 常用的拓撲圖 96
4．2．2 同步復制、異步復制和同步刷盤、異步刷盤 97
4．2．3 部署實踐 98
第5章 Namesrv 102
5．1 Namesrv概述 103
5．1．1 什么是Namesrv 103
5．1．2 Namesrv核心數據結構和API 103
5．1．3 Namesrv和Zookeeper 105
5．2 Namesrv架構 106
5．2．1 Namesrv組件 106
5．2．2 Namesrv啟動流程 108
5．2．3 Namesrv停止流程 110
5．3 RocketMQ的路由原理 111
5．3．1 路由注冊 111
5．3．2 路由剔除 112
第6章 Broker存儲機制 114
6．1 Broker概述 115
6．1．1 什么是Broker 115
6．1．2 Broker存儲目錄結構 116
6．1．3 Broker啟動和停止流程 117
6．2 Broker存儲機制 125
6．2．1 Broker消息存儲結構 126
6．2．2 Broker消息存儲機制 130
6．2．3 Broker讀寫分離機制 150
6．3 Broker CommitLog索引機制 155
6．3．1 索引的數據結構 155
6．3．2 索引的構建過程 158
6．3．3 索引如何使用 159
6．4 Broker過期文件刪除機制 162
6．4．1 CommitLog文件的刪除過程 162
6．4．2 Consume Queue、Index File文件的刪除過程 166
6．5 Broker主從同步機制 167
6．5．1 主從同步概述 168
6．5．2 主從同步流程 169
6．6 Broker的關機恢復機制 174
6．6．1 Broker關機恢復概述 174
6．6．2 Broker關機恢復流程 177
第7章 RocketMQ特性――事務消息與延遲消息機制 182
7．1 事務消息概述 183
7．2 事務消息機制 184
7．2．1 生產者發送事務消息和執行本地事務 184
7．2．2 Broker存儲事務消息 188
7．2．3 Broker回查事務消息 191
7．2．4 Broker提交或回滾事務消息 197
7．3 延遲消息概述 201
7．4 延遲消息機制 203
7．4．1 延遲消息存儲機制 203
7．4．2 延遲消息投遞機制 205
第8章 RocketMQ源代碼閱讀 208
8．1 RocketMQ源代碼結構概述 209
8．2 RocketMQ源代碼編譯 212
8．3 如何閱讀源代碼 214
8．4 源代碼閱讀范例：通過消息id查詢消息 216
第9章 RocketMQ企業*佳實踐 224
9．1 RocketMQ落地概述 225
9．1．1 為什么選擇RocketMQ 225
9．1．2 如何做RocketMQ的集群管理 226
9．2 RocketMQ集群管理 230
9．2．1 Topic管理 230
9．2．2 消費者管理 235
9．3 RocketMQ集群監控和報警 240
9．3．1 監控和報警架構 240
9．3．2 基于Grafana監控 242
9．3．3 基于Prometheus的報警 243
9．4 RocketMQ集群遷移 244
9．5 RocketMQ測試環境實踐 245
9．6 RocketMQ接入實踐 247
9．6．1 Spring接入RocketMQ 247
9．6．2 Python接入RocketMQ 249
附錄 252
展開全部
RocketMQ分布式消息中間件(核心原理與最佳實踐) 節選
第9章RocketMQ企業*佳實踐 前面幾章介紹了RocketMQ各個組件的功能和基本原理，本章主要介紹RocketMQ如何在企業落地，主要內容如下： l RocketMQ集群管理。 l RocketMQ集群監控和報警。 l RocketMQ集群測試環境實踐。 l Spring和Python如何接入RocketMQ？ 9.1 RocketMQ落地概述 9.1.1 為什么選擇RocketMQ 一款技術產品要在企業落地是非常困難的，筆者總結了幾個要點，供讀者在選擇一款技術產品時參考：穩定可靠、運維與管理方便、低成本、性能考量。 接下來，我們對消息隊列中間件的選型做詳細分析。 業務需求永遠是**需求。對業務而言，組件能夠穩定、可靠、可持續地保障業務正常流轉肯定是首要的需求。在經歷過阿里巴巴、VIPKID、螞蟻金服、微眾銀行等對于穩定性有極致需求的大廠洗禮后，穩定、可靠成為了RocketMQ的代言詞。 作為技術人員，一款產品的管理、運維和開發的難易程度也是選型的重要參考指標。現代互聯網公司不同于傳統企業，快速迭代、快速把握市場才是王道。簡單、方便的產品能快速支持業務起步，對開發者友好的或者自研的產品總是容易掌控，也能快速適應業務的發展和變化。 RocketMQ使用Java語言開發，做二次開發或集成到現有系統難度較低。RocketMQ社區也相當活躍，文檔包含中英文，對國內開發者非常友好。同時，社區提供的管理平臺功能完善，更新也比較活躍，RocketMQ的衍生產品也非常豐富，比如rocketmq-connect-es、rocketmq-flink、rocketmq-hbase等。 成本，對于商業公司是必須要考慮的。這里的成本包含硬成本和軟成本，如圖9-1所示。 下面，我們介紹一下硬成本。服務器成本：技術產品都需要部署在硬件服務器上才能提供服務，硬件包含內存、CPU、磁盤等耗材，配置越高花費越大。 軟件授權成本：對開源產品而言，雖然企業付出的金錢成本為0，更多的卻是責任。RocketMQ在阿里巴巴內部從一個普通技術項目到一個可靠的、可用的技術項目經歷了11年（從2001年到2012年），從一個技術項目再到技術產品經歷了4年（從2012年到2016年），從阿里巴巴走向Apache的開源之路又經歷了4年（從2016年到現在2020年），總共經歷了19年，阿里巴巴和社區的付出有多少我們難以想象。作為一個普通的技術從業者，“拿來主義”不提倡，投桃報李方可行。 對于軟成本，筆者覺得比硬成本更重要，因為它是看不見的，往往被大家忽略。可能很多人追求技術的創新卻忘記了軟成本，導致留下無數的技術債，隨著業務不斷發展，技術壁壘也愈發明顯。 *后一個重要的考慮：性能。2020年互聯網行業仍然是流量的行業，高并發、大吞吐是當前面臨的*大挑戰之一。RocketMQ在阿里巴巴內部各個平臺都廣泛使用，并且成功支撐了多個雙11萬億級別的消息流量，充分證明了RocketMQ強大的吞吐能力。 9.1.2 如何做RocketMQ的集群管理 RocketMQ的集群管理主要是對集群中Broker、Namesrv、Topic、生產者、消費者進行統一管控。 RocketMQ本身提供了一系列的管理接口，具體實現在org.apache.rocketmq.tools.admin. DefaultMQAdminExt.java文件中，源代碼結構如圖9-2所示。 一般在生成環境中嚴禁開放自動創建Topic和消費者組，需要通過API進行統一管理。下面簡單列出了4.2.0版本支持的一些管理API，如表9-1所示，供大家在自研治理系統時參考。當然原生工具也提供命令行管理。 表9-1的大部分核心功能在社區提供的RocketMQ-Console管理平臺中都有，筆者建議使用RocketMQ-Console或者像VIPKID一樣自研一套管理平臺替代命令行操作，這樣更加安全可靠。如何搭建RocketMQ-Console在4.2.2節中有詳細的描述，讀者可以按照描述一步步操作搭建。 在VIPKID，我們基于RocketMQ開發了VKMQ（VIPKID消息隊列），包含Broker、 Namesrv、游樂場管理平臺、基于Prometheus的監控報警模塊（Prometheus Exporter代碼已經貢獻給Apache社區，可以直接下載使用）等整套生態，負責中國、美國等世界幾十個國家和地區之間的消息扭轉，目前的生產環境已穩定地運行了兩年多。 在VIPKID，*重要的不是知道如何管理集群，而是要知道在管理方法后面的每一個操作都需要有Double-Check。 接下來，筆者將基于社區版RocketMQ Console講解企業在踐行RocketMQ時遇到的問題較多的場景。 9.2 RocketMQ集群管理 9.2.1 Topic管理 Topic管理是集群管理中常見的操作，包括創建Topic、查看Topic路由、修改Topic配置、重置消費位點。 1．創建Topic 創建Topic的核心在于，你需要知道Topic和隊列（Queue）的關系，也叫Topic路由分布，下面展示一個名為topicA的Topic路由關系，如圖9-3所示。 如圖9-3所示，topicA有4個Queue，分布在兩臺Broker上。當有消息發送的時候，默認會均勻地發送給這4個Queue。 接下來我們看看如何在RocketMQ Console上創建topicA。 我們進入Topic管理頁面，單擊“新增/更新”按鈕，會出現如圖9-4所示的彈窗。 下面將依次講解每個輸入框的含義。 集群名：RocketMQ集群名，和下一個選項BROKER_NAME二者選其一，如果選擇集群名，則表示這個新建Topic的Queue會分布在這個集群的全部Broker中。 BROKER_NAME：RocketMQ Broker的名字，選擇后新建Topic的Queue會分布在選中的Broker機器上。集群名和BROKER_NAME只需選擇一個就可以。 主題名：Topic名字，字符串長度不能超過255，不能與系統默認名字沖突，還需要滿足正則表達式：^[%|a-zA-Z0-9_-]+$。 讀/寫隊列數量：每臺Broker上Queue的數量，建議設置為相同值。 perm：Topic權限，這是一個常量，該常量的定義在org.apache.rocketmq.common. constant.PermName類中。2表示只寫，4表示只讀，6表示讀寫均可。 創建完成后，檢查創建的Topic是否和我們預期的一致。刷新頁面后，搜索剛剛創建的topicA，單擊“路由信息”按鈕，可以看到topicA的路由信息如圖9-5所示。 更新Topic在實際業務場景中會經常用到，我們通過兩個場景進行具體的講解。 場景1：Topic擴容 如果在實際業務中發現當前的發送效率已經不能滿足業務需求，那么擴容是一種常用的處理手段。如圖9-3所示，接受topicA消息的全部壓力都在master broker 1和master broker 2上，我們怎樣才能用新機器分攤壓力呢？ **步：部署新的master broker 3、master broker 4機器，部署步驟詳見4.2.2節。 第二步：回到RocketMQ Console平臺的Topic管理頁面，單擊“新增/更新”按鈕。 第三步：如圖9-4所示，在BROKER_NAME輸入框中選擇新加的Broker。在輸入Queue數量時要注意讀、寫Queue的數值表示在單臺Broker中的數量，如果想將一半的流量分流到新的Broker中，那么讀、寫Queue數量都填2。擴容后topicA的發送效率將增加一倍，新舊2組機器壓力承擔比例為1:1，擴容后topicA的路由圖變成如圖9-6所示的樣子。 場景2：Topic權限更改 如圖9-6所示，如果擴容后Master Broker 4機器有問題，那么理論上topicA會有1/4的消息發送失敗，此時可以更改topicA在Master Broker 4上的權限為0，表示不可讀、不可寫，如圖9-7所示。 我們稍加分析可知，master broker 4在禁止讀寫后，topicA的路由會改變，全部的生產者在感知到路由變化后，不再將消息發送到master broker 4。 消費者在進行Rebalance后，也會感知topicA的路由發生變化，將不再從master broker 4拉取消息消費。
RocketMQ分布式消息中間件(核心原理與最佳實踐) 作者簡介
李偉 Apache RocketMQ北京社區聯合發起人，RocketMQ項目Commiter，RocketMQ社區Python客戶端項目負責人。目前就職于北京某在線教育公司，擔任數據中間 件架構師，負責公司內部消息和數據流平臺，對分布式存儲系統設計和研發有豐富經驗，熱衷于知識分享和社區活動。 座右銘：Programming is not only a way to problems,but also to think！ RocketMQ社區 RocketMQ是Apache軟件基金會(Apache Software Foundation，簡稱ASF)運作的一個高級開源軟件項目。 Apache軟件基金會成立于1999年，是一個運作開源軟件的非營利性組織。截至目前，擁有個人成員數730+、Commiter數7000+、ASF運營項目數350+，我們所熟知的開源項目有依賴管理工具Apache Maven，Web服務器Apache Tomcat，數據存儲Apache HBase、Apache Hive，計算引擎Apache Flink、Apache Hadoop等。 歡迎加入Apache RocketMQ國內討論釘釘群：
書友推薦
- >
山海經
- >
【精裝繪本】畫給孩子的中國神話
- >
史學評論
- >
大紅狗在馬戲團-大紅狗克里弗-助人
- >
名家帶你讀魯迅:朝花夕拾
- >
我與地壇
- >
隨園食單
- >
新文學天穹兩巨星--魯迅與胡適/紅燭學術叢書(紅燭學術叢書)
本類暢銷
