針對以上問題和性能分析點，進行了以下優化，分別是：

1）基礎探測圖按rid分層染色計算所有點到點路徑，零拷貝

        萃取整個路徑算法需要修改的部分，單獨創建一個臨時變量用于不可避免的一次路徑計算過程中寫操作，防止任何一次兩點路徑計算更改全局基礎探測圖操作，這樣一個頻道下任意兩點之間路徑并按rid分層染色計算路徑都可以在一個基礎探測圖里實現，而不是每次進行兩點之間路徑計算就拷貝一次基礎探測圖，賦值及循環耗時非常大。

2）按rid再細粒度拆分路徑計算任務

        在之前，最小路徑計算單元是點到點之間的路徑計算，如果遇到一個點里有多rid，則在計算點到點路徑時串行循環計算rid，如果rid很多，則此次路徑計算會占用較長cpu時間而無法去處理其它部分。現在對這部分邏輯進行優化，原則就是按rid粒度拆分路徑計算單元，挺高并發度，更好的利用協程效應。

3）節點按rid染色分層循環次數縮小至節點個數

        之前在圖遍歷時實時判斷rid歸屬分層并染色，遍歷次數和判斷次數是：節點個數*節點個數。現在是在創建的臨時變量里遍歷節點個數并按rid提前進行分層染色，標記為某種狀態，稱之為預分層染色，大大減少遍歷次數和判斷次數。

4）路徑計算協程個數及隊列大小調整

        隨著業務發展，面臨的場景也在不斷變化，之前的配置是按一個點到點計算一條路徑來優化配置的。而現在按rid分層計算則使路徑計算量暴增，點到點拆分出的計算任務按rid倍數增長，需要對其并發處理個數喝隊列緩存大小進行調整。

5）json字段優化

        在兩兩互探節點較多時，預處理模塊處理性能較之前下降明顯。如500*500節點場景下，舊版本1.15.0預處理模塊耗時是80毫秒，而新版本1.16.0不開啟rid計算并且每個節點攜帶40個rid時耗時變成940秒，下降11倍，有點觸目驚心。后分析發現，耗時基本在json.Unmarshal，預處理以往觀察也確實在這塊耗時較大，這說明沒有引入新的函數導致了預處理模塊性能下降。對此，仔細查看json.Unmarshal性能火焰圖后發現其中在數組創建上消耗很大，聯想到最近新增的rid字段并使用數組類型接收，有可能是這塊導致。隨后把rid字段去除上報1.16.0版本，預處理模塊處理耗時瞬間降低到110毫秒，反向證明rid數組是罪魁禍首。

        經過反復思考驗證后，把rid字段改為字符串類型性能可到較大提升，預處理模塊耗時下降到240毫秒，在多出rid字段處理情況下，性能損耗基本能接受，故新增一個rids字段為字符串類型，刪除rid為組數類型字段。

6）路徑匯聚優化為兩重匯聚

        之前的匯聚是一個協程進行按頻道名進行路徑匯聚，現在按rid拆分計算任務暴增后處理性能跟不上，導致匯聚隊列積壓影響路徑計算速率，計劃對這部分進行多次匯聚優化。增加一層并發匯聚，并發數可配置，進行粗粒度匯聚后降低待匯聚條數，然后再定義一個單協程二層匯聚進行最終匯聚，主動匯聚或者被動匯聚在二層匯聚里判斷實現。