問題：對於超大的 string V8不能支持 問題背景 在 Nodejs 計算服務中，對端上上報的記憶體信息二進位數據進行預處理+緩存時，遇到了一個奇怪的報錯：RangeError: Invalid string length 。根據該報錯信息，查找得知是字元串長度超過了 node.js 的限制，即 ...
問題：對於超大的 string V8不能支持
問題背景
在 Nodejs 計算服務中，對端上上報的記憶體信息二進位數據進行預處理+緩存時，遇到了一個奇怪的報錯：RangeError: Invalid string length 。根據該報錯信息，查找得知是字元串長度超過了 node.js 的限制，即 2^29-1 (約 5 億+)個字元。整體流程如圖所示。
關於 node.js string 的長度上限，主要和 V8 引擎「壓縮指針」技術有關。按個人理解，其通過壓縮指向變數的地址(64 位)中固定的 32 位的方式，從而減少引擎的記憶體占用。
代碼細節
由於需要快速訪問某地址，因此緩存的數據結構必須是個對象，即 INodeGraph。具體結構如下：
type IAddr = string;
// 記憶體圖譜
declare interface INodeGraph {
[addr: IAddr]: IParsedNode;
}
// 記憶體節點信息
declare interface IParsedNode {
addr: IAddr;
// size, nodeType 等輔助信息
parentNodeAddr: IAddr[]; // addr
childNodeAddr: string[]; // addr
edgeMap: {
[addr: IAddr]: {
// 當前節點與父子節點之間的邊(關係)的信息
};
};
}
|
我們目的很明確，就是實現這樣一個 js 大對象的持久化存儲，並且能夠方便快速的轉回 js object。為解決此問題，首先想到的能否利用 protobuf 替代 JSON 實現持久化。可惜的是 protobuf 並不適用於動態 key 的場景，它適用於處理數組中存儲多個相似結構對象的數據結構。
隨後嘗試了減少對象中不必要的信息，即縮短對象的固定 key，例如用「pNode」取代冗長的「parentNodeAddr」。對於一個百萬個鍵值對的 object 而言，雖然犧牲了代碼的可讀性，但在實際的 case 中，能承載的鍵值對數量大約多了 20%。
事實上回過頭來看，更好的處理方式或許是用另外的 Map 存儲對象的 key。例如 ： 將 nodeGraph.parentNodeAddr 這個 key 最大程度縮短為 nodeGraph.p
聲明 const GraphKey = { parentNodeAddr: 'p' } 保存一個 key 的映射，需要訪問某屬性時，使用nodeGraph[GraphKey.parentNodeAddr]
更進一步
上述手段只是治標不治本，對於 key 更多的大對象並不能徹底解決問題。因此在不改變項目整體架構的前提下（如使用圖資料庫/改用 go 開發等），提出以下兩個最終方案：
方案 1：藉助 Node.js C++ Addons 的能力，繞開 js string 的限制，將相關序列化邏輯交給 C++ 處理，並直接將處理好的引用樹 js object 進行後續處理。
- 優勢：如果能實現，性能會獲得優先提升；擴展了 Node.js 的能力
- 劣勢：實現難度大；維護可能是個問題
方案 2：生成引用樹緩存時，拆分為多個較小的對象，分別進行序列化和存儲，使用時再合併為一個大對象。
- 優勢：無需 C++ 側開發，難度更小；維護方便
- 劣勢：合併對象需要額外的時間，這一步驟可能會讓未命中緩存時的首次請求更慢
你要覺得這篇文章比較好，記得點推薦！
