最近不少朋友在折騰Python后端的時(shí)候都會(huì)碰到同一個(gè)需求把數(shù)據(jù)寫進(jìn)Redis再從Redis里讀出來用。Redis本質(zhì)上就是一張住在內(nèi)存里的超級(jí)大表讀寫速度能到毫秒級(jí)而Python連Redis最主流的方案就是redis-py這個(gè)庫。這篇文章我不想只貼幾個(gè)API了事而是打算把從環(huán)境準(zhǔn)備開始到連接方式、參數(shù)選型、五種數(shù)據(jù)類型怎么存、存的時(shí)候有什么坑再到線上常見的故障排查一次講透。不管你是剛把Python裝好的新手還是已經(jīng)寫過好幾個(gè)接口的進(jìn)階選手照著這篇文章把代碼跑一遍基本就能在自己的項(xiàng)目里獨(dú)立接Redis了。1. 環(huán)境準(zhǔn)備先把Redis和Python的底座打好1.1 Redis服務(wù)端安裝與啟動(dòng)先明確一件事Redis是一個(gè)獨(dú)立的服務(wù)端程序Python只是它的客戶端。你在Python里寫import redis不代表Redis就跑起來了。所以第一步永遠(yuǎn)是先把Redis服務(wù)端裝好。在Linux上最省事直接用包管理器# Ubuntu / Debian sudo apt update sudo apt install redis-server # CentOS / RHEL sudo yum install redismacOS用戶如果裝了Homebrew一行就搞定brew install redis裝完之后啟動(dòng)也不同平臺(tái)有別# Linux多數(shù)發(fā)行版安裝后就自動(dòng)注冊(cè)成服務(wù) sudo systemctl start redis sudo systemctl enable redis # macOS 用 brew services 管理 brew services start redisWindows這邊要單獨(dú)說。Redis官方早就不提供Windows原生版本了我試過網(wǎng)上那些第三方編譯版版本舊、還時(shí)不時(shí)出點(diǎn)詭異問題?，F(xiàn)在最靠譜的兩條路一條是裝WSL2后在Linux子系統(tǒng)里裝另一條是直接用Docker跑docker run -d --name redis -p 6379:6379 redis:7啟動(dòng)之后無論如何先驗(yàn)證一下服務(wù)端是否真的活著。Redis自帶一個(gè)極簡的測試命令redis-cli ping如果返回PONG說明服務(wù)端已經(jīng)正常待命這時(shí)候再進(jìn)入Python環(huán)節(jié)才有意義。1.2 Python側(cè)安裝redis-pyPython連接Redis的庫有很多redis-py是維護(hù)最活躍、文檔最全、社區(qū)用戶最多的一個(gè)也是事實(shí)上的標(biāo)準(zhǔn)。安裝沒有任何懸念pip install redis裝完確認(rèn)一下版本不同大版本的API風(fēng)格差異挺多的python -c import redis; print(redis.__version__)我這篇文章里用的示例代碼基于redis-py 4.x或5.x如果你裝的是更老的2.x、3.x建議直接升到新版。老版本的連接方式也能跑但很多參數(shù)名、默認(rèn)行為都不一樣照著新教程寫容易踩踩版本差異的坑。順帶說一句在虛擬環(huán)境里安裝是最佳實(shí)踐別圖省事直接往全局環(huán)境里塞。用python -m venv venv建一個(gè)隔離環(huán)境再激活后安裝能少掉未來依賴沖突的一堆麻煩。2. 連接Redis的核心方式與參數(shù)拆解2.1 從最基礎(chǔ)的連接說起redis-py最基礎(chǔ)的用法是直接創(chuàng)建一個(gè)Redis實(shí)例import redis r redis.Redis(host127.0.0.1, port6379, db0) r.set(hello, world) print(r.get(hello)) # bworld這段代碼的含義是告訴客戶端去連接127.0.0.1這臺(tái)機(jī)器上的6379端口選第0號(hào)邏輯數(shù)據(jù)庫然后執(zhí)行一次寫入、一次讀取。這里有個(gè)新手最容易犯迷糊的點(diǎn)r.get(hello)返回的是bworld而不是world。原因在于redis-py默認(rèn)把返回值當(dāng)成字節(jié)串來處理因?yàn)樗恢滥愕降状娴氖俏谋具€是二進(jìn)制數(shù)據(jù)。想讓它自動(dòng)解碼成字符串需要在創(chuàng)建客戶端時(shí)傳入decode_responsesTruer redis.Redis(host127.0.0.1, port6379, db0, decode_responsesTrue) print(r.get(hello)) # world這個(gè)參數(shù)是新手遇到的第一座山后面排查章節(jié)我還會(huì)專門展開講。2.2 連接對(duì)象與連接池的區(qū)別直接創(chuàng)建redis.Redis()對(duì)象做少量操作沒問題但在高并發(fā)項(xiàng)目里每次操作都新建連接、用完再斷資源開銷是非常大的。Redis是基于TCP的握手、認(rèn)證都有成本每秒幾千次寫入的場景下頻繁建連會(huì)直接拖垮性能。正確的做法是用連接池。連接池的原理和數(shù)據(jù)庫連接池一樣預(yù)先創(chuàng)建一批連接放在池子里用的時(shí)候借一條用完歸還循環(huán)復(fù)用pool redis.ConnectionPool( host127.0.0.1, port6379, db0, decode_responsesTrue, max_connections50, ) r redis.Redis(connection_poolpool)創(chuàng)建redis.Redis時(shí)如果傳了connection_pool它就不會(huì)自己單獨(dú)建連而是從池子里借。max_connections控制池里最多能有多少條連接。默認(rèn)值是2的31次方減1相當(dāng)于不限但生產(chǎn)環(huán)境我強(qiáng)烈建議手動(dòng)指定一個(gè)合理上限否則突發(fā)流量會(huì)把Redis的連接數(shù)拉到峰值反過來影響服務(wù)端性能。還有一個(gè)隱藏細(xì)節(jié)同一個(gè)連接池可以被多個(gè)Redis實(shí)例共享也就是說兩個(gè)業(yè)務(wù)模塊可以共用一個(gè)池子只要它們?cè)L問的是同一個(gè)Redis實(shí)例、同一個(gè)db。2.3 連接參數(shù)逐個(gè)說清楚很多人在配置連接時(shí)只看得懂host和port其他參數(shù)一律不填。這些參數(shù)平時(shí)確實(shí)用不上但遇到問題、做調(diào)優(yōu)的時(shí)候它們就是救命稻草。host和portRedis服務(wù)端地址和端口默認(rèn)是localhost和6379。填127.0.0.1和填localhost在大部分機(jī)器上等效但如果本機(jī)做了域名解析的特殊配置比如IPv6優(yōu)先兩者就可能出現(xiàn)行為差異建議直接寫IP。password服務(wù)端設(shè)置了密碼時(shí)必填沒設(shè)就不填。密碼對(duì)應(yīng)Redis配置里的requirepass。dbRedis默認(rèn)有16個(gè)邏輯數(shù)據(jù)庫編號(hào)0到15db0指默認(rèn)庫。邏輯庫的作用是數(shù)據(jù)隔離比如同一個(gè)Redis實(shí)例里緩存數(shù)據(jù)放db0、業(yè)務(wù)數(shù)據(jù)放db1。不過話說回來邏輯庫只是簡單的編號(hào)隔離并沒有真正的權(quán)限控制如果項(xiàng)目規(guī)模上來了更推薦用不同的Redis實(shí)例來做真正的隔離。socket_timeout單次讀寫操作的超時(shí)時(shí)間單位秒。默認(rèn)是不超時(shí)意味著如果Redis端卡住了你的程序就可能一直等下去。我一般建議設(shè)置成3到5秒避免一個(gè)慢查詢把整個(gè)服務(wù)線程拖死。socket_connect_timeout建立TCP連接的超時(shí)默認(rèn)一樣不限制。設(shè)置成2到3秒比較合理Redis掛掉的時(shí)候快速失敗而不是卡在connect上讓請(qǐng)求堆積。socket_keepalive是否開啟TCP保活默認(rèn)不開。如果客戶端和Redis之間有NAT設(shè)備或防火墻空閑連接可能被靜默掐斷開啟?；畈⑴浜舷旅娴慕】禉z查能減少這種幽靈斷連。health_check_interval連接空閑多久后在下次使用前進(jìn)行一次PING檢查直到失敗就重連。默認(rèn)是0表示不啟用。生產(chǎn)環(huán)境我建議設(shè)30秒能有效規(guī)避連接被中間網(wǎng)絡(luò)設(shè)備悄悄關(guān)閉導(dǎo)致的報(bào)錯(cuò)。retry_on_timeout超時(shí)后是否自動(dòng)重試。默認(rèn)False。打開之后副作用是可能造成命令重復(fù)執(zhí)行所以只建議在冪等操作場景開啟。這些參數(shù)看起來不起眼但線上很多連接莫名其妙斷了、程序假死的案子最后都能追溯到某幾個(gè)參數(shù)沒配置好。3. Redis五大數(shù)據(jù)類型的存儲(chǔ)實(shí)操3.1 String類型萬能的緩存和王牌計(jì)數(shù)器String是Redis里最基礎(chǔ)、最常用的類型。一個(gè)key對(duì)應(yīng)一個(gè)valuevalue本身是字符串但你可以通過命令把它當(dāng)整數(shù)來做自增運(yùn)算。最常見的場景就是緩存一段文本比如把接口返回的JSON存進(jìn)去設(shè)置過期時(shí)間import json user_info {name: 張三, age: 30} r.setex(user:1001, 3600, json.dumps(user_info))setex的三個(gè)參數(shù)分別是key、過期秒數(shù)、value。這樣寫入后1小時(shí)內(nèi)這個(gè)key自動(dòng)失效非常適合緩存場景。取出來記得要json.loads還原data r.get(user:1001) if data: user_info json.loads(data)另一個(gè)經(jīng)典用法是計(jì)數(shù)器比如統(tǒng)計(jì)接口調(diào)用次數(shù)、限流用的滑動(dòng)窗口計(jì)數(shù)。Redis的incr是原子操作在高并發(fā)下不會(huì)丟數(shù)據(jù)r.incr(request:count:20250101) count r.get(request:count:20250101)我之前處理過一個(gè)活動(dòng)抽獎(jiǎng)的限流需求就是靠incr加expire實(shí)現(xiàn)的。每次用戶抽獎(jiǎng)先incr一個(gè)按用戶ID和時(shí)間片組成的key第一次自增后順手設(shè)置過期時(shí)間值超過閾值就拒絕。這套邏輯在單機(jī)Redis下性能非常穩(wěn)定。3.2 Hash類型存對(duì)象數(shù)據(jù)的天然選擇Hash可以理解成一個(gè)key下面掛了一個(gè)小型的字段-值映射表。你存一個(gè)用戶的多個(gè)屬性時(shí)用Hash比用String存一整段JSON要靈活得多因?yàn)槟憧梢灾桓缕渲幸粋€(gè)字段不需要取出來反序列化整個(gè)對(duì)象再寫回。r.hset(user:1001, mapping{ name: 張三, age: 30, city: 北京, }) r.hget(user:1001, name) # 張三 r.hgetall(user:1001) # {name: 張三, age: 30, city: 北京}注意一點(diǎn)hgetall會(huì)一次性把所有字段取回來字段很多且只需要其中一兩個(gè)時(shí)用hmget指定字段更省流量r.hmget(user:1001, name, city) # [張三, 北京]Hash在存儲(chǔ)對(duì)象屬性、購物車、配置項(xiàng)這類一物多屬性的數(shù)據(jù)時(shí)特別好用。我見過有人把用戶的積分、等級(jí)、最近登錄時(shí)間全塞進(jìn)一個(gè)Hash里更新其中一個(gè)字段時(shí)整個(gè)對(duì)象的數(shù)據(jù)一致性依然有保障代價(jià)也小。3.3 List、Set、ZSet隊(duì)列、去重和排行榜List類型是雙向鏈表特別適合做簡單的消息隊(duì)列。生產(chǎn)者從左邊塞消費(fèi)者從右邊取r.lpush(task:queue, job_1) r.lpush(task:queue, job_2) while True: job r.rpop(task:queue) if job is None: break print(f處理任務(wù): {job})這里有個(gè)講究用brpop替代rpop可以阻塞等待隊(duì)列為空時(shí)掛起而不是立刻返回None這樣就不用在輪詢里空轉(zhuǎn)浪費(fèi)CPU。Set類型是去重的無序集合適合做標(biāo)簽、關(guān)注關(guān)系、去重判斷r.sadd(user:1001:tags, python, backend, python) r.smembers(user:1001:tags) # {backend, python}上面連續(xù)sadd了兩次python第二次不會(huì)重復(fù)寫入這是Set天然的約束。ZSet是有序集合每個(gè)成員帶一個(gè)分?jǐn)?shù)Redis按分?jǐn)?shù)排序典型用途就是排行榜r.zadd(leaderboard:2025, mapping{ player_1: 100, player_2: 80, player_3: 120, }) r.zrevrange(leaderboard:2025, 0, 2, withscoresTrue)zrevrange按分?jǐn)?shù)從高到低取前三名配合withscoresTrue順便拿到分?jǐn)?shù)。排行榜這種需求用關(guān)系數(shù)據(jù)庫查起來要order by加limit數(shù)據(jù)量大時(shí)還得考慮索引放到Redis里就是一條命令的事。3.4 過期時(shí)間的進(jìn)階玩法Redis的過期機(jī)制是懶過期加主動(dòng)過期結(jié)合。懶過期是讀的時(shí)候發(fā)現(xiàn)過期就刪主動(dòng)過期是后臺(tái)每100毫秒采樣一批過期key進(jìn)行清理。這意味著一個(gè)key到了過期時(shí)間并不會(huì)被立刻物理刪除你剛好在那之前讀了它就可能讀到本應(yīng)失效的數(shù)據(jù)——雖然概率很低但設(shè)計(jì)緩存時(shí)要留個(gè)心眼。給已經(jīng)寫好的key添加過期時(shí)間是常規(guī)操作r.expire(user:1001, 3600) ttl r.ttl(user:1001) # 剩余秒數(shù)-1表示永不過期-2表示key不存在對(duì)于批量緩存更新我習(xí)慣在寫入時(shí)就帶上過期時(shí)間而不是寫入后再用expire補(bǔ)少一次RTT不說邏輯上也更清晰。4. 完整實(shí)戰(zhàn)寫一個(gè)可復(fù)用的Redis存儲(chǔ)模塊4.1 從零封裝一個(gè)連接模塊把前面的知識(shí)點(diǎn)串起來生產(chǎn)環(huán)境里我習(xí)慣封裝成一個(gè)單獨(dú)的模塊業(yè)務(wù)方只負(fù)責(zé)傳key和value不關(guān)心連接池怎么創(chuàng)建、序列化怎么處理。下面給一個(gè)可直接抄作業(yè)的示例文件名叫redis_client.pyimport json import redis class RedisClient: def __init__(self, host: str 127.0.0.1, port: int 6379, password: str None, db: int 0, max_connections: int 50): self.pool redis.ConnectionPool( hosthost, portport, passwordpassword, dbdb, decode_responsesTrue, socket_timeout3, socket_connect_timeout3, socket_keepaliveTrue, health_check_interval30, max_connectionsmax_connections, ) self.client redis.Redis(connection_poolself.pool) def set_json(self, key: str, obj, expire: int None) - bool: value json.dumps(obj, ensure_asciiFalse) return self.client.set(key, value, exexpire) def get_json(self, key: str): value self.client.get(key) if value is None: return None return json.loads(value) def delete(self, key: str): self.client.delete(key) def get_client(self) - redis.Redis: return self.client這個(gè)工具的寫法有幾個(gè)關(guān)鍵設(shè)計(jì)說給各位參考decode_responsesTrue放在連接池構(gòu)造里那么所有從連接池借出來的連接都默認(rèn)字符串解碼省去到處轉(zhuǎn)碼的麻煩。socket_timeout3保證單個(gè)命令最多等3秒Redis無響應(yīng)時(shí)快速失敗不會(huì)把請(qǐng)求線程掛死。set_json和get_json專門處理JSON序列化內(nèi)部自動(dòng)把Python對(duì)象轉(zhuǎn)成JSON字符串、再轉(zhuǎn)回來。業(yè)務(wù)層調(diào)用時(shí)感知不到序列化細(xì)節(jié)。使用方式就簡單了from redis_client import RedisClient cache RedisClient(host127.0.0.1, db1) cache.set_json(user:1001, {name: 張三, age: 30}, expire3600) user cache.get_json(user:1001)4.2 序列化選型JSON是默認(rèn)答案別輕易用pickle前面示例用了json.dumps這是最穩(wěn)妥的選擇。原因是JSON可讀性強(qiáng)、跨語言通用前端或者其他語言的服務(wù)也能毫無障礙地讀取。需要注意中文會(huì)被轉(zhuǎn)成unicode轉(zhuǎn)義序列所以我在set_json里加了ensure_asciiFalse存進(jìn)去的字符串直接顯示中文排查問題的時(shí)候一目了然。有同學(xué)圖方便想用pickle直接把Python對(duì)象二進(jìn)制序列化存進(jìn)去我強(qiáng)烈不建議。兩個(gè)理由一是pickle格式只有Python能讀其他語言完全沒法解析二是pickle在反序列化時(shí)存在任意代碼執(zhí)行風(fēng)險(xiǎn)如果數(shù)據(jù)源不可信等于把后門開給攻擊者。除非你明確知道自己存的對(duì)象沒法簡單轉(zhuǎn)JSON比如含有datetime、Decimal才考慮用json.dumps加一個(gè)自定義default函數(shù)來處理特殊類型。日常項(xiàng)目里90%的場景JSON都?jí)蛴昧恕?.3 緩存過期時(shí)間的策略設(shè)計(jì)expire設(shè)置多少合適看起來是拍腦袋的事實(shí)際有講究。緩存熱點(diǎn)數(shù)據(jù)過期時(shí)間建議加上一個(gè)隨機(jī)抖動(dòng)。比如基準(zhǔn)3600秒再隨機(jī)加0到300秒避免大量key在同一秒集體過期造成緩存雪崩。緩存防穿透如果key對(duì)應(yīng)的數(shù)據(jù)在數(shù)據(jù)庫里根本不存在可以考慮把這個(gè)空結(jié)果也緩存一小段時(shí)間比如60秒避免惡意請(qǐng)求反復(fù)穿透到數(shù)據(jù)庫。更新策略更新數(shù)據(jù)庫后先更新緩存還是先刪緩存業(yè)界討論很多。我的習(xí)慣是先更新數(shù)據(jù)庫再刪除緩存下次讀取時(shí)緩存缺失再回源數(shù)據(jù)庫重建。這個(gè)方案在絕大多數(shù)場景下簡單可靠比先寫緩存再更新數(shù)據(jù)庫的臟數(shù)據(jù)概率要低得多。5. 常見故障排查與避坑實(shí)錄5.1 連接被拒絕不是代碼的問題是環(huán)境的問題我最常收到的問題就是為什么我代碼連不上Redis報(bào)錯(cuò)ConnectionError: Error while reading from socket。第一步永遠(yuǎn)是先確認(rèn)Redis服務(wù)端真的在跑redis-cli ping如果返回Could not connect to Redis at 127.0.0.1:6379: Connection refused那就是服務(wù)端壓根沒啟動(dòng)或者啟動(dòng)后崩了。去服務(wù)端日志看一眼常見原因是配置了bind 127.0.0.1但你的代碼從另一臺(tái)機(jī)器連過來自然被拒絕。這時(shí)候修改Redis配置把bind改成需要的IP或0.0.0.0同時(shí)注意防火墻和網(wǎng)絡(luò)安全然后重啟服務(wù)。還有一類情況是Redis啟動(dòng)了但處于保護(hù)模式protected mode。默認(rèn)配置下Redis只能被本機(jī)訪問外部IP連接會(huì)被明確拒絕。如果確實(shí)是內(nèi)網(wǎng)測試環(huán)境需要其他機(jī)器連需要修改配置或者顯式設(shè)置密碼后關(guān)閉保護(hù)模式。5.2 認(rèn)證失敗密碼不匹配不是因?yàn)閞edis-py有bug如果Redis配置了requirepass而連接代碼沒帶密碼或者帶錯(cuò)了會(huì)報(bào)AuthenticationError。這個(gè)排查思路很直接# 命令行帶密碼驗(yàn)證 redis-cli -a your_password ping命令行能通說明密碼沒問題那就是代碼里的password參數(shù)寫錯(cuò)了。命令行也不通直接去Redis配置文件里找requirepass那一行確認(rèn)密碼。需要注意的是密碼里如果帶有特殊字符命令行里可能要加引號(hào)。代碼里則老實(shí)寫成字符串注意別把空格、換行這些不可見字符帶進(jìn)去。5.3 存進(jìn)去是字符串取出來是bytes到底怎么回事這是新手最高頻的困惑也是decode_responses這個(gè)參數(shù)的知識(shí)盲區(qū)。redis-py默認(rèn)把所有value當(dāng)成二進(jìn)制數(shù)據(jù)返回所以r.get(key)得到bvalue。如果連接配置了decode_responsesTrue它才會(huì)自動(dòng)轉(zhuǎn)成str。但有一個(gè)坑經(jīng)常被忽略decode_responses只影響連接層的自動(dòng)解碼它不會(huì)幫你把JSON字符串轉(zhuǎn)成Python對(duì)象。你存的是JSON字符串取回來decode后得到JSON字符串還得自己json.loads。所以在封裝工具類時(shí)get_json里不僅要依賴decode更要顯式處理反序列化。5.4 命令超時(shí)和連接池耗盡線上偶發(fā)redis.exceptions.TimeoutError或者ConnectionPoolError: Connection pool exhausted這兩類問題的根源完全不同但都和連接配置有關(guān)。超時(shí)命令執(zhí)行超過了socket_timeout的閾值。先看Redis的慢日志SLOWLOG GET能告訴你哪些命令耗時(shí)高。如果確實(shí)有大key導(dǎo)致的慢命令拆key是正路。如果Redis本身很快但網(wǎng)絡(luò)有抖動(dòng)適當(dāng)調(diào)大socket_timeout也能緩解。連接池耗盡池子里所有連接都被借出且未歸還。常見原因是業(yè)務(wù)代碼用pipeline或訂閱發(fā)布時(shí)忘了釋放或者某個(gè)線程被慢查詢卡在線程里遲遲不歸還連接。排查時(shí)可以用CLIENT LIST看當(dāng)前連接數(shù)再對(duì)照池子的max_connections基本能定位是哪個(gè)模塊把連接占滿了。我之前遇到過一例比較典型的有個(gè)定時(shí)任務(wù)每5分鐘跑一次全量數(shù)據(jù)同步每次開50個(gè)并發(fā)線程同時(shí)從池子里借連接正常沒問題。某天數(shù)據(jù)量翻倍單次同步耗時(shí)從1分鐘變成10分鐘池子里的50條連接全被占著不放其他業(yè)務(wù)立刻報(bào)連接池耗盡。后來把同步任務(wù)改成分批處理控制并發(fā)數(shù)問題再?zèng)]出現(xiàn)過。附一個(gè)排查速查表方便對(duì)照?qǐng)?bào)錯(cuò)現(xiàn)象可能原因建議動(dòng)作Connection refusedRedis未啟動(dòng)、端口錯(cuò)誤檢查redis-cli ping與服務(wù)端日志AuthenticationError密碼錯(cuò)誤或未傳password用redis-cli -a驗(yàn)證密碼TimeoutErrorRedis慢命令、網(wǎng)絡(luò)抖動(dòng)看SLOWLOG視情況調(diào)大socket_timeoutConnection pool exhausted連接未歸還、并發(fā)過高檢查業(yè)務(wù)代碼控制并發(fā)調(diào)大池子上限socket read timeout網(wǎng)絡(luò)不穩(wěn)定、連接被中間設(shè)備掐斷開啟socket_keepalive與health_check_intervalResponseError: WRONGTYPEkey類型與命令不匹配TYPE key查看類型刪除或改名重建5.5 存量key的類型沖突還有一種問題特別讓人抓狂明明代碼是對(duì)的一執(zhí)行就報(bào)WRONGTYPE Operation against a key holding the wrong kind of value。原因是同一個(gè)key之前被用別的類型寫過比如以前用set存過字符串后來你又拿它去hsetRedis不會(huì)自動(dòng)幫你轉(zhuǎn)換類型直接拒絕。遇到這種情況TYPE key查一下類型DEL key刪掉重建就行。存key的命名規(guī)范從源頭做好能避免絕大多數(shù)這類問題。6. 一些生產(chǎn)環(huán)境的實(shí)操心得最后分享幾個(gè)我在實(shí)際項(xiàng)目里總結(jié)的做法不是什么高深理論但都是踩過坑換來的。第一個(gè)心得是Redis的key一定要有命名規(guī)范。我常用的格式是業(yè)務(wù)名:實(shí)體名:ID例如user:info:1001、order:status:8888。好處是排查問題時(shí)能通過前綴快速定位是一類數(shù)據(jù)也可以用SCAN user:*遍歷相關(guān)key。別小看這件事等Redis里有幾千萬個(gè)key的時(shí)候連命名都亂成一團(tuán)線上事故處理起來會(huì)非常煎熬。第二個(gè)心得是Redis里真的只放值得放的數(shù)據(jù)。Redis是內(nèi)存數(shù)據(jù)庫內(nèi)存比磁盤貴得多放進(jìn)去的數(shù)據(jù)越大成本越高。那些動(dòng)輒幾百KB的文本、大列表放之前認(rèn)真想想能不能換一種存儲(chǔ)方案。我在一個(gè)項(xiàng)目里見過有人把整個(gè)文件內(nèi)容以base64形式塞進(jìn)Redis一個(gè)key就占幾十MB這種行為基本等同于花錢買罪受。第三個(gè)心得是監(jiān)控一定要提前做。接入Redis的同時(shí)用INFO memory關(guān)注內(nèi)存使用量、INFO stats關(guān)注命中率設(shè)置好告警。Redis宕機(jī)不可怕可怕的是它內(nèi)存撐爆了、swap開始拖垮整機(jī)性能而你完全不知道。第四個(gè)心得是關(guān)于發(fā)布訂閱和分布式鎖這類進(jìn)階能力。熱詞里經(jīng)常能看到redis分布式鎖這個(gè)確實(shí)是剛需但用的時(shí)侯一定要注意鎖的過期時(shí)間與業(yè)務(wù)執(zhí)行時(shí)間的匹配避免鎖提前釋放導(dǎo)致并發(fā)進(jìn)入臨界區(qū)。業(yè)界成熟的做法是用紅鎖算法或者引入更專門的協(xié)調(diào)服務(wù)單機(jī)Redis的分布式鎖只能滿足多數(shù)普通場景。不要因?yàn)镽edis功能多就把它當(dāng)萬能數(shù)據(jù)庫用有些一致性要求很高的數(shù)據(jù)關(guān)系數(shù)據(jù)庫的主鍵約束和事務(wù)機(jī)制是不可替代的。文章寫到這里正好把連接Redis從安裝、連接方式、數(shù)據(jù)類型到線上問題排查整個(gè)鏈路都過了一遍。如果你照著示例代碼把連接池封裝和JSON讀寫跑通了接下來完全可以自己動(dòng)手?jǐn)U展比如做接口級(jí)的緩存中間件或者寫一個(gè)基于ZSet的簡易排行榜服務(wù)。我自己第一次真正吃透Redis就是從封裝一個(gè)RedisClient開始的把每個(gè)參數(shù)、每種數(shù)據(jù)類型都親手驗(yàn)證一遍后面再碰到生產(chǎn)和性能問題心里就有底得多。這套東西并不難難的是邁出第一步親手敲一遍代碼。