這年頭，你看到的東西未必就是你認為的東西。一個mysql協(xié)議的后面，可能是tidb;一個linux機器后面，可能是一個精簡的docker;你覺得xjjdog是個女的，但可能ta自己也不太清楚;而當你大呼php萬歲的時候，可能是研發(fā)人員和你開個玩笑，重寫了后綴，而后端用的卻是java。
大家都知道redis速度快，但它的容量和內存容量有關，很容易達到瓶頸。有些互聯(lián)網公司，直接使用redis作為后端數據庫(在下佩服)。當業(yè)務量暴增，就面臨一個redis容量和價格的權衡問題。改業(yè)務代碼是來不及了，只好用一些持久化存儲 ，來模擬redis的一些數據結構。
redis支持近十種數據類型，最常用的有5種。string、hash、zset、set、list等。本文將針對幾種常見的數據結構，探討一下常用操作的模擬實現。
其實，我們所需要開發(fā)的，就是一個redis代理proxy。redis的客戶端，連接上我們的代理之后，會進行協(xié)議解析。解析出來的命令，將會被模擬，然后根據配置的路由，定位到相應的mysql中。
也就是你所使用的redis，其實使用mysql來存儲數據的。沒有rdb，也沒有aof。
Redis是文本協(xié)議
redis是文本協(xié)議，協(xié)議名稱叫做RESP。RESP 是 Redis 序列化協(xié)議的簡寫。它是一種直觀的文本協(xié)議，優(yōu)勢在于實現異常簡單，解析性能極好。
如圖，Redis 協(xié)議將傳輸的結構數據，可以總結為 5 種最小單元類型。每個單元結束時，統(tǒng)一加上回車換行符號/r/n 。
下面是幾個規(guī)則：
比如，下面這個就是數組[9,9,6]的報文。
所以這個協(xié)議的解析和拼裝，是非常簡單的。拿netty來說，就有codec-redis 模塊供我們使用。
實現：數據結構設計
在數據表的設計上，我們發(fā)現，kv和hash在效率上沒有什么差別，因為它能夠直接根據key定位到。
反倒是zset，由于有排序的功能，造成了很多操作的執(zhí)行效率都不盡人意。
另外，由于我們不同的數據結構，是使用不同的表進行存儲的。所以刪除操作，要在每張表上都執(zhí)行一遍。
kv設計
kv，即string，是redis里最基本的數據類型。一個key對應一個value，string類型的值最大能存儲512MB。
設計專用的數據庫表rstore_kv，其中，rkey是主鍵。
set操作
get操作
del操作
exists操作
ttl操作
hash設計
hash 是一個鍵值(key=>value)對集合。hash 特別適合用于存儲對象。
設計專用的數據庫表rstore_hash，其中，rkey和hkey是聯(lián)合主鍵。
hset操作
hget操作
hgetall操作
hdel操作
del操作
hlen,hexists操作
ttl操作
zset設計
Redis zset 和 set 一樣也是string類型元素的集合,且不允許重復的成員。不同的是每個元素都會關聯(lián)一個double類型的分數。redis正是通過分數來為集合中的成員進行從小到大的排序。它的底層結構是跳躍表，效率特別高，但是會占用大量內存。
設計專用的數據庫表rstore_zset，其中，rkey和member是聯(lián)合主鍵。
zadd操作
zscore操作
zrem操作
zcard,exists操作
zcount操作
zremrangebyscore操作
zrangebyscore操作
zrange操作
zrank操作
ttl操作
del操作
set設計
sadd操作
scard操作
sismember操作
smembers操作
srem操作
del操作
ttl操作
End
本篇文章僅僅模擬了常用數據結構的常用功能，有很多很多功能是不支持的，比較明顯的就是分布式鎖setnx等。所以這個proxy層的開發(fā)，要想做到ok，并不是那么簡單。
同時，我們以一種模擬的視角，來看一下redis的數據結構，在關系型數據庫中的表現形式。這樣，更能夠加深我們對redis的認識，明白它存在的價值。
【責任編輯：武曉燕 TEL：（010）68476606】