直接上手！Redis在海量數(shù)據(jù)和高并發(fā)下的優(yōu)化實(shí)踐
Redis 對于從事互聯(lián)網(wǎng)技術(shù)工程師來說并不陌生，幾乎所有的大中型企業(yè)都在使用 Redis 作為緩存數(shù)據(jù)庫。
但是對于絕大多數(shù)企業(yè)來說只會用到它的最基礎(chǔ)的 KV 緩存功能，還有很多 Redis 的高級功能可能都未曾認(rèn)真實(shí)踐過。
來自掌閱的工程師錢文品將為大家?guī)恚骸禦edis 在海量數(shù)據(jù)和高并發(fā)下的優(yōu)化實(shí)踐》的主題分享。
他將圍繞 Redis 分享在平時的日常業(yè)務(wù)開發(fā)中遇到的 9 個經(jīng)典案例，希望通過此次分享可以幫助大家更好的將 Redis 的高級特性應(yīng)用到日常的業(yè)務(wù)開發(fā)中來。
掌閱電子書閱讀軟件 ireader 的總用戶量大概是 5 億左右，月活 5000 萬，日活近 2000 萬 。服務(wù)端有 1000 多個 Redis 實(shí)例，100+ 集群，每個實(shí)例的內(nèi)存控制在 20G 以下。
KV 緩存
第一個是最基礎(chǔ)，也是最常用的就是 KV 功能，我們可以用 Redis 來緩存用戶信息、會話信息、商品信息等等。
下面這段代碼就是通用的緩存讀取邏輯：
- def get_user(user_id):
- user = redis.get(user_id)
- if not user:
- user = db.get(user_id)
- redis.setex(user_id, ttl, user) // 設(shè)置緩存過期時間
- return user
- def save_user(user):
- redis.setex(user.id, ttl, user) // 設(shè)置緩存過期時間
- db.save_async(user) // 異步寫數(shù)據(jù)庫
這個過期時間非常重要，它通常會和用戶的單次會話長度成正比，保證用戶在單次會話內(nèi)盡量一直可以使用緩存里面的數(shù)據(jù)。
當(dāng)然如果貴公司財力雄厚，又極其注重性能體驗(yàn)，可以將時間設(shè)置的長點(diǎn)甚至干脆就不設(shè)置過期時間。當(dāng)數(shù)據(jù)量不斷增長時，就使用 Codis 或者 Redis-Cluster 集群來擴(kuò)容。
除此之外 Redis 還提供了緩存模式，Set 指令不必設(shè)置過期時間，它也可以將這些鍵值對按照一定的策略進(jìn)行淘汰。
打開緩存模式的指令是：config set maxmemory 20gb ，這樣當(dāng)內(nèi)存達(dá)到 20GB 時，Redis 就會開始執(zhí)行淘汰策略，給新來的鍵值對騰出空間。
這個策略 Redis 也是提供了很多種，總結(jié)起來這個策略分為兩塊：劃定淘汰范圍，選擇淘汰算法。
比如我們線上使用的策略是 Allkeys-lru。這個 Allkeys 表示對 Redis 內(nèi)部所有的 Key 都有可能被淘汰，不管它有沒有帶過期時間，而 Volatile 只淘汰帶過期時間的。
Redis 的淘汰功能就好比企業(yè)遇到經(jīng)濟(jì)寒冬時需要勒緊褲腰帶過冬進(jìn)行一輪殘酷的人才優(yōu)化。
它會選擇只優(yōu)化臨時工呢，還是所有人一律平等都可能被優(yōu)化。當(dāng)這個范圍圈定之后，會從中選出若干個名額，怎么選擇呢，這個就是淘汰算法。
最常用的就是 LRU 算法，它有一個弱點(diǎn)，那就是表面功夫做得好的人可以逃過優(yōu)化。
比如你乘機(jī)趕緊在老板面前好好表現(xiàn)一下，然后你就安全了。所以到了 Redis 4.0 里面引入了 LFU 算法，要對平時的成績也進(jìn)行考核，只做表面功夫就已經(jīng)不夠用了，還要看你平時勤不勤快。
最后還有一種極不常用的算法：隨機(jī)搖號算法。這個算法有可能會把 CEO 也給淘汰了，所以一般不會使用它。
分布式鎖
下面我們看第二個功能：分布式鎖，這個是除了 KV 緩存之外最為常用的另一個特色功能。
比如一個很能干的資深工程師，開發(fā)效率很快，代碼質(zhì)量也很高，是團(tuán)隊(duì)里的明星。所以諸多產(chǎn)品經(jīng)理都要來煩他，讓他給自己做需求。
如果同一時間來了一堆產(chǎn)品經(jīng)理都找他，他的思路呢就會陷入混亂，再優(yōu)秀的程序員，大腦的并發(fā)能力也好不到哪里去。
所以他就在自己的辦公室的門把上掛了一個請勿打擾的牌子，當(dāng)一個產(chǎn)品經(jīng)理來的時候先看看門把上有沒有這個牌子，如果沒有呢就可以進(jìn)來找工程師談需求，談之前要把牌子掛起來，談完了再把牌子摘了。
這樣其他產(chǎn)品經(jīng)理也要來煩他的時候，如果看見這個牌子掛在那里，就可以選擇睡覺等待或者是先去忙別的事。如是這位明星工程師從此獲得了安寧。
這個分布式鎖的使用方式非常簡單，就是使用 Set 指令的擴(kuò)展參數(shù)如下：
- # 加鎖
- set lock:$user_id owner_id nx ex=5
- # 釋放鎖
- if redis.call("get", KEYS[1]) == ARGV[1] then
- return redis.call("del", KEYS[1])
- else
- return 0
- end
- # 等價于
- del_if_equals lock:$user_id owner_id
一定要設(shè)置這個過期時間，因?yàn)橛龅教厥馇闆r，比如地震(進(jìn)程被 Kill -9，或者機(jī)器宕機(jī))，產(chǎn)品經(jīng)理可能會選擇從窗戶上跳下去，沒機(jī)會摘牌，導(dǎo)致了死鎖饑餓，讓這位優(yōu)秀的工程師成了一位大閑人，造成嚴(yán)重的資源浪費(fèi)。
同時還需要注意這個 owner_id，它代表鎖是誰加的，產(chǎn)品經(jīng)理的工號。以免你的鎖不小心被別人摘掉了。
釋放鎖時要匹配這個 owner_id，匹配成功了才能釋放鎖。這個 owner_id 通常是一個隨機(jī)數(shù)，存放在 ThreadLocal 變量里(棧變量)。
官方其實(shí)并不推薦這種方式，因?yàn)樗诩耗Ｊ较聲a(chǎn)生鎖丟失的問題，在主從發(fā)生切換的時候。
官方推薦的分布式鎖叫 RedLock，作者認(rèn)為這個算法較為安全，推薦我們使用。
不過掌閱這邊一直還使用上面最簡單的分布式鎖，為什么我們不去使用 RedLock 呢?因?yàn)樗倪\(yùn)維成本會高一些，需要 3 臺以上獨(dú)立的 Redis 實(shí)例，用起來要繁瑣一些。
另外 Redis 集群發(fā)生主從切換的概率也并不高，即使發(fā)生了主從切換出現(xiàn)鎖丟失的概率也很低，因?yàn)橹鲝那袚Q往往都有一個過程，這個過程的時間通常會超過鎖的過期時間，也就不會發(fā)生鎖的異常丟失。
還有就是分布式鎖遇到鎖沖突的機(jī)會也不多，這正如一個公司里明星程序員也比較有限一樣，總是遇到鎖排隊(duì)那說明結(jié)構(gòu)上需要優(yōu)化。
延時隊(duì)列
下面我們繼續(xù)看第三個功能，延時隊(duì)列。前面我們提到產(chǎn)品經(jīng)理在遇到「請勿打擾」的牌子時可以選擇多種策略：
- 干等待
- 睡覺
- 放棄不干了
- 歇一會再干
干等待：就是 Spinlock，這會燒 CPU，飆高 Redis 的 QPS。
睡覺：就是先 Sleep 一會再試，這會浪費(fèi)線程資源，還會增加響應(yīng)時長。
放棄不干了：就是告知前端用戶待會再試，現(xiàn)在系統(tǒng)壓力大有點(diǎn)忙，影響用戶體驗(yàn)。
最后一種就是現(xiàn)在要講的策略待會再來：這是在現(xiàn)實(shí)世界里最普遍的策略。
這種策略一般用在消息隊(duì)列的消費(fèi)中，這個時候遇到鎖沖突該怎么辦?不能拋棄不處理，也不適合立即重試(Spinlock)，這時就可以將消息扔進(jìn)延時隊(duì)列，過一會再處理。
有很多專業(yè)的消息中間件支持延時消息功能，比如 RabbitMQ 和 NSQ。Redis 也可以，我們可以使用 Zset 來實(shí)現(xiàn)這個延時隊(duì)列。
Zset 里面存儲的是 Value/Score 鍵值對，我們將 Value 存儲為序列化的任務(wù)消息，Score 存儲為下一次任務(wù)消息運(yùn)行的時間(Deadline)，然后輪詢 Zset 中 Score 值大于 Now 的任務(wù)消息進(jìn)行處理。
- # 生產(chǎn)延時消息
- zadd(queue-key, now_ts+5, task_json)
- # 消費(fèi)延時消息
- while True:
- task_json = zrevrangebyscore(queue-key, now_ts, 0, 0, 1)
- if task_json:
- grabbed_ok = zrem(queue-key, task_json)
- if grabbed_ok:
- process_task(task_json)
- else:
- sleep(1000) // 歇 1s
當(dāng)消費(fèi)者是多線程或者多進(jìn)程的時候，這里會存在競爭浪費(fèi)問題。當(dāng)前線程明明將 task_json 從 Zset 中輪詢出來了，但是通過 Zrem 來爭搶時卻搶不到手。
這時就可以使用 LUA 腳本來解決這個問題，將輪詢和爭搶操作原子化，這樣就可以避免競爭浪費(fèi)。
- local res = nil
- local tasks = redis.pcall("zrevrangebyscore", KEYS[1], ARGV[1], 0, "LIMIT", 0, 1)
- if #tasks > 0 then
- local ok = redis.pcall("zrem", KEYS[1], tasks[1])
- if ok > 0 then
- res = tasks[1]
- end
- end
- return res
為什么我要將分布式鎖和延時隊(duì)列一起講呢，因?yàn)楹茉绲臅r候線上出了一次故障。
故障發(fā)生時線上的某個 Redis 隊(duì)列長度爆表了，導(dǎo)致很多異步任務(wù)得不到執(zhí)行，業(yè)務(wù)數(shù)據(jù)出現(xiàn)了問題。
后來查清楚原因了，就是因?yàn)榉植际芥i沒有用好導(dǎo)致了死鎖，而且遇到加鎖失敗時就 Sleep 無限重試結(jié)果就導(dǎo)致了異步任務(wù)徹底進(jìn)入了睡眠狀態(tài)不能處理任務(wù)。
那這個分布式鎖當(dāng)時是怎么用的呢?用的就是 Setnx+Expire，結(jié)果在服務(wù)升級的時候停止進(jìn)程直接就導(dǎo)致了個別請求執(zhí)行了 Setnx，但是 Expire 沒有得到執(zhí)行，于是就帶來了個別用戶的死鎖。
但是后臺呢又有一個異步任務(wù)處理，也需要對用戶加鎖，加鎖失敗就會無限 Sleep 重試，那么一旦撞上了前面的死鎖用戶，這個異步線程就徹底熄火了。
因?yàn)檫@次事故我們才有了今天的正確的分布式鎖形式以及延時隊(duì)列的發(fā)明，還有就是優(yōu)雅停機(jī)，因?yàn)槿绻嬖趦?yōu)雅停機(jī)的邏輯，那么服務(wù)升級就不會導(dǎo)致請求只執(zhí)行了一半就被打斷了，除非是進(jìn)程被 Kill -9 或者是宕機(jī)。
定時任務(wù)
分布式定時任務(wù)有多種實(shí)現(xiàn)方式，最常見的一種是 Master-Workers 模型。
Master 負(fù)責(zé)管理時間，到點(diǎn)了就將任務(wù)消息扔到消息中間件里，然后 Worker 們負(fù)責(zé)監(jiān)聽這些消息隊(duì)列來消費(fèi)消息。
著名的 Python 定時任務(wù)框架 Celery 就是這么干的。但是 Celery 有一個問題，那就是 Master 是單點(diǎn)的，如果這個 Master 掛了，整個定時任務(wù)系統(tǒng)就停止工作了。
另一種實(shí)現(xiàn)方式是 Multi-Master 模型。這個模型什么意思呢，就類似于 Java 里面的 Quartz 框架，采用數(shù)據(jù)庫鎖來控制任務(wù)并發(fā)。
會有多個進(jìn)程，每個進(jìn)程都會管理時間，時間到了就使用數(shù)據(jù)庫鎖來爭搶任務(wù)執(zhí)行權(quán)，搶到的進(jìn)程就獲得了任務(wù)執(zhí)行的機(jī)會，然后就開始執(zhí)行任務(wù)，這樣就解決了 Master 的單點(diǎn)問題。
這種模型有一個缺點(diǎn)，那就是會造成競爭浪費(fèi)問題，不過通常大多數(shù)業(yè)務(wù)系統(tǒng)的定時任務(wù)并沒有那么多，所以這種競爭浪費(fèi)并不嚴(yán)重。
還有一個問題它依賴于分布式機(jī)器時間的一致性，如果多個機(jī)器上時間不一致就會造成任務(wù)被多次執(zhí)行，這可以通過增加數(shù)據(jù)庫鎖的時間來緩解。
現(xiàn)在有了 Redis 分布式鎖，那么我們就可以在 Redis 之上實(shí)現(xiàn)一個簡單的定時任務(wù)框架：
- # 注冊定時任務(wù)
- hset tasks name trigger_rule
- # 獲取定時任務(wù)列表
- hgetall tasks
- # 爭搶任務(wù)
- set lock:${name} true nx ex=5
- # 任務(wù)列表變更(滾動升級)
- # 輪詢版本號，有變化就重加載任務(wù)列表，重新調(diào)度時間有變化的任務(wù)
- set tasks_version $new_version
- get tasks_version
如果你覺得 Quartz 內(nèi)部的代碼復(fù)雜的讓人看不懂，分布式文檔又幾乎沒有，很難折騰，可以試試 Redis，使用它會讓你少掉點(diǎn)頭發(fā)。
- Life is Short，I use Redis
- https://github.com/pyloque/taskino
頻率控制
如果你做過社區(qū)就知道，不可避免總是會遇到垃圾內(nèi)容。一覺醒來你會發(fā)現(xiàn)首頁突然會被某些莫名其妙的廣告帖刷屏了。如果不采取適當(dāng)?shù)臋C(jī)制來控制就會導(dǎo)致用戶體驗(yàn)受到嚴(yán)重影響。
控制廣告垃圾貼的策略非常多，高級一點(diǎn)的通過 AI，最簡單的方式是通過關(guān)鍵詞掃描。
還有比較常用的一種方式就是頻率控制，限制單個用戶內(nèi)容生產(chǎn)速度，不同等級的用戶會有不同的頻率控制參數(shù)。
頻率控制就可以使用 Redis 來實(shí)現(xiàn)，我們將用戶的行為理解為一個時間序列，我們要保證在一定的時間內(nèi)限制單個用戶的時間序列的長度，超過了這個長度就禁止用戶的行為。
它可以是用 Redis 的 Zset 來實(shí)現(xiàn)：
圖中綠色的部分就是我們要保留的一個時間段的時間序列信息，灰色的段會被砍掉。統(tǒng)計綠色段中時間序列記錄的個數(shù)就知道是否超過了頻率的閾值。
- # 下面的代碼控制用戶的 ugc 行為為每小時最多 N 次
- hist_key = "ugc:${user_id}"
- with redis.pipeline() as pipe:
- # 記錄當(dāng)前的行為
- pipe.zadd(hist_key, ts, uuid)
- # 保留1小時內(nèi)的行為序列
- pipe.zremrangebyscore(hist_key, 0, now_ts - 3600)
- # 獲取這1小時內(nèi)的行為數(shù)量
- pipe.zcard(hist_key)
- # 設(shè)置過期時間，節(jié)約內(nèi)存
- pipe.expire(hist_key, 3600)
- # 批量執(zhí)行
- _, _, count, _ = pipe.exec()
- return count > N
服務(wù)發(fā)現(xiàn)
技術(shù)成熟度稍微高一點(diǎn)的企業(yè)都會有服務(wù)發(fā)現(xiàn)的基礎(chǔ)設(shè)施。通常我們都會選用 Zookeeper、Etcd、Consul 等分布式配置數(shù)據(jù)庫來作為服務(wù)列表的存儲。
它們有非常及時的通知機(jī)制來通知服務(wù)消費(fèi)者服務(wù)列表發(fā)生了變更。那我們該如何使用 Redis 來做服務(wù)發(fā)現(xiàn)呢?
這里我們要再次使用 Zset 數(shù)據(jù)結(jié)構(gòu)，我們使用 Zset 來保存單個服務(wù)列表。多個服務(wù)列表就使用多個 Zset 來存儲。
Zset 的 Value 和 Score 分別存儲服務(wù)的地址和心跳的時間。服務(wù)提供者需要使用心跳來匯報自己的存活，每隔幾秒調(diào)用一次 Zadd。
服務(wù)提供者停止服務(wù)時，使用 Zrem 來移除自己。
- zadd service_key heartbeat_ts addr
- zrem service_key addr
這樣還不夠，因?yàn)榉?wù)有可能是異常終止，根本沒機(jī)會執(zhí)行鉤子，所以需要使用一個額外的線程來清理服務(wù)列表中的過期項(xiàng)：
- zremrangebyscore service_key 0 now_ts - 30 # 30s 都沒來心跳
接下來還有一個重要的問題是如何通知消費(fèi)者服務(wù)列表發(fā)生了變更，這里我們同樣使用版本號輪詢機(jī)制。
當(dāng)服務(wù)列表變更時，遞增版本號。消費(fèi)者通過輪詢版本號的變化來重加載服務(wù)列表。
- if zadd() > 0 || zrem() > 0 || zremrangebyscore() > 0:
- incr service_version_key
但是還有一個問題，如果消費(fèi)者依賴了很多的服務(wù)列表，那么它就需要輪詢很多的版本號，這樣的 IO 效率會比較低下。
這時我們可以再增加一個全局版本號，當(dāng)任意的服務(wù)列表版本號發(fā)生變更時，遞增全局版本號。
這樣在正常情況下消費(fèi)者只需要輪詢?nèi)职姹咎柧涂梢粤?。?dāng)全局版本號發(fā)生變更時再挨個比對依賴的服務(wù)列表的子版本號，然后加載有變更的服務(wù)列表：https://github.com/pyloque/captain。
位圖
掌閱的簽到系統(tǒng)做的比較早，當(dāng)時用戶量還沒有上來，設(shè)計上比較簡單，就是將用戶的簽到狀態(tài)用 Redis 的 Hash 結(jié)構(gòu)來存儲，簽到一次就在 Hash 結(jié)構(gòu)里記錄一條。
簽到有三種狀態(tài)，未簽到、已簽到和補(bǔ)簽，分別是 0、1、2 三個整數(shù)值：
- hset sign:${user_id} 2019-01-01 1
- hset sign:${user_id} 2019-01-02 1
- hset sign:${user_id} 2019-01-03 2
- ...
這非常浪費(fèi)用戶空間，到后來簽到日活過千萬的時候，Redis 存儲問題開始凸顯，直接將內(nèi)存飚到了 30G+，我們線上實(shí)例通常過了 20G 就開始報警，30G 已經(jīng)屬于嚴(yán)重超標(biāo)了。
這時候我們就開始著手解決這個問題，去優(yōu)化存儲。我們選擇了使用位圖來記錄簽到信息，一個簽到狀態(tài)需要兩個位來記錄，一個月的存儲空間只需要 8 個字節(jié)。
這樣就可以使用一個很短的字符串來存儲用戶一個月的簽到記錄。優(yōu)化后的效果非常明顯，內(nèi)存直接降到了 10 個 G。
因?yàn)椴樵冋麄€月的簽到狀態(tài) API 調(diào)用的很頻繁，所以接口的通信量也跟著小了很多。
但是位圖也有一個缺點(diǎn)，它的底層是字符串，字符串是連續(xù)存儲空間，位圖會自動擴(kuò)展，比如一個很大的位圖 8M 個位，只有最后一個位是 1，其他位都是零，這也會占用 1M 的存儲空間，這樣的浪費(fèi)非常嚴(yán)重。
所以呢就有了咆哮位圖這個數(shù)據(jù)結(jié)構(gòu)，它對大位圖進(jìn)行了分段存儲，全位零的段可以不用存。
另外還對每個段設(shè)計了稀疏存儲結(jié)構(gòu)，如果這個段上置 1 的位不多，可以只存儲它們的偏移量整數(shù)。這樣位圖的存儲空間就得到了非常顯著的壓縮。
這個咆哮位圖在大數(shù)據(jù)精準(zhǔn)計數(shù)領(lǐng)域非常有價值，感興趣的同學(xué)可以了解一下：https://juejin.im/post/5cf5c817e51d454fbf5409b0
模糊計數(shù)
前面提到這個簽到系統(tǒng)，如果產(chǎn)品經(jīng)理需要知道這個簽到的日活月活怎么辦呢?通常我們會直接甩鍋，請找數(shù)據(jù)部門。
但是數(shù)據(jù)部門的數(shù)據(jù)往往不是很實(shí)時，經(jīng)常前一天的數(shù)據(jù)需要第二天才能跑出來，離線計算通常是定時的一天一次。那如何實(shí)現(xiàn)一個實(shí)時的活躍計數(shù)?
最簡單的方案就是在 Redis 里面維護(hù)一個 Set 集合，來一個用戶，就 Sadd 一下，最終集合的大小就是我們需要的 UV 數(shù)字。
但是這個空間浪費(fèi)很嚴(yán)重，僅僅為了一個數(shù)字要存儲這樣一個龐大的集合似乎非常不值當(dāng)。那該怎么辦?
這時你就可以使用 Redis 提供的 HyperLogLog 模糊計數(shù)功能，它是一種概率計數(shù)，有一定的誤差，誤差大約是 0.81%。
但是空間占用很小，其底層是一個位圖，它最多只會占用 12K 的存儲空間。而且在計數(shù)值比較小的時候，位圖使用稀疏存儲，空間占用就更小了。
- # 記錄用戶
- pfadd sign_uv_${day} user_id
- # 獲取記錄數(shù)量
- pfcount sign_uv_${day}
微信公眾號文章的閱讀數(shù)可以使用它，網(wǎng)頁的 UV 統(tǒng)計它都可以完成。但是如果產(chǎn)品經(jīng)理非常在乎數(shù)字的準(zhǔn)確性，比如某個統(tǒng)計需求和金錢直接掛鉤，那么你可以考慮一下前面提到的咆哮位圖。
它使用起來會復(fù)雜一些，需要提前將用戶 ID 進(jìn)行整數(shù)序列化。Redis 沒有原生提供咆哮位圖的功能，但是有一個開源的 Redis Module 可以拿來即用：https://github.com/aviggiano/redis-roaring。
布隆過濾器
最后我們要講一下布隆過濾器，如果一個系統(tǒng)即將會有大量的新用戶涌入時，它就會非常有價值，可以顯著降低緩存的穿透率，降低數(shù)據(jù)庫的壓力。
這個新用戶的涌入不一定是業(yè)務(wù)系統(tǒng)的大規(guī)模鋪開，也可能是因?yàn)閬碜酝獠康木彺娲┩腹簟?/p>
- def get_user_state0(user_id):
- state = cache.get(user_id)
- if not state:
- state = db.get(user_id) or {}
- cache.set(user_id, state)
- return state
- def save_user_state0(user_id, state):
- cache.set(user_id, state)
- db.set_async(user_id, state)
比如上面就是這個業(yè)務(wù)系統(tǒng)的用戶狀態(tài)查詢接口代碼，現(xiàn)在一個新用戶過來了，它會先去緩存里查詢有沒有這個用戶的狀態(tài)數(shù)據(jù)，因?yàn)槭切掠脩?，所以肯定緩存里沒有。
然后它就要去查數(shù)據(jù)庫，結(jié)果數(shù)據(jù)庫也沒有。如果這樣的新用戶大批量瞬間涌入，那么可以預(yù)見數(shù)據(jù)庫的壓力會比較大，會存在大量的空查詢。
我們非常希望 Redis 里面有這樣的一個 Set，它存放了所有用戶的 ID，這樣通過查詢這個 Set 集合就知道是不是新用戶來了。
當(dāng)用戶量非常龐大的時候，維護(hù)這樣的一個集合需要的存儲空間是很大的。
這時候就可以使用布隆過濾器，它相當(dāng)于一個 Set，但是呢又不同于 Set，它需要的存儲空間要小的多。
比如你存儲一個用戶 ID 需要 64 個字節(jié)，而布隆過濾器存儲一個用戶 ID 只需要 1 個字節(jié)多點(diǎn)。
但是呢它存的不是用戶 ID，而是用戶 ID 的指紋，所以會存在一定的小概率誤判，它是一個具備模糊過濾能力的容器。
當(dāng)它說用戶 ID 不在容器中時，那么就肯定不在。當(dāng)它說用戶 ID 在容器里時，99% 的概率下它是正確的，還有 1% 的概率它產(chǎn)生了誤判。
不過在這個案例中，這個誤判并不會產(chǎn)生問題，誤判的代價只是緩存穿透而已。
相當(dāng)于有 1% 的新用戶沒有得到布隆過濾器的保護(hù)直接穿透到數(shù)據(jù)庫查詢，而剩下的 99% 的新用戶都可以被布隆過濾器有效的擋住，避免了緩存穿透。
- def get_user_state(user_id):
- exists = bloomfilter.is_user_exists(user_id)
- if not exists:
- return {}
- return get_user_state0(user_id)
- def save_user_state(user_id, state):
- bloomfilter.set_user_exists(user_id)
- save_user_state0(user_id, state)
布隆過濾器的原理有一個很好的比喻，那就是在冬天一片白雪覆蓋的地面上，如果你從上面走過，就會留下你的腳印。
如果地面上有你的腳印，那么就可以大概率斷定你來過這個地方，但是也不一定，也許別人的鞋正好和你穿的一模一樣。
可是如果地面上沒有你的腳印，那么就可以 100% 斷定你沒來過這個地方。
作者：錢文品(老錢)
簡介：互聯(lián)網(wǎng)分布式高并發(fā)技術(shù)十年老兵，目前任掌閱服務(wù)端技術(shù)專家。熟練使用 Java、Python、Golang 等多種計算機(jī)語言，開發(fā)過游戲，制作過網(wǎng)站，寫過消息推送系統(tǒng)和 MySQL 中間件，實(shí)現(xiàn)過開源的 ORM 框架、Web 框架、RPC 框架等。
