現代的開發語言除了C++以外，大部分都對內存管理做好了封裝，一般的開發者根本都接觸不到內存的底層操作。更何況現在各種優秀的開源組件應用越來越多，例如mysql、redis等，這些甚至都不需要大家動手開發，直接拿來用就好了。所以有些同學也會覺得作為應用層開發的同學沒有學習的必要去學習底層。但我想通過本文的實際案例告訴大家，哪怕不直接接觸內存底層操作，就只是用一些開源的工具，如果你能理解底層的工作原理，你也能夠用到極致。
用戶訪問歷史讀寫需求
假如現在有這樣一個業務需求，用戶每次刷新都需要獲得要消費的新數據，但是不能和之前訪問過的歷史重複。你可以把它和你經常在用的今日頭條之類的信息流app聯繫起來。每次都要看到新的新聞，但是你肯定不想看到過去已經看過的文章。 這樣在功能實現的時候，就必要保存用戶的訪問歷史。當用戶再來刷新的時候，首先得獲取用戶的歷史記錄，要保證推給用戶的數據和之前的不重複。當推薦完成的時候，也需要把這次新推薦過的數據id記錄到歷史裡。為了適當降低實現複雜度，我們可以規定每個用戶只要不和過去的一萬條記錄重複就可以了。這樣每個用戶最多隻需要保存一萬條歷史id，如果存滿了就把最早的歷史記錄擠掉。我們進一步具體化一下這個需求的幾個關鍵點：
- 每個數據id是一個int整數來表示
- 每個用戶要保存1萬條id
- 每次用戶刷新開始的時候需要將這1萬條歷史全部讀取出來過濾一遍
- 每次用戶刷新結束的時候需要將新訪問過的10條寫入一遍，如果超過1萬需將最早的記錄擠掉
可見，每次用戶訪問的時候，會涉及到一個1萬規模的數據集上的一次讀取和一次寫入操作。
好了，需求描述完了，我們怎麼樣進行我們的技術方案的設計呢？相信你也能想到很多實現方案，我們今天來對比兩個基於Redis下的存儲方案在性能方面的優劣。
方案一：用Redis的list來存儲
首先能想到的第一個辦法就是用Redis的List來保存。因為這個數據結構設計的太適合上面的場景了。List下的lrange命令可以實現一次性讀取用戶的所有數據id的需求。
<code>$redis->lrange('TEST_KEY', 0,9999);/<code>lpush命令可以實現新的數據id的寫入，ltrim可以保證將用戶的記錄數量不超過1萬條。
<code>$redis->lpush('TEST_KEY', 1,2,3,4,5,6,7,8,9,10);
$redis->ltrim('TEST_KEY', 0,9999);/<code>我們準備一個用戶，提前存好一萬條id。寫入的時候每次只寫入10條新的id，讀取的時候通過lrange一次全部讀取出來。進行一下性能耗時測試，結果如下。
<code>Write repeats:10000 time consume:0.65939211845398 each 6.5939211845398E-5
Rrite repeats:10000 time consume:42.383342027664 each 0.0042383342027664/<code>
方案二：用Redis的string來存儲
我能想到的另外一個技術方案就是直接用String來存。我們可以把1萬個int表示的數據id拼接成一個字符串，用一個特殊的字符把他們分割開。例如："100000_100001_10002"這種。 存儲的時候，拼接一下，然後把這個大字符串寫到Redis裡。讀取的時候，把大字符串整體讀取出來，然後再用字符切割成數組來使用。
由於用string存儲的時候，保存前多了一個拼接字符串的操作，讀取後多了一步將字符串分割成數組的操作。在測試string方案的時候，為了公平起見，我們把需要把這兩步的開銷也考慮進來。 核心代碼如下：
<code>$userItems = array(......);
//寫入
for($i=0; $i $redis->set('TEST_KEY', implode('_', $userItems));
}
//讀取
for($i=0; $i<10000; $i++){
$items = explode("_", $redis->get('TEST_KEY'));
}/<code>
耗時測試結果如下
<code>Write repeats:10000 time consume:6.4061808586121 each 0.00064061808586121
Read repeats:10000 time consume:4.9698271751404 each 0.00049698271751404/<code>
結論
我們再直觀對比下兩個技術方案的性能數據。
圖1 方案1和方案二的性能對比
基於list的方案裡，寫入速度非常快，只需要0.066ms，因為僅僅只需要寫入新添加的10條記錄就可以了，再加一次鏈表的截斷操作，但是讀取性能可就要慢很多了，超過了4ms。原因之一是因為讀取需要整體遍歷，但其實還有第二個原因。我們本案例中的數據量過大，所以Redis在內部實際上是用雙端鏈表來實現的。
圖2 Redis之雙端列表內存結構
通過上圖你可能看出來，鏈表是通過指針串起來的。大量的node之間極大可能是隨機地分佈在內存的各個位置上，這樣你遍歷整個鏈表的時候，實際上大概率會導致內存的隨機模式下工作。
基於string方案在寫入的時候耗時比list要高，因為每次都得需要將1萬條全部寫入一遍。但是讀取性能卻比list高了10倍，總體上耗時加起來大約只有方案一的1/4左右。為什麼？我們再來看下redis string數據結構的內存佈局
圖3 Redis之string內存結構
可見，如果用string來存儲的話，不管用戶的數據id有多少，訪問將全部都是順序IO。順序IO的好處有兩點：
- 1. 一內存的順序IO的耗時大約只是隨機IO的1/3-1/4左右，
- 2. 對於讀取來說，順序訪問將極大地提升CPU的L1、L2、L3的cache命中率
所以如果你深入了內存的工作原理，哪怕你不能直接去操作內存，即使只是用一些開源的軟件，你也能夠將它的性能發揮到極致~
閱讀更多 開發內功修煉 的文章
