前言
當面對一個複雜的分佈式系統時，如果我們想了解其內部運行的情況，我們通常的做法是進行內部指標metric的收集和暴露。但是如果我們遇到一些內部指標的統計需要進行系統服務內部邏輯的大規模改動或者目標metric的指標收集操作會影響到服務的正常請求處理，那麼這個時候我們有沒有好的辦法呢？最完美的方法無疑是搭建出一個元數據完全一致的READ-ONLY模式的系統，注意了這裏指的是一個獨立的服務。本文筆者將以Ozone的Recon服務爲例，來聊聊這個只讀模式的系統應該如何來做。
Ozone Recon模式的運作原理
在Ozone中，就做了這麼一個只讀模式的SCM服務，名字叫Recon服務。Recon用來做SCM內的Container情況的分析。
Recon作爲只讀模式的SCM，它理應持有完全一致的Container信息，這樣才能做準確的模擬分析。但這裏有個問題，Recon不能處理來自外部的Container寫請求操作的。對於這種情況的處理，Recon採用了下面的辦法：
- 1）Recon從SCM服務節點上同步一份初始Container db文件。
- 2）Datanode額外配置Recon的地址作爲Container Report的另外一個心跳報告地址。
- 3）Recon和SCM一樣，同樣接受下面Datanode的Container報告信息，進行內部Container狀態的更新。
- 4）當Recon接受到新的Container時，它需要額外向SCM服務查詢，此Container是否是有效的Container，如果是，則添加到自身內存中。
- 5）Datanode將會實現對於來自於SCM的Container Delete操作的ACK回覆，表明其已正確刪除本地的Container。Recon可以利用此ACK回覆正式移除其維護的對應Container信息。
Recon採用了上述的方案後，就能保證和SCM主服務完全一致的內存元數據信息了，然後它就可以做許多靈活的自定義分析了，並且它不會影響到SCM服務的運行。假設沒有這樣一個“影子”系統，我們想要的部分系統分析將會受制於系統內部的本身邏輯實現等原因。
以下爲上述步驟的流程圖展示：
總結
不過筆者在這裏不僅僅是隻想談Ozone Recon的原理過程，而想表達的是Ozone Recon的只讀模式系統實現原理具有通用性。它的實現思路完全適用於類似的其它基於心跳 report進行狀態同步的分佈式存儲系統。在這點上，它的這個實現方式是具有通用性的。 而且作爲只讀的系統，它不進行任何報告的action回覆指令操作，風險也很低，對其下報告的slave節點沒有任何的影響。
引用
[1].https://issues.apache.org/jira/browse/HDDS-1996 . Ozone Recon Service v0.2