閱讀478 返回首頁    go 阿裏雲 go 技術社區[雲棲]

Redis開發運維實踐開發設計規範之內存考慮

4.4 內存考慮

  1. 隻要有可能的話，就盡量使用散列鍵而不是字符串鍵來儲存鍵值對數據，因為散列鍵管理方便、能夠避免鍵名衝突、並且還能夠節約內存。

    具體實例： 節約內存：Instagram的Redis實踐 blog.nosqlfan.com/html/3379.html

  2. 如果將redis作為cache進行頻繁讀寫和超時刪除等，此時應該避免設置較大的k-v，因為這樣會導致redis的 內存碎片增加，導致rss占用較大，最後被操作係統OOM killer幹掉。一個很具體的issue例子請見：https://github.com/antirez/redis/issues/2136

  3. 如果采用序列化考慮通用性，請采用json相關的庫進行處理，如果對內存大小和速度都很關注的，推薦使用messagepack進行序列化和反序列化

  4. 如果需要計數器，請將計數器的key通過天或者小時分割，比如下邊的設計:

    需要修改為：

    更好的一個設計是采用hash：

  5. 各種數據結構及其占用內存的benchmark測試

set個數 每個set的元素總數 內存占用 Key大小 Value大小
100 100 1.88M 7 36
100 1000 10.75M 7 36
100 10000 111.12M 7 36
1000 100 11.59M 8 36
1000 1000 100.35M 8 36
1000 10000 1.08G 8 36
10000 100 108.71M 9 36
10000 1000 996.23M 9 36
zset個數 每個zset的元素總數 內存占用 Key大小 Value大小
100 100 1.62M 8 49
100 1000 15.91M 8 49
100 10000 162.06M 8 49
1000 100 8.71M 9 49
1000 1000 151.87M 9 49
1000 10000 1.58G 9 49
10000 100 79.83M 10 49
10000 1000 1.48G 10 49
hash個數 每個hash的元素總數 內存占用 Key大小 Value大小
100 100 1.63M 8 49
100 1000 6.29M 8 49
100 10000 156.91M 8 49
1000 100 8.71M 9 49
1000 1000 55.59M 9 49
1000 10000 1.52G 9 49
10000 100 79.83M 10 49
10000 1000 548.58M 10 49
list個數 每個list的元素總數 內存占用 Key大小 Value大小
100 100 1.23M 8 36
100 1000 10.00M 8 36
100 10000 92.40M 8 36
1000 100 4.83M 9 36
1000 1000 92.52M 9 36
1000 10000 916.47M 9 36
10000 100 40.76M 10 36
10000 1000 917.69M 10 36
string個數 內存占用 Key大小 Value大小
100 846.79K 13 36
1000 966.29K 13 36
10000 2.16M 13 36
100000 130.88M 13 36

Redis開發運維實踐指南本文為《Redis開發運維實踐指南》內容，該書作者為黃鵬程，已授權雲棲社區轉載。

最後更新：2017-05-08 10:31:37

  上一篇：go Redis開發運維實踐開發設計規範之超時設置
  下一篇：go Redis開發運維實踐開發設計規範之數據異常處理