Redis只能做緩存？太out了！
本文轉(zhuǎn)載自微信公眾號(hào)「小姐姐味道」，作者小姐姐養(yǎng)的狗。轉(zhuǎn)載本文請(qǐng)聯(lián)系小姐姐味道公眾號(hào)。
大多數(shù)數(shù)據(jù)庫，由于經(jīng)常和磁盤打交道，在高并發(fā)場(chǎng)景下，響應(yīng)會(huì)非常的慢。為了解決這種速度差異，大多數(shù)系統(tǒng)都習(xí)慣性的加入一個(gè)緩存層，來加速數(shù)據(jù)的讀取。redis由于它優(yōu)秀的處理能力和豐富的數(shù)據(jù)結(jié)構(gòu)，已經(jīng)成為了事實(shí)上的分布式緩存標(biāo)準(zhǔn)。
但是，如果你以為redis只能做緩存的話，那就太小看它了。
redis豐富的數(shù)據(jù)結(jié)構(gòu)，使得它的業(yè)務(wù)使用場(chǎng)景非常廣泛，加上rdb的持久化特性，它甚至能夠被當(dāng)作落地的數(shù)據(jù)庫使用。在這種情況下，redis能夠撐起大多數(shù)互聯(lián)網(wǎng)公司，尤其是社交、游戲、直播類公司的半壁江山。
1. Redis能夠勝任存儲(chǔ)工作
redis提供了非常豐富的集群模式：主從、哨兵、cluster，滿足服務(wù)高可用的需求。同時(shí)，redis提供了兩種持久化方式：aof和rdb，常用的是rdb。
通過bgsave指令，主進(jìn)程會(huì)fork出新的進(jìn)程，回寫磁盤。bgsave相當(dāng)于做了一個(gè)快照，由于它并沒有WAL日志和checkpoint機(jī)制，是無法做到實(shí)時(shí)備份的。如果機(jī)器突然斷電，那就很容易丟失數(shù)據(jù)。
幸運(yùn)的是，redis是內(nèi)存型的數(shù)據(jù)庫，主叢同步的速度是非常快的。如果你的集群維護(hù)的好，內(nèi)存分配的合理，那么除非機(jī)房斷電，否則redis的SLA，會(huì)一直保持在非常高的水平。
聽起來不是絕對(duì)可靠啊，有丟失數(shù)據(jù)的可能!這在一般CRUD的業(yè)務(wù)中，是無法忍受的。但為什么redis能夠滿足大多數(shù)互聯(lián)網(wǎng)公司的需求?這也是由業(yè)務(wù)屬性所決定的。
在決定最大限度擁抱redis之前，你需要確認(rèn)你的業(yè)務(wù)是否有以下特點(diǎn)：
除了核心業(yè)務(wù)，是否大多數(shù)業(yè)務(wù)對(duì)于數(shù)據(jù)的可靠性要求較低，丟失一兩條數(shù)據(jù)是可以忍受的?
- 面對(duì)的是C端用戶，可根據(jù)用戶ID快速定位到一類數(shù)據(jù)，數(shù)據(jù)集合普遍較小?無大量范圍查詢需求?
- 是否能忍受內(nèi)存型數(shù)據(jù)的成本需求?
- 是否業(yè)務(wù)幾乎不需要事務(wù)操作?
很幸運(yùn)的是，這類業(yè)務(wù)需求特別的多。比如常見的社交，游戲、直播、運(yùn)營類業(yè)務(wù)，都是可以完全依賴Redis的。
2. Reids應(yīng)用場(chǎng)景
Redis具有松散的文檔結(jié)構(gòu)，豐富的數(shù)據(jù)類型，能夠適應(yīng)千變?nèi)f化的scheme變更需求，接下來我將介紹Redis除緩存外的大量的應(yīng)用場(chǎng)景。
2.1 基本用戶數(shù)據(jù)存儲(chǔ)
在傳統(tǒng)的數(shù)據(jù)庫設(shè)計(jì)中，用戶表是非常難以設(shè)計(jì)的，變更的時(shí)候會(huì)傷筋動(dòng)骨。使用Redis的hash結(jié)構(gòu)，可以實(shí)現(xiàn)松散的數(shù)據(jù)模型設(shè)計(jì)。某些不固定，驗(yàn)證型的功能屬性，可以以JSON接口直接存儲(chǔ)在hash的value中。使用hash結(jié)構(gòu)，可以采用HGET和HMGET等指令，只獲取自己所需要的數(shù)據(jù)，在使用上也是非常便捷的。
- >HSET user:199929 sex m
- >HSET user:199929 age 22
- >HGETALL user:199929
- 1) "sex"
- 2) "m"
- 3) "age"
- 4) "22"
這種非統(tǒng)計(jì)型的、讀多寫少的場(chǎng)景，是非常適合使用KV結(jié)構(gòu)進(jìn)行存儲(chǔ)的。Redis的hash結(jié)構(gòu)提供了非常豐富的指令，某個(gè)屬性也可以使用HINCRBY進(jìn)行遞增遞減，非常的方便。
2.2 實(shí)現(xiàn)計(jì)數(shù)器
上面稍微提了一下HINCRBY指令，而對(duì)于Redis的Key本身來說，也有INCRBY指令，實(shí)現(xiàn)某個(gè)值的遞增遞減。
比如以下場(chǎng)景：統(tǒng)計(jì)某個(gè)帖子的點(diǎn)贊數(shù);存放某個(gè)話題的關(guān)注數(shù);存放某個(gè)標(biāo)簽的粉絲數(shù);存儲(chǔ)一個(gè)大體的評(píng)論數(shù);某個(gè)帖子熱度;紅點(diǎn)消息數(shù);點(diǎn)贊、喜歡、收藏?cái)?shù)等。
- > INCRBY feed:e3kk38j4kl:like 1
- > INCRBY feed:e3kk38j4kl:like 1
- > GET feed:e3kk38j4kl:like
- "2"
像微博這樣容易出現(xiàn)熱點(diǎn)的業(yè)務(wù)，傳統(tǒng)的數(shù)據(jù)庫，肯定是撐不住的，就要借助于內(nèi)存數(shù)據(jù)庫。由于Redis的速度非?？?，就不用再采用傳統(tǒng)DB非常慢的count操作，所有這種遞增操作都是毫秒級(jí)別的，而且效果都是實(shí)時(shí)的。
2.3 排行榜
排行榜能提高參與者的積極性，所以這項(xiàng)業(yè)務(wù)非常常見，它本質(zhì)上是一個(gè)topn的問題。
Redis中有一個(gè)叫做zset的數(shù)據(jù)結(jié)構(gòu)，使用跳表實(shí)現(xiàn)的有序列表，可以很容易實(shí)現(xiàn)排行榜一類的問題。當(dāng)存入zset中的數(shù)據(jù)，達(dá)到千萬甚至是億的級(jí)別，依然能夠保持非常高的并發(fā)讀寫，且擁有非常棒的平均響應(yīng)時(shí)間(5ms以內(nèi))。
使用zadd 可以添加新的記錄，我們會(huì)使用排行相關(guān)的分?jǐn)?shù)，作為記錄的score值，然后使用zrevrange指令即可獲取實(shí)時(shí)的排行榜數(shù)據(jù)，而zrevrank則可以非常容易的獲取用戶的實(shí)時(shí)排名。
- >ZADD sorted:xjjdog:2021-07 55 dog0
- >ZADD sorted:xjjdog:2021-07 89 dog1
- >ZADD sorted:xjjdog:2021-07 32 dog2
- >ZCARD sorted:xjjdog:2021-07
- >3
- > ZREVRANGE sorted:xjjdog:2021-07 0 -10 WITHSCORES # top10排行榜
- 1) "dog1"
- 2) "89"
- 3) "dog0"
- 4) "55"
- 5) "dog2"
- 6) "32"
2.4 好友關(guān)系
set結(jié)構(gòu)，是一個(gè)沒有重復(fù)數(shù)據(jù)的集合，你可以將某個(gè)用戶的關(guān)注列表、粉絲列表、雙向關(guān)注列表、黑名單、點(diǎn)贊列表等，使用獨(dú)立的zset進(jìn)行存儲(chǔ)。
使用ZADD、ZRANK等，將用戶的黑名單使用ZADD添加，ZRANK使用返回的sorce值判斷是否存在黑名單中。使用sinter指令，可以獲取A和B的共同好友。
除了好友關(guān)系，有著明確黑名單、白名單業(yè)務(wù)場(chǎng)景的數(shù)據(jù)，都可以使用set結(jié)構(gòu)進(jìn)行存儲(chǔ)。這種業(yè)務(wù)場(chǎng)景還有很多，比如某個(gè)用戶上傳的通訊錄，計(jì)算通訊錄的好友關(guān)系等等。
在實(shí)際使用中，使用zset存儲(chǔ)這類關(guān)系的更多一些。zset同set一樣，都不允許有重復(fù)值，但zset多了一個(gè)score字段，我們可以存儲(chǔ)一個(gè)時(shí)間戳，用來標(biāo)明關(guān)系建立所發(fā)生的時(shí)間，有更明確的業(yè)務(wù)含義。
2.5 統(tǒng)計(jì)活躍用戶數(shù)
類似統(tǒng)計(jì)每天的活躍用戶、用戶簽到、用戶在線狀態(tài)，這種零散的需求，實(shí)在是太多了。如果為每一個(gè)用戶存儲(chǔ)一個(gè)bool變量，那占用的空間就太多了。這種情況下，我們可以使用bitmap結(jié)構(gòu)，來節(jié)省大量的存儲(chǔ)空間。
- >SETBIT online:2021-07-23 3876520333 1
- >SETBIT online:2021-07-24 3876520333 1
- >GETBIT online:2021-07-23 3876520333
- 1
- >BITOP AND active online:2021-07-23 online:2021-07-24
- >GETBIT active 3876520333
- 1
- >DEBUG OBJECT online:2021-07-23
- Value at:0x7fdfde438bf0 refcount:1 encoding:raw serializedlength:5506446 lru:16410558 lru_seconds_idle:5
- (0.96s)
注意，如果你的id很大，你需要先進(jìn)行一次預(yù)處理，否則它會(huì)占用非常多的內(nèi)存。
bitmap包含一串連續(xù)的2進(jìn)制數(shù)字，使用1bit來表示真假問題。在bitmap上，可以使用and、or、xor等位操作(bitop)。
2.6 分布式鎖
Redis的分布式鎖，是一種輕量級(jí)的解決方案。雖然它的可靠性比不上Zookeeper之類的系統(tǒng)，但Redis分布式鎖有著極高的吞吐量。
一個(gè)最簡陋的加鎖動(dòng)作，可以使用redis帶nx和px參數(shù)的set指令去完成。下面是一小段簡單的分布式樣例代碼。
- public String lock(String key, int timeOutSecond) {
- for (; ; ) {
- String stamp = String.valueOf(System.nanoTime());
- boolean exist = redisTemplate.opsForValue().setIfAbsent(key, stamp, timeOutSecond, TimeUnit.SECONDS);
- if (exist) {
- return stamp;
- }
- }
- }
- public void unlock(String key, String stamp) {
- redisTemplate.execute(script, Arrays.asList(key), stamp);
- }
刪除操作的lua為。
- local stamp = ARGV[1]
- local key = KEYS[1]
- local current = redis.call("GET",key)
- if stamp == current then
- redis.call("DEL",key)
- return "OK"
- end
redisson的RedLock，是使用最普遍的分布式鎖解決方案，有讀寫鎖的差別，并處理了多redis實(shí)例情況下的異常問題。
2.7 分布式限流
使用計(jì)數(shù)器去實(shí)現(xiàn)簡單的限流，在Redis中是非常方便的，只需要使用incr配合expire指令即可。
- incr key
- expire key 1
這種簡單的實(shí)現(xiàn)，通常來說不會(huì)有問題，但在流量比較大的情況下，在時(shí)間跨度上會(huì)有流量突然飆升的風(fēng)險(xiǎn)。根本原因，就是這種時(shí)間切分方式太固定了，沒有類似滑動(dòng)窗口這種平滑的過度方案。
同樣是redisson的RRateLimiter，實(shí)現(xiàn)了與guava中類似的分布式限流工具類，使用非常便捷。下面是一個(gè)簡短的例子：
- RRateLimiter limiter = redisson.getRateLimiter("xjjdogLimiter");
- // 只需要初始化一次
- // 每2秒鐘5個(gè)許可
- limiter.trySetRate(RateType.OVERALL, 5, 2, RateIntervalUnit.SECONDS);
- // 沒有可用的許可，將一直阻塞
- limiter.acquire(3);
2.8 消息隊(duì)列
redis可以實(shí)現(xiàn)簡單的隊(duì)列。在生產(chǎn)者端，使用LPUSH加入到某個(gè)列表中;在消費(fèi)端，不斷的使用RPOP指令取出這些數(shù)據(jù)，或者使用阻塞的BRPOP指令獲取數(shù)據(jù)，適合小規(guī)模的搶購需求。
Redis還有PUB/SUB模式，不過pubsub更適合做消息廣播之類的業(yè)務(wù)。
在Redis5.0中，增加了stream類型的數(shù)據(jù)結(jié)構(gòu)。它比較類似于Kafka，有主題和消費(fèi)組的概念，可以實(shí)現(xiàn)多播以及持久化，已經(jīng)能滿足大多數(shù)業(yè)務(wù)需求了。
2..9 LBS應(yīng)用
早早在Redis3.2版本，就推出了GEO功能。通過GEOADD指令追加lat、lng經(jīng)緯數(shù)據(jù)，可以實(shí)現(xiàn)坐標(biāo)之間的距離計(jì)算、包含關(guān)系計(jì)算、附近的人等功能。
關(guān)于GEO功能，最強(qiáng)大的開源方案是基于PostgreSQL的PostGIS，但對(duì)于一般規(guī)模的GEO服務(wù)，redis已經(jīng)足夠用了。
2.10 更多擴(kuò)展應(yīng)用場(chǎng)景
要看redis能干什么，就不得不提以下java的客戶端類庫redisson。redisson包含豐富的分布式數(shù)據(jù)結(jié)構(gòu)，全部是基于redis進(jìn)行設(shè)計(jì)的。
redisson提供了比如Set、 SetMultimap、 ScoredSortedSet、 SortedSet, Map、 ConcurrentMap、 List、 ListMultimap、 Queue、BlockingQueue等非常多的數(shù)據(jù)結(jié)構(gòu)，使得基于redis的編程更加的方便。在github上，可以看到有上百個(gè)這樣的數(shù)據(jù)結(jié)構(gòu)：https://github.com/redisson/redisson/tree/master/redisson/src/main/java/org/redisson/api。
對(duì)于某個(gè)語言來說，基本的數(shù)組、鏈表、集合等api，配合起來能夠完成大部分業(yè)務(wù)的開發(fā)。Redis也不例外，它擁有這些基本的api操作能力，同樣能夠組合成分布式的、線程安全的高并發(fā)應(yīng)用。
由于Redis是基于內(nèi)存的，所以它的速度非?？?，我們也會(huì)把它當(dāng)作一個(gè)中間數(shù)據(jù)的存儲(chǔ)地去使用。比如一些公用的配置，放到redis中進(jìn)行分享，它就充當(dāng)了一個(gè)配置中心的作用;比如把JWT的令牌存放到Redis中，就可以突破JWT的一些限制，做到安全登出。
3. 一站式Redis面臨的挑戰(zhàn)
redis的數(shù)據(jù)結(jié)構(gòu)豐富，一般不會(huì)在功能性上造成困擾。但隨著請(qǐng)求量的增加，SLA要求的提高，我們勢(shì)必會(huì)對(duì)Redis進(jìn)行一些改造和定制性開發(fā)。
3.1 高可用挑戰(zhàn)
redis提供了主從、哨兵、cluster等三種集群模式，其中cluster模式為目前大多數(shù)公司所采用的方式。
但是，redis的cluster模式，有不少的硬傷。redis cluster采用虛擬槽的概念，把所有的key映射到 0～16383個(gè)整數(shù)槽內(nèi)，屬于無中心化的架構(gòu)。但它的維護(hù)成本較高，slave也不能夠參與讀取操作。
它的主要問題，在于一些批量操作的限制。由于key被hash到多臺(tái)機(jī)器上，所以mget、hmset、sunion等操作就非常的不友好，經(jīng)常發(fā)生性能問題。
redis的主從模式是最簡單的模式，但無法做到自動(dòng)failover，通常在主從切換后，還需要修改業(yè)務(wù)代碼，這是不能忍受的。即使加上haproxy這樣的負(fù)載均衡組件，復(fù)雜性也是非常高的。
哨兵模式在主從數(shù)量比較多的時(shí)候，能夠顯著的體現(xiàn)它的價(jià)值。一個(gè)哨兵集群，能夠監(jiān)控成百上千個(gè)集群，但是哨兵集群本身的維護(hù)是比較困難的。幸運(yùn)的是，redis的文本協(xié)議非常簡單，在netty中，甚至直接提供了redis的codec。自研一套哨兵系統(tǒng)，加強(qiáng)它的功能，是可行的。
3.2 冷熱數(shù)據(jù)分離
redis的特點(diǎn)是，不管什么數(shù)據(jù)，都一股腦地搞到內(nèi)存里做計(jì)算，這對(duì)于有時(shí)間序列概念，有冷熱數(shù)據(jù)之分的業(yè)務(wù)，造成了非常大的成本考驗(yàn)。為什么大多數(shù)開發(fā)者喜歡把數(shù)據(jù)存放在MySQL中，而不是Redis中?除了事務(wù)性要求以外，很大原因是歷史數(shù)據(jù)的問題。
通常，這種冷熱數(shù)據(jù)的切換，是由中間件完成的。我們上面也談到了，Redis是一個(gè)文本協(xié)議，非常簡單。做一個(gè)中間件，或者做一個(gè)協(xié)議兼容的Redis模擬存儲(chǔ)，是比較容易的。
比如我們Redis中，只保留最近一年的活躍用戶。一個(gè)好幾年不活躍的用戶，突然間訪問了系統(tǒng)，這時(shí)候我們獲取數(shù)據(jù)的時(shí)候，就需要中間件進(jìn)行轉(zhuǎn)換，從容量更大，速度更慢的存儲(chǔ)中查找。
這個(gè)時(shí)候，Redis的作用，更像是一個(gè)熱庫，更像是一個(gè)傳統(tǒng)cache層做的事情，發(fā)生在業(yè)務(wù)已經(jīng)上規(guī)模的時(shí)候。但是注意，直到此時(shí)，我們的業(yè)務(wù)層代碼，一直都是操作的redis的api。它們使用這眾多的函數(shù)指令，并不關(guān)心數(shù)據(jù)到底是真正存儲(chǔ)在redis中，還是在ssdb中。
3.3 功能性需求
redis還能玩很多花樣。舉個(gè)例子，全文搜索。很多人都會(huì)首選es，但redis生態(tài)就提供了一個(gè)模塊：RediSearch，可以做查詢，可以做filter。
但我們通常還會(huì)有更多的需求，比如統(tǒng)計(jì)類、搜索類、運(yùn)營效果分析等。這類需求與大數(shù)據(jù)相關(guān)，即使是傳統(tǒng)的DB也不能勝任。這時(shí)候，我們當(dāng)然要把redis中的數(shù)據(jù)，導(dǎo)入到其他平臺(tái)進(jìn)行計(jì)算啦。
如果你選擇的是redis數(shù)據(jù)庫，那么dba打交道的，就是rdb，而不是binlog。有很多的rdb解析工具(比如redis-rdb-tools)，能夠定期把rdb解析成記錄，導(dǎo)入到hadoop等其他平臺(tái)。
此時(shí)，rdb成為所有團(tuán)隊(duì)的中樞，成為基本的數(shù)據(jù)交換格式。導(dǎo)入到其他db后的業(yè)務(wù)，該怎么玩怎么玩，完全不會(huì)因?yàn)闃I(yè)務(wù)系統(tǒng)選用了redis就無法運(yùn)轉(zhuǎn)。
4. 總結(jié)
大多數(shù)業(yè)務(wù)系統(tǒng)，跑在redis上，這是很多一直使用MySQL做業(yè)務(wù)系統(tǒng)的同學(xué)所不能想象的。看完了上面的介紹，相信你能夠?qū)edis能夠?qū)崿F(xiàn)的存儲(chǔ)功能有個(gè)大體的了解。打開你的社交app、游戲app、視頻app，看一下它們的功能，能夠涵蓋多少呢?
我這里要強(qiáng)調(diào)的是，某些數(shù)據(jù)，并不是一定要落地到RDBMS才算安全，它們并不是一個(gè)強(qiáng)需求。
那既然redis這么厲害，為什么還要有mysql、tidb這樣的存儲(chǔ)呢?關(guān)鍵還在于業(yè)務(wù)屬性上。
如果一個(gè)業(yè)務(wù)系統(tǒng)，每次交互的數(shù)據(jù)，都是一個(gè)非常大的結(jié)果集，并涉及到非常復(fù)雜的統(tǒng)計(jì)、過濾工作，那么RDBMS是必須的;但如果一個(gè)系統(tǒng)，能夠通過某個(gè)標(biāo)識(shí)，快速定位到一類數(shù)據(jù)，這一類數(shù)據(jù)在可以預(yù)見的未來，是有限的，那就非常適合Redis存儲(chǔ)。
一個(gè)電商系統(tǒng)，選用redis做存儲(chǔ)就是作死，但一個(gè)社交系統(tǒng)就快活的多。在合適的場(chǎng)景選用合適的工具，才是我們應(yīng)該做的。
但是一個(gè)系統(tǒng)，能否在產(chǎn)品驗(yàn)證期，就能快速的響應(yīng)變化，快速開發(fā)上線，才是成功的關(guān)鍵。這也是使用redis做數(shù)據(jù)庫，所能夠帶來的最大好處。千萬別被那概率極低的丟數(shù)據(jù)場(chǎng)景，給嚇怕了。比起產(chǎn)品成功，你的系統(tǒng)即使是牢如鋼鐵，也一文不值。
小姐姐味道 (xjjdog)，一個(gè)不允許程序員走彎路的公眾號(hào)。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。
