用Golang實現redis

緣起

最近公司的第一個PHP轉GO項目已經在生產環境穩定運行數周，又逢需求小年兒，得空分享下去年學GO過程中的練手項目Godis——用Golang實現的redis.

redis3.0版本，代碼簡明精鍊，再加上是Web後端程式員使用最多組件之一，熟悉redis原理並閱讀多源碼的開發人員人數頗多，這個系列小文便不再對redis細節做過多介紹。不過，有必要系統性說明的地方仍然會以較大篇幅嘗試解讀。

進入正題

基本流程

Godis第一版的目標是“最基本的kv緩衝”，feature list如下：

1. 用戶端/服務端互動
2. set/get 命令實現
3. AOF持久化實現

已經做到，再精簡就等於沒寫的境界。遵循實際工作中的編碼流程，先設計基本架構再填充實現的方式，Godis的架構圖一步到位、毫無點綴：

原理分析

1. 用戶端/服務端互動

用戶端與服務端通過建立網路連接，發送、處理、返回資料給對方，完成通訊。redis的單機應用中，一個服務端redis-server進程可以處理多個用戶端的請求。

用戶端需要一個資料結構來儲存資訊，接收命令，維持和服務端的串連，與服務端進行一對一的互動。
用戶端具體需要哪些資訊，暫且不表。

服務端為了響應多個用戶端的請求，對資料進行查詢、儲存、更新、刪除操作，也需要一個結構來儲存基本資料，包括資料本身、正在串連中的用戶端等。
用戶端和服務端通過這兩個基本資料結構，便可以在建立串連（可以簡化為socket demo）之後，儲存自身和對方的必要資訊，維持之後的互動。

從原理分析入手，使用所示的結構體，可以滿足儲存用戶端、服務端的資料存放區要求：

client並非是我們用來和redis-server互動的client，而是與redis-server建立串連後，服務端在伺服器建立的、用來儲存當前串連的結構。與redis-server建立串連的用戶端什麼樣，redis-server不關心，畢竟與之互動的都是協議而已。

由圖，client和server結構體均有Db欄位，不同的是，server.Db指向的是0號db（redis支援多db，可以自行查閱瞭解）；client.Db指向的是正在串連的db。如果有select切換操作，該指向也會隨之變化。

2. set/get 命令實現

set、get 命令是redis最常用的命令之一，也是最能反映緩衝發展曆史的操作。對最簡單命令代碼的閱讀，可以看到redis最核心的原理。
set命令將資料以k-v索引值對，儲存到資料庫，也就是redis-server佔用的記憶體中，並且任何串連到此redis伺服器的用戶端，都可以通過get命令查詢到。
上一小節提到，儲存伺服器相關的資訊需要一個結構體，這裡set命令儲存的資料，也存在這個結構體中。不過，儲存的是資料的指標。
所以，set/get的實現原理可以簡化為，在伺服器資料結構中儲存set命令的資料，get命令執行時，也從這個資料結構中尋找。
set、get命令在用戶端接收之後，經由協議轉換傳遞給服務端執行。服務端執行命令前先查詢是否支援該命令，以決定是否執行。所以server結構體還需要有個commands欄位，記錄支援的命令列表。

3. AOF持久化實現

set命令儲存的資料不能一直在記憶體中，萬一宕機或者硬體故障，資料豈不是煙消雲散？
這就需要持久化技術，這也是儲存領域的一大關鍵技術。AOF，是Append Only File的簡稱，代表的是“只存增量”的持久化方式。在Godis v0.0.1版本中，將以最簡單的方式實現AOF持久化，做到下次開機可以查到上次set的資料 :)
持久化不應該對所有命令一視同仁，減少沒必要的執行開銷。在server中增加dirty欄位，標記資料是否已經被汙染，再決定是否持久化。

資料結構關聯

經過如上說明，這裡還有一幅Godis v0.0.1版資料結構圖：

下集預告

1. 實現主要資料結構
2. 完成服務端/用戶端互動