億級中轉場：30倍內存優化算法設計與實現

    一句簡介：內存最大可存100萬，有一天能存300萬，再有一天儲900萬，再一天可存1800萬，直到3000萬！

    需求背景

     隨着公司的快遞業務日益增加，特別是節假日或購物節，如五1、61八、雙十一的快遞單量瞬間暴增，中轉場需緩存大量數據等待分揀，在去年雙十一高峯期，有些場地的進港和出港數據僅保留2到3天的數據，但分別都已經高達到2000至4000萬之間，而場地有些服務器高達38G的內存都沒法支撐起數千萬數據內存的消耗，致使後臺服務直接開檔空掛，巴槍使用癱瘓！

     記憶去年雙十一隻要當天當收件量超過1800萬以上，基本都會出現內存溢出的狀況，運維只能重啓後臺應用，重啓後巴槍需等待30~40分鐘緩存數據加載，無奈卻在勝仗關鍵時刻出叉子，不但影響分揀效率，且在工做壓力較大狀況下，場地人員也出現較大情緒！

    業務痛點（傳統解決方式）

一、順豐接近擁有300箇中轉場，若需每臺服務器拆解更換內存條，費時費力；

二、因服務器內存插槽有限，沒空閒插槽時，只能以捨棄現有4G換成8G方式進行，形成資源浪費； 

三、若是有些中轉場服務器較早期，內存擴展支持已到極限，須要更換服務器，形成成本費用則更高；  

四、假設全部服務器均有無限內存插槽和擴展支持，但在千萬數據量起步，吞吃內存胃口會增長几倍，甚至更多，不久後又要擴展；  

    算法概述

一、對象類型的數據轉換字節類型的數據；

二、千萬級別的List集合縮小爲萬級別的List集合；

三、須要緩存的數據進行批量且快速壓縮處理；

四、更新緩存數據時，對壓縮數據斷點判斷與拼接；

五、請求緩存數據時，對數據定點標識與二叉樹快速查找； 

流程圖如【圖1-1】所示：

                                              

    模擬演視

一、2倍以上加載效率（數據量越大越明顯）：jdk1.6，最大內存256，90萬數據；

A、舊算法時間截圖

B、新算法時間截圖

 二、30倍內存優化（數據量越大越明顯）：jdk1.6，最大內存256；

 A、舊算法內存截圖，101萬時已經溢出

B、新算法內存截圖，3000萬正常  

 

    算法難點

一、數據段算法對殘缺數據、特殊數據、超長數據、一表多箇中轉場等容易丟數據狀況的拼接； 

二、針對數據量較大時，對各類類型（long型、char型、String型等）轉換字節算法的性能要求較高；

 

---

創新點

一、 以習慣擴展硬件內存方式對比，省時省力省錢，只要伴隨正常版本的發佈，便可達到下降內存的使用。 

二、在數據量較大時，不但內存節省，還提升的加載和提取的效率， 能使巴槍終端反應靈敏，同時負載更多巴槍；

三、在後續緩存結構程序，均可以使用本內存優化算法，有效達到無邊界效益反應，疊加節省更多的人力物力；

---

帶來的影響

一、主要對進港、出港等幾個數據量大的緩存進行算法優化就能達到2~6倍的內存使用效果，10.5版本已在進港驗證功能使用正常（現10.8版本）；

 

二、不管是互聯網發展或公司業務擴展，又或者搭載新應用，如人工智能程序等，中轉場內存必須是擴展的過程，假設一個16G的中轉場本來要花費600元（按中關村三星8G內存400元~800元取平均值）擴展8G內存，但使用優化算法後，能空出了8G以上的內存，便是雙倍節省，做280箇中轉場計算（中轉場還在增長），雙倍費用節省33.5萬元左右，固然之後的疊加效果能夠會更多；

 

三、部分中轉場的服務器已經出現沒法支持擴展更大的內存，面對內存不足時，只能更換服務器，這會是更大一筆費用，優化內存後實現資源再利用！