0. 前情提要 1. 進擊的 Hadoop 2. Hadoop 家族 3. Hadoop 戰隊 4. Hadoop 富二代 5. Hadoop 小圈圈 6. 喝咖啡騎大象建議 因為這個題目其實包山包海，所以我們今天只把焦點放在 Hadoop 身上。 3 / 74 前情提要 4 / 74 由創建 Lucene 與 Nutch 的 Doug Cutting 主導開發 Lucene Query Real-Time Processing Graph Processing Iterative Modeling 人心不足蛇吞象 Hadoop 的體質 (Batch Processing) 問題： 每次就是一個 Batch Job，一個接著一個 每個 Batch Job 做的事就是讀入所有資料、處理、寫出結果 Job 與 Job 之間的 I/O Overhead 太高，但是彼此之間又沒有交集 / 74 MapReduce (MRv2) 分工優點 ResourceManager 其實是 Resource Arbitrator，要考量到 Capacity、Fairness、 SLA 等問題，也提供 Pluggable Interface 實作不同想法。 ApplicationMaster 其實是 MRv1 與 MRv2 最大的不同，負責與中央的 ResourceManager 與各地的

網路，通常有下列問題需要回答，如圖 2.17 所示。 有哪些開源的元件支援 Kubernetes 的網路模型？ 外部如何存取 Kubernetes 的叢集？ Kubernetes 的網路元件之間是如何通訊的？ Docker 自身的網路模型和限制？ Docker 背後的網路基礎是什麼？ Kubernetes 的網路模型是什麼？ 圖 2.17 Kubernetes 常見問題 在本節將分別 在本節將分別回答這些問題，然後透過一個具體的試驗，將這些相關的知識串聯在 一起。 2.5.1 Kubernetes 網路模型 Kubernetes 網路模型設計的一個基礎原則是：每個 Pod 都擁有一個獨立的 IP 位址， 而且假設所有 Pod 都在一個可以直接連線的、扁平的網路空間中。所以不管它們是 否運行在同一個 Node（Host 主機）中，都要求它們可以直接透過對方的 IP 進行存 取。 取。設計這個原則的主要原因是，使用者不需要額外考慮如何建立 Pod 之間的連 線，也不需要考慮將容器連接埠對應到主機連接埠等問題。 實際上在 Kubernetes 的世界裡，IP 是以 Pod 為單位來進行分配的。一個 Pod 內部 的所有容器共用一個網路底層堆疊（實際上就是一個網路命名空間，包括它們的 IP 2-70 Kubernetes 核心原理 2 PREROUTING 鏈 PREROUTING

Kubernetes支援最新的5個Kubernetes版本。其中最新的3個版本可獲 得完整功能、產品更新及安全性修補程式，比較舊的2個版本則僅獲得安全性更新。 這種更為廣泛的支援方式，可消除混合雲之中的問題，因為雲端供應商採用現行 Kubernetes修訂版的步調緩慢，並持續支援舊版本。 6. 邊緣支援 在邊緣運作對Kubernetes產生全新挑戰：資源的規模、大小及可存取性很快 將成為限制因素。C Single-node edition單節點版本 使用者如果想在單一裝置執行Kubernetes，目前有輕量級的發行版本專門用於提 供單節點叢集，並可透過抽象化技術，排除Kubernetes固有的部分複雜度問題。 Canonical Kubernetes及Rancher可分別透過MicroK8及K3支援單節點叢集。撰 寫本文時，Red Hat並未正式支援任何單節點OpenShift解決方案。 MicroK 為企業工作負載提供無可比擬的自動化程度及通用平台。不過Kubernetes本身是一 項高度複雜的技術，並不是所有企業都具有專業知識及時間在內部維護。完全託管的 Kubernetes叢集可消除此項問題，讓使用者將Kubernetes當成服務使用。廠商負責 運作叢集，使用者則將重心放在提供核心業務價值。 Canonical Kubernetes可讓企業選擇在裸機、OpenStack或任何公有雲使用完

service oriented architecture service mesh 單體式與微服務軟體架構對比 The Reformation 服務網格是一個輕量級的基礎架構組件，用來解決以下問題： ▪ 服務都在哪裡運行? ▪ 它們都健康嗎? ▪ 怎樣保證服務之間客戶無障礙安全互聯? ▪ 整個軟件的所有功能模塊是否都能夠容器化？ ▪ 是不是所有容器化了的微服務都能夠在同一個集群/數據中心/公有雲運帷？

程序的開源系統 ○ 根據資源需求和其他約束自動放置容器 ○ 自我修復，重新啟動失敗的容器 ○ 橫向縮放，自動調整應用程序副本數 ○ 自動部署和回滾，逐漸部署對應用程序或其配置的更改， 在出現 問題時恢復更改 Google Kubernetes Engine ● Google Kubernetes Engine GKE ○ 在 Google Cloud 提供技術的 Kubernetes

Runbook 是詳細的“how-to”指 南，用於完成運營流程中經常 重複的任務或程序。 • 創建 Runbook 的目的是為團 隊中的每個人（無論是新人還 是經驗豐富的人）提供快速準 確地解決特定問題的知識和步 驟。 21 每一個 alert 都應該要有 一個 runbook！ Ref. https://runbooks.prometheus-operator.dev/ Click to edit

. 16 7.2 刷盘策略 .......................................................................................................................................................... 18 7.2.1 异步刷盘 ........... .................................................................................... 18 7.2.2 同步刷盘 .................................................................................................. cpu、主板、内存等关键设备损坏） (6). 磁盘设备损坏。 (1)、(2)、(3)、(4)四种情冴都属亍硬件资源可立即恢复情冴，RocketMQ 在返四种情冴下能保证消息丌丢，戒 者丢失少量数据（依赖刷盘方式是同步迓是异步）。 (5)、(6)属亍单点故障，丏无法恢复，一旦収生，在此单点上的消息全部丢失。RocketMQ 在返两种情冴下，通 过异步复制，可保证 99%的消息丌丢，但是仍然会有极少

........................................................................................... 40 五：刷盘策略 ................................................................................................ PageCache 文件封装，操作物理文件在内存中的映射以及将内存数据持久 化到物理文件中， 代码中写死了要求 os 系统的页大小为 4k, 消息刷盘根据参数 （commitLog 默认至少刷 4 页, consumeQueue 默认至少刷 2 页）才刷 以下 io 对象构建了物理文件映射内存的对象 FileChannel fileChannel = new RandomAccessFile(file 件还是有点耗时的， getMinOffset 获取队列消息最少偏移量，即第一个文件的文件起始偏移量 getMaxOffset 获取队列目前写到位置偏移量 getCommitWhere 刷盘刷到哪里了 5) DefaultMessageStore 消息存储层实现 (1) putMessage 添加消息委托给 commitLog.putMessage(msg)，主要流程：

Broker的角色，AYNSC_MASTER=异步复制master，SYNC_MASTER=同步双写master，SLAVE= lave节点 brokerRole=ASYNC_MASTER # 刷盘方式，ASYNC_FLUSH=异步刷盘，SYNC_FLUSH=同步刷盘 flushDiskType=ASYNC_FLUSH # broker对外服务的监听端口 listenPort=10911 # nameServer地址，如果name Broker的角色，AYNSC_MASTER=异步复制master，SYNC_MASTER=同步双写master，SLAVE= lave节点 brokerRole=SLAVE # 刷盘方式，ASYNC_FLUSH=异步刷盘，SYNC_FLUSH=同步刷盘 flushDiskType=ASYNC_FLUSH # broker对外服务的监听端口 listenPort=11011 # nameServer地址，如果name Broker的角色，AYNSC_MASTER=异步复制master，SYNC_MASTER=同步双写master，SLAVE= lave节点 brokerRole=ASYNC_MASTER # 刷盘方式，ASYNC_FLUSH=异步刷盘，SYNC_FLUSH=同步刷盘 flushDiskType=ASYNC_FLUSH # broker对外服务的监听端口 listenPort=10911 # nameServer地址，如果name

何商业行为。 7 > 开篇：我的另一种参与 RocketMQ 开源社区的方式  RocketMQ 为什么性能高效，到底运用了什么“厉害”的技术？  RocketMQ 如何实现刷盘（可以类比一下数据库方面的刷盘、redo、undo 日志）？  RocketMQ 文件存储设计理念、基于文件的 Hash 索引是怎么实现的?  定时消息、消息过滤等实现原理。  如何进行网络编程（Netty 读消息走的是 PageCache(对于,DirectByteBuffer 是两步刷盘，一步是刷到 PageCache，还有一步 本文来自『中间件兴趣圈』公众号，仅作技术交流，未授权任何商业行为。 1.9 RocketMQ 消息发送 system busy、broker busy 原因分析与解决方案坑 < 98 是刷到磁盘文件中)，带来的好处就是，避免了内存操作的很多容易堵的地方，降低了时延， config 中将 transientStorePoolEnable=true。 方案依据：启用“读写”分离，消息发送时消息先追加到 DirectByteBuffer(堆外内存) 中，然后在异步刷盘机制下，会将 DirectByteBuffer 中的内容提交到 PageCache，然后 刷写到磁盘。消息拉取时，直接从 PageCache 中拉取，实现了读写分离，减轻了 PageCaceh 的压力，能从根本上解决该问题。