簡(jiǎn)介面向大型網(wǎng)站高性能、高并發(fā)與高可用架構(gòu)設(shè)計(jì)的學(xué)習(xí)需求這份docx技術(shù)指南面向具備一定IT基礎(chǔ)的工程師和架構(gòu)師幫助梳理架構(gòu)目標(biāo)、模式選型與分層優(yōu)化的完整方法。內(nèi)容覆蓋分層、分割、分布式部署、集群、緩存、異步等常見(jiàn)模式并延伸到前端、瀏覽器、應(yīng)用層、代碼和存儲(chǔ)層優(yōu)化以及冗余備份、失效轉(zhuǎn)移、CAP理論、分庫(kù)分表、一致性Hash、安全架構(gòu)與電商網(wǎng)站架構(gòu)演進(jìn)案例兼顧理論框架和落地思路。資源包共1個(gè)docx文件大小約3.19MB便于集中閱讀和專(zhuān)題查閱。已有1124人學(xué)習(xí)說(shuō)明其在架構(gòu)設(shè)計(jì)入門(mén)與進(jìn)階場(chǎng)景中具有一定參考價(jià)值。讀者可據(jù)此建立大型網(wǎng)站架構(gòu)知識(shí)地圖理解不同階段的優(yōu)化重點(diǎn)與可用性保障策略并結(jié)合案例對(duì)照自身系統(tǒng)查漏補(bǔ)缺對(duì)準(zhǔn)備大規(guī)模擴(kuò)展或正面臨高流量挑戰(zhàn)的團(tuán)隊(duì)也可作為架構(gòu)演進(jìn)參考。1. 三臺(tái)機(jī)器到三十臺(tái) Tomcat這份指南補(bǔ)的是哪一段路有個(gè)場(chǎng)景很典型一個(gè)小團(tuán)隊(duì)要做全品類(lèi)電商站點(diǎn)目標(biāo)是三到五年做到一千萬(wàn)注冊(cè)用戶(hù)還要定期扛大促。第一次做容量預(yù)估按峰值算出來(lái)要三十臺(tái) Web 服務(wù)器采購(gòu)單還沒(méi)批下來(lái)負(fù)責(zé)人先問(wèn)了一句——平時(shí)只用十臺(tái)剩下二十臺(tái)一年開(kāi)幾天這個(gè)問(wèn)題就是高性能、高并發(fā)、高可用架構(gòu)設(shè)計(jì)真正開(kāi)始的地方。這份資料把大型網(wǎng)站的架構(gòu)目標(biāo)拆成高性能、高可用、可伸縮、可擴(kuò)展、安全、敏捷六條再按分層、分割、分布式、集群、緩存、異步、冗余這些模式落到七層邏輯架構(gòu)上最后用一套電商站點(diǎn)從單機(jī)到分布式服務(wù)的完整演化過(guò)程串起來(lái)。它適合已經(jīng)能獨(dú)立上線(xiàn)一個(gè)中小系統(tǒng)、但要第一次面對(duì)流量突增的工程師也適合需要把“分布式系統(tǒng)”這四個(gè)字從概念變成部署圖的人。2. 容量預(yù)估把“一千萬(wàn)注冊(cè)用戶(hù)”折算成每秒 8340 個(gè)并發(fā)架構(gòu)設(shè)計(jì)最容易出問(wèn)題的地方是沒(méi)有算清楚目標(biāo)就動(dòng)手畫(huà)圖。容量預(yù)估是整份資料里最該先讀的一節(jié)因?yàn)樗鼪Q定了后面所有選型集群要幾臺(tái)、緩存要多大、數(shù)據(jù)庫(kù)要不要拆。這一步算錯(cuò)后面的負(fù)載均衡和分庫(kù)分表全都要返工。我見(jiàn)過(guò)不少團(tuán)隊(duì)把“注冊(cè)用戶(hù)數(shù)”直接當(dāng)成“并發(fā)用戶(hù)數(shù)”報(bào)上去結(jié)果要么采購(gòu)過(guò)量要么上線(xiàn)當(dāng)天被打穿兩種結(jié)果都不會(huì)有人滿(mǎn)意。2.1 從 UV 到 QPS 的四步折算折算的起點(diǎn)不是注冊(cè)用戶(hù)是日活。一千萬(wàn)注冊(cè)用戶(hù)按二八原則取 20% 作為日 UV也就是 200 萬(wàn)人均日點(diǎn)擊按 30 次算覆蓋瀏覽、搜索、加購(gòu)、下單這些動(dòng)作日 PV 就是 6000 萬(wàn)。真正的并發(fā)峰值不落在全天而是落在一天里 20% 的時(shí)間里產(chǎn)生 80% 請(qǐng)求的那一段24 小時(shí)乘 0.2 是 4.8 小時(shí)也就是 288 分鐘這 288 分鐘要承接 4800 萬(wàn)次訪問(wèn)每分鐘約 16.7 萬(wàn)次換算到秒就是 2780 次。大促峰值按平常的三倍估每秒 8340 次。這個(gè)數(shù)在資料里寫(xiě)得很明確也是后面所有服務(wù)器臺(tái)數(shù)的計(jì)算基準(zhǔn)。參數(shù)取值計(jì)算方式或依據(jù)注冊(cè)用戶(hù)1000 萬(wàn)3~5 年業(yè)務(wù)目標(biāo)日 UV200 萬(wàn)注冊(cè)用戶(hù) × 20%二八原則人均日點(diǎn)擊30 次瀏覽 搜索 加購(gòu) 下單合計(jì)日 PV6000 萬(wàn)日 UV × 人均點(diǎn)擊集中訪問(wèn)時(shí)長(zhǎng)4.8 小時(shí)24 × 0.280% 請(qǐng)求落在 20% 時(shí)間集中訪問(wèn)量4800 萬(wàn)日 PV × 0.8每分鐘請(qǐng)求16.7 萬(wàn)4800 萬(wàn) ÷ 288 分鐘平時(shí) QPS278016.7 萬(wàn) ÷ 60峰值 QPS8340平時(shí) × 3這套折算適合用腳本跑改一個(gè)參數(shù)就能看結(jié)果比在表格里手改公式可靠得多# capacity.py 容量預(yù)估從注冊(cè)用戶(hù)反推每秒并發(fā) REG_USER 10_000_000 # 3~5 年注冊(cè)用戶(hù)目標(biāo) ACTIVE_RATIO 0.2 # 二八原則20% 用戶(hù)產(chǎn)生 80% 訪問(wèn) CLICK_PER_USER 30 # 人均日點(diǎn)擊瀏覽 搜索 加購(gòu) 下單 PEAK_WINDOW 0.2 # 80% 流量集中在 20% 的時(shí)間里 PEAK_FACTOR 3 # 大促峰值 平常值 3 倍 daily_uv REG_USER * ACTIVE_RATIO daily_pv daily_uv * CLICK_PER_USER busy_min 24 * 60 * PEAK_WINDOW # 集中訪問(wèn)時(shí)長(zhǎng)分鐘 busy_pv daily_pv * 0.8 qps_avg busy_pv / busy_min / 60 qps_peak qps_avg * PEAK_FACTOR print(f日 UV {daily_uv/1e4:.0f} 萬(wàn), 日 PV {daily_pv/1e4:.0f} 萬(wàn)) print(f平常 QPS {qps_avg:.0f}, 峰值 QPS {qps_peak:.0f})腳本里每個(gè)常量都對(duì)應(yīng)一個(gè)業(yè)務(wù)假設(shè)改假設(shè)之前先想清楚依據(jù)ACTIVE_RATIO 取 0.2 是行業(yè)里比較常見(jiàn)的活躍度如果你的產(chǎn)品是工具型低頻應(yīng)用取 0.1 更穩(wěn)PEAK_FACTOR 取 3 是按有大促活動(dòng)的站點(diǎn)估的沒(méi)有活動(dòng)運(yùn)營(yíng)的站點(diǎn)取 2 就夠。運(yùn)行結(jié)果會(huì)和上表對(duì)得上日志里同時(shí)打印 UV 和 PV 是為了交叉驗(yàn)證防止某個(gè)參數(shù)填錯(cuò)一個(gè)量級(jí)還看不出來(lái)。提示容量預(yù)估的結(jié)果要寫(xiě)進(jìn)設(shè)計(jì)文檔并標(biāo)注每個(gè)假設(shè)的來(lái)源。半年后業(yè)務(wù)變了能一眼看出是哪條假設(shè)失效比重新拍腦袋估一遍省事得多。2.2 并發(fā)數(shù)不等于 QPS最容易搞混的一個(gè)換算拿到 2780 這個(gè)數(shù)之后很多人直接拿它去除以單機(jī)并發(fā)能力得出服務(wù)器臺(tái)數(shù)這一步幾乎必錯(cuò)。并發(fā)線(xiàn)程數(shù)和 QPS 之間隔著響應(yīng)時(shí)間QPS 并發(fā)數(shù) ÷ 平均 RT。同樣 2780 QPS接口平均 RT 是 100 毫秒需要同時(shí)在跑的線(xiàn)程是 278 個(gè)一臺(tái)機(jī)器就能扛RT 漲到 500 毫秒同樣流量下需要的線(xiàn)程變成 1390 個(gè)得五臺(tái)機(jī)器才頂?shù)米?。性能?yōu)化和擴(kuò)容在這里是同一件事的兩面把 RT 壓下去等于憑空多出幾臺(tái)機(jī)器。按資料里的口徑單臺(tái) Web 服務(wù)器按每秒 300 個(gè)并發(fā)來(lái)估算日常 2780 QPS 需要約 10 臺(tái)峰值 8340 QPS 需要約 30 臺(tái)。這個(gè) 300 是有前提的Tomcat 默認(rèn)的 maxThreads 是 150實(shí)際能扛到 300 意味著大部分請(qǐng)求的 RT 要壓得足夠短且 CPU 利用率維持在 70% 左右峰值時(shí)才允許沖到 90%。這就是 70/90 原則——平時(shí)留三成余量給突發(fā)峰值把余量用滿(mǎn)但不打滿(mǎn)既不浪費(fèi)資源也不至于一有抖動(dòng)就雪崩。場(chǎng)景QPS平均 RT所需并發(fā)線(xiàn)程單機(jī) 300 并發(fā)下的臺(tái)數(shù)日常2780100 ms2781實(shí)際按冗余布 2 臺(tái)起日常2780300 ms8343峰值8340100 ms8343峰值8340300 ms25029表格里的數(shù)字和資料里“日常 10 臺(tái)、峰值 30 臺(tái)”看起來(lái)差得不小原因在 RT資料按更保守的 RT 和更保守的單機(jī)承載估我這張表按 300 并發(fā)、RT 可控來(lái)算。兩種口徑都不算錯(cuò)差的是對(duì)代碼性能的信心。實(shí)操里我一般先按保守口徑報(bào)預(yù)算壓測(cè)跑完拿到真實(shí) RT再往下修省得上線(xiàn)前臨時(shí)加機(jī)器來(lái)不及采購(gòu)。2.3 峰值和日常的差值怎么消化30 臺(tái)和 10 臺(tái)之間的差距就是這份資料里點(diǎn)出的第一個(gè)真問(wèn)題大量服務(wù)器只有在大促時(shí)才用得上平時(shí)是純浪費(fèi)。不解決這個(gè)差值架構(gòu)圖畫(huà)得再漂亮成本這一關(guān)也過(guò)不去。消化差值的辦法有三類(lèi)優(yōu)先級(jí)從高到低是削峰、限流、彈性擴(kuò)容。削峰靠異步。下單請(qǐng)求進(jìn)來(lái)不直接寫(xiě)庫(kù)先落消息隊(duì)列前端立刻返回排隊(duì)中后臺(tái)按數(shù)據(jù)庫(kù)能吃下的速度慢慢消費(fèi)。資料里把這種“請(qǐng)求—響應(yīng)—通知”的模式歸到異步架構(gòu)模式它對(duì)付的是瞬時(shí)洪峰不是持續(xù)高負(fù)載。限流是第二道超過(guò)閾值就讓請(qǐng)求排隊(duì)或者返回 429寧可讓 1% 的用戶(hù)等兩秒也不能讓 100% 的用戶(hù)一起超時(shí)。彈性擴(kuò)容排最后因?yàn)樗龣C(jī)器從創(chuàng)建到進(jìn)集群跑起來(lái)幾分鐘起步只適合應(yīng)對(duì)可以預(yù)判的活動(dòng)。# 按單機(jī)實(shí)測(cè)承壓能力的 80% 設(shè)閾值超出后排隊(duì)而不是直接拒絕 limit_req_zone $binary_remote_addr zoneperip:10m rate20r/s; limit_req_zone $server_name zoneperserver:10m rate800r/s; server { location /product/ { limit_req zoneperserver burst200 nodelay; # 允許 200 個(gè)突發(fā)排隊(duì) limit_req_status 429; # 明確返回限流碼方便監(jiān)控統(tǒng)計(jì) proxy_pass http://product_cluster; } location /api/comment/ { limit_req zoneperip burst10 nodelay; # 非核心接口按 IP 收得更緊 limit_req_status 429; proxy_pass http://comment_cluster; } }配置里兩個(gè) zone 對(duì)應(yīng)兩種限流維度perserver 按虛擬主機(jī)整體限流護(hù)住核心鏈路perip 按來(lái)源 IP 限流主要防刷。rate 的單位是每秒請(qǐng)求數(shù)burst 是允許超出的突發(fā)量nodelay 表示突發(fā)部分立即放行而不是勻速排隊(duì)——不加 nodelay超出的請(qǐng)求會(huì)被平滑拉長(zhǎng)用戶(hù)側(cè)感知就是接口變慢大促時(shí)這種慢會(huì)順著調(diào)用鏈放大。閾值不能憑感覺(jué)填先壓測(cè)出單機(jī)能穩(wěn)定處理的 QPS再乘 0.8 寫(xiě)進(jìn)去改完觀察 429 的比例超過(guò)總請(qǐng)求的 1% 就說(shuō)明閾值定低了。3. 分層、分割、分布式、集群把架構(gòu)模式翻譯成部署拓?fù)浞謱印⒎指?、分布式、集群、緩存、異步、冗余、安全、自?dòng)化、敏捷這十個(gè)詞背下來(lái)只要五分鐘但把它們對(duì)應(yīng)到部署圖上是幾臺(tái)機(jī)器、幾條網(wǎng)絡(luò)跳數(shù)、幾個(gè)團(tuán)隊(duì)負(fù)責(zé)才是架構(gòu)設(shè)計(jì)真正的工作量。這份資料的價(jià)值在于它把每個(gè)模式都落到了具體層上而不是停在概念介紹。3.1 七層邏輯架構(gòu)與業(yè)務(wù)垂直切分資料給出的七層是從客戶(hù)端一路排到大數(shù)據(jù)處理層的每一層的擴(kuò)容方式和高可用手段都不一樣混著做就會(huì)互相拖累。層級(jí)主要職責(zé)擴(kuò)容方式高可用手段客戶(hù)層PC 瀏覽器、移動(dòng)端無(wú)客戶(hù)端側(cè)多入口、降級(jí)到簡(jiǎn)版頁(yè)前端層DNS 調(diào)度、CDN、反向代理加節(jié)點(diǎn)多 CDN、代理集群應(yīng)用層業(yè)務(wù)集群按業(yè)務(wù)垂直拆分水平加機(jī)器負(fù)載均衡、無(wú)狀態(tài)設(shè)計(jì)服務(wù)層公共的訂單、支付、用戶(hù)服務(wù)水平加機(jī)器服務(wù)降級(jí)、超時(shí)、冪等數(shù)據(jù)層關(guān)系庫(kù)集群、NoSQL、分布式緩存讀寫(xiě)分離、分庫(kù)分表主備、失效轉(zhuǎn)移大數(shù)據(jù)存儲(chǔ)層日志與結(jié)構(gòu)化數(shù)據(jù)歸集加存儲(chǔ)節(jié)點(diǎn)多副本大數(shù)據(jù)處理層離線(xiàn)與實(shí)時(shí)分析加計(jì)算節(jié)點(diǎn)任務(wù)重試、隔離隊(duì)列應(yīng)用層的拆分方式在資料里寫(xiě)得很具體按業(yè)務(wù)屬性垂直切成產(chǎn)品、購(gòu)物、支付、評(píng)論、客服、接口六個(gè)子系統(tǒng)。切完之后還要做等級(jí)定義產(chǎn)品和購(gòu)物、支付算核心系統(tǒng)評(píng)論、客服、接口算非核心。這個(gè)等級(jí)不是為了寫(xiě)文檔好看它直接決定了兩件事——出故障時(shí)先保誰(shuí)流量突增時(shí)先降誰(shuí)。核心系統(tǒng)單獨(dú)部署非核心系統(tǒng)可以合并部署省機(jī)器兩種方案在資源緊張時(shí)都能用。注意垂直切分不是越細(xì)越好。每切一刀子系統(tǒng)之間就多一次遠(yuǎn)程調(diào)用故障面從“一個(gè)進(jìn)程掛”變成“一條鏈路斷”。判斷標(biāo)準(zhǔn)是這兩塊業(yè)務(wù)的變更頻率和團(tuán)隊(duì)歸屬是否真的不同如果同一個(gè)團(tuán)隊(duì)同時(shí)維護(hù)、發(fā)布節(jié)奏一致切開(kāi)只會(huì)增加運(yùn)維成本。3.2 四層和七層的分界負(fù)載均衡怎么選負(fù)載均衡選型是架構(gòu)落地時(shí)第一個(gè)要拍板的技術(shù)決策常見(jiàn)的組合是四層設(shè)備打頭、七層代理做二級(jí)。區(qū)別在網(wǎng)絡(luò)模型的層級(jí)四層只看目標(biāo) IP 和端口轉(zhuǎn)發(fā)路徑短、吞吐高七層要解出報(bào)文內(nèi)容能按 URL、Header、Cookie 做路由但代價(jià)是連接被代理層接管開(kāi)銷(xiāo)更大。類(lèi)型可見(jiàn)信息性能典型用途硬件四層設(shè)備IP 端口最高入口第一層扛總流量四層軟件負(fù)載均衡IP 端口高入口分流成本低七層代理Nginx、HAProxy完整 HTTP 報(bào)文中動(dòng)靜分離、按業(yè)務(wù)路由、灰度實(shí)際部署里我一般這樣排最外層用四層做流量分發(fā)后面掛一組七層代理七層代理再按 URL 把請(qǐng)求分到不同的業(yè)務(wù)集群。這樣動(dòng)靜分離、灰度發(fā)布、按業(yè)務(wù)限流這些能力都能在七層做四層只負(fù)責(zé)把流量攤平。配置上要注意上游連接復(fù)用不開(kāi) keepalive 的話(huà)每次請(qǐng)求都要重新握手RT 會(huì)莫名其妙多出幾毫秒upstream product_cluster { least_conn; # 按當(dāng)前連接數(shù)分配長(zhǎng)請(qǐng)求多的場(chǎng)景比輪詢(xún)穩(wěn) server 10.0.1.11:8080 max_fails2 fail_timeout10s; server 10.0.1.12:8080 max_fails2 fail_timeout10s; keepalive 64; # 與上游保持 64 個(gè)空閑長(zhǎng)連接省掉握手開(kāi)銷(xiāo) } server { location /product/ { proxy_http_version 1.1; # keepalive 必須配合 HTTP/1.1 proxy_set_header Connection ; # 清掉 close否則長(zhǎng)連接失效 proxy_connect_timeout 1s; # 連接超時(shí)要短快速失敗 proxy_read_timeout 3s; # 讀超時(shí)按 P99 RT 的 2~3 倍設(shè) proxy_next_upstream error timeout; # 失敗自動(dòng)換一臺(tái)重試一次就夠 proxy_pass http://product_cluster; } }幾個(gè)參數(shù)值得單獨(dú)說(shuō)。least_conn 在請(qǐng)求耗時(shí)差異大時(shí)比默認(rèn)輪詢(xún)更均衡因?yàn)檩喸?xún)會(huì)把新請(qǐng)求派給還沒(méi)處理完長(zhǎng)請(qǐng)求的節(jié)點(diǎn)。max_fails 和 fail_timeout 組合起來(lái)決定健康檢查的靈敏度2 次失敗、10 秒內(nèi)不再派流量閾值太松會(huì)把請(qǐng)求打到已經(jīng)掛掉的節(jié)點(diǎn)太緊則容易誤判。代理層的超時(shí)一定要設(shè)短并且必須小于上游服務(wù)的超時(shí)否則代理還在等、上游已經(jīng)放棄兩臺(tái)機(jī)器的時(shí)間對(duì)不上排查的時(shí)候就是黑匣子。proxy_next_upstream 要慎用只對(duì)冪等請(qǐng)求開(kāi)重試下單和支付這類(lèi)接口重試會(huì)造成重復(fù)扣款。3.3 集群之后的狀態(tài)去哪Session 的三種處理應(yīng)用服務(wù)器一旦做成集群第一個(gè)撞上的問(wèn)題就是 Session。同一用戶(hù)在兩次請(qǐng)求之間落到不同機(jī)器上登錄態(tài)就丟了。資料里把這條路歸到“無(wú)狀態(tài)設(shè)計(jì)”具體落地有三種做法會(huì)話(huà)復(fù)制、粘性會(huì)話(huà)、集中存儲(chǔ)。會(huì)話(huà)復(fù)制是在集群節(jié)點(diǎn)之間互相同步 Session 對(duì)象節(jié)點(diǎn)數(shù)一多同步的流量會(huì)呈平方級(jí)增長(zhǎng)三臺(tái)以?xún)?nèi)還能忍十臺(tái)以上基本不可用。粘性會(huì)話(huà)靠負(fù)載均衡把同一用戶(hù)的請(qǐng)求固定打到同一臺(tái)機(jī)器配置簡(jiǎn)單但那臺(tái)機(jī)器掛了用戶(hù)就得重新登錄而且流量分布會(huì)越來(lái)越不均。集中存儲(chǔ)是把 Session 挪到分布式緩存里應(yīng)用節(jié)點(diǎn)徹底無(wú)狀態(tài)加機(jī)器減機(jī)器都不影響登錄態(tài)是規(guī)模上去之后唯一還能擴(kuò)展的方案。// 集中式 Session只寫(xiě)變化的字段靠過(guò)期時(shí)間做滑動(dòng)續(xù)期 public void saveSession(String sid, MapString, Object delta) { String key sess: sid; redis.hset(key, delta); // 增量寫(xiě)入避免整對(duì)象覆蓋丟字段 redis.expire(key, 1800); // 30 分鐘滑動(dòng)過(guò)期每次請(qǐng)求重置 } public MapString, Object loadSession(String sid) { MapString, Object attrs redis.hgetAll(sess: sid); if (attrs.isEmpty()) { return null; // 返回 null 由上層跳登錄不要在這里拋異常 } redis.expire(sess: sid, 1800); return attrs; }這段代碼里最關(guān)鍵的不是存是過(guò)期策略。每次請(qǐng)求都重置過(guò)期時(shí)間等于把“活躍用戶(hù)”和“登錄態(tài)”綁在一起30 分鐘內(nèi)沒(méi)有操作的會(huì)話(huà)自動(dòng)回收緩存不會(huì)無(wú)限膨脹。增量寫(xiě)入而不是整對(duì)象覆蓋是為了避免并發(fā)場(chǎng)景下兩個(gè)請(qǐng)求各寫(xiě)一半、互相把對(duì)方的字段抹掉。清空 Session 時(shí)記得用 del 而不是把字段置空否則 hgetAll 拿到的是一堆空值上層的登錄判斷會(huì)失效。4. 多級(jí)緩存與數(shù)據(jù)庫(kù)拆分把熱點(diǎn)數(shù)據(jù)擋在數(shù)據(jù)庫(kù)之前數(shù)據(jù)庫(kù)永遠(yuǎn)是這套架構(gòu)里最難擴(kuò)的一環(huán)。應(yīng)用層加機(jī)器是分鐘級(jí)的事數(shù)據(jù)庫(kù)加機(jī)器要考慮主從同步、數(shù)據(jù)一致性、分片路由動(dòng)一次傷筋動(dòng)骨。所以思路是盡量不讓請(qǐng)求走到數(shù)據(jù)庫(kù)——緩存擋在前面讀寫(xiě)分離擋在第二層分庫(kù)分表是最后的辦法。4.1 一級(jí)本地緩存和二級(jí)分布式緩存的分工緩存能起作用的前提是數(shù)據(jù)分布不均資料里引的是二八原則80% 的訪問(wèn)最終落在 20% 的數(shù)據(jù)上。熱點(diǎn)數(shù)據(jù)被反復(fù)讀取把它放到離應(yīng)用最近的地方就能省掉后面所有的網(wǎng)絡(luò)往返和磁盤(pán) IO。兩級(jí)緩存的分工是一級(jí)放基本不變或者有規(guī)律變化的數(shù)據(jù)比如數(shù)據(jù)字典、類(lèi)目樹(shù)二級(jí)放全量熱點(diǎn)數(shù)據(jù)比如商品詳情、活動(dòng)配置。請(qǐng)求的讀取順序是一級(jí) → 二級(jí) → 數(shù)據(jù)庫(kù)一級(jí)過(guò)期或未命中就去二級(jí)二級(jí)也沒(méi)有才回源?；卦粗笾鸺?jí)回填回填時(shí)給不同的過(guò)期時(shí)間避免所有 key 同時(shí)失效。資料里提到緩存比例一般 1:4 就值得上緩存理論上 1:2 就夠了——這個(gè)比例說(shuō)的是“讀次數(shù) : 回源次數(shù)”低于這個(gè)數(shù)緩存的維護(hù)成本超過(guò)它省下的數(shù)據(jù)庫(kù)壓力。// 兩級(jí)緩存讀取本地 Caffeine 在前Redis 在后回源加互斥鎖 public Product getProduct(long skuId) { String key sku: skuId; Product p localCache.getIfPresent(key); // 一級(jí)進(jìn)程內(nèi)納秒級(jí) if (p ! null) return p; p redis.get(key); // 二級(jí)跨進(jìn)程共享 if (p ! null) { localCache.put(key, p); // 回填一級(jí)短過(guò)期 return p; } String lock lock: key; // 只讓一個(gè)線(xiàn)程去查庫(kù) if (redis.setnx(lock, 1, 10)) { try { p db.queryProduct(skuId); // 回源 if (p ! null) { redis.setex(key, 1800 rnd(300), p); // 二級(jí) 30 分鐘 隨機(jī)抖動(dòng) localCache.put(key, p); // 一級(jí) 60 秒故意設(shè)短 } } finally { redis.del(lock); } } else { sleep(50); // 沒(méi)搶到鎖稍等再讀一次二級(jí) p redis.get(key); } return p; }一級(jí)緩存故意設(shè)得比二級(jí)短是個(gè)血淚經(jīng)驗(yàn)本地緩存分布在每臺(tái)應(yīng)用機(jī)器上沒(méi)法主動(dòng)失效只能靠過(guò)期自然淘汰。二級(jí)緩存改了數(shù)據(jù)還能通知到一級(jí)不行。如果一級(jí)設(shè)得長(zhǎng)會(huì)出現(xiàn)“后臺(tái)改了商品價(jià)格部分用戶(hù)十分鐘后才看到”這種無(wú)法復(fù)現(xiàn)的玄學(xué)問(wèn)題。列表頁(yè)這種對(duì)一致性要求不高的場(chǎng)景一級(jí)緩存可以設(shè)長(zhǎng)一點(diǎn)詳情頁(yè)和價(jià)格相關(guān)的一定要短。4.2 讀寫(xiě)分離和分庫(kù)分表什么時(shí)候切、按什么鍵切讀寫(xiě)分離解決的是讀多寫(xiě)少的場(chǎng)景。主庫(kù)承擔(dān)寫(xiě)從庫(kù)承擔(dān)讀靠主備復(fù)制同步數(shù)據(jù)。它能擴(kuò)讀的能力但擴(kuò)不了寫(xiě)而且引入一個(gè)繞不過(guò)去的問(wèn)題主從延遲。剛下單立刻查訂單詳情從庫(kù)可能還沒(méi)同步到用戶(hù)看到的是“訂單不存在”。處理辦法有兩種一是強(qiáng)制走主庫(kù)讀二是延遲雙查先查從庫(kù)查不到隔 200 毫秒再查一次。前者簡(jiǎn)單但會(huì)把主庫(kù)壓力拉回去后者體驗(yàn)好一點(diǎn)但要控制重試次數(shù)。分庫(kù)分表是最后的手段因?yàn)樗淖兞藬?shù)據(jù)訪問(wèn)的基本假設(shè)。垂直切分按業(yè)務(wù)切用戶(hù)業(yè)務(wù)、商品業(yè)務(wù)的表放不同庫(kù)這個(gè)和應(yīng)用層的垂直拆分是對(duì)應(yīng)的。水平切分是把一張大表按某個(gè)鍵拆成多張用戶(hù)表是最典型的例子按用戶(hù) ID 取模分到 16 張物理表。// 水平分表路由uid 取模庫(kù)內(nèi) 16 張表 public String routeTable(long uid) { int idx (int) (uid 15); // 16 是 2 的冪位運(yùn)算比取模快 return String.format(t_user_%02d, idx); } // 跨分片查詢(xún)不要拼 UNION ALL改成先查索引表再按 id 批量取 public ListOrder listOrders(long uid, int page, int size) { String t routeTable(uid); // 同一用戶(hù)的數(shù)據(jù)一定在同一張表 return jdbc.query(SELECT * FROM t WHERE uid ? ORDER BY id DESC LIMIT ?, ?, uid, page * size, size); }取模的好處是分布均勻、路由計(jì)算快壞處是擴(kuò)容時(shí)要重新分布。16 張表擴(kuò)到 32 張存量數(shù)據(jù)得全部重算一遍過(guò)程中還得保證不停服。所以分片數(shù)一開(kāi)始就要留余量按三到五年的量估寧可從 16 張起步后面只做歸檔也別半年就擴(kuò)一次。想避開(kāi)這個(gè)問(wèn)題就用一致性 Hash擴(kuò)縮容時(shí)只有相鄰的一段數(shù)據(jù)需要遷移代價(jià)是實(shí)現(xiàn)復(fù)雜度高定位問(wèn)題時(shí)要多繞幾層。提示分片鍵選錯(cuò)比不分還糟。訂單按用戶(hù) ID 分片那“按訂單號(hào)查詢(xún)”和“按商家查詢(xún)”就變成了跨所有分片的廣播查詢(xún)本來(lái)一個(gè)索引能解決的問(wèn)題變成了 16 次查詢(xún)。跨分片的查詢(xún)需求要在設(shè)計(jì)階段列出來(lái)數(shù)量多的話(huà)考慮建異構(gòu)索引表。4.3 緩存穿透、擊穿、雪崩的三道防線(xiàn)三個(gè)詞經(jīng)常被混著用但成因完全不同。穿透是查一個(gè)數(shù)據(jù)庫(kù)里根本沒(méi)有的數(shù)據(jù)緩存永遠(yuǎn)不命中每次請(qǐng)求都打到庫(kù)上擊穿是某個(gè)熱點(diǎn) key 過(guò)期的瞬間大量并發(fā)同時(shí)回源雪崩是大批 key 在同一時(shí)刻集體過(guò)期或者緩存集群整個(gè)掛了壓力全部轉(zhuǎn)給數(shù)據(jù)庫(kù)。問(wèn)題成因處理辦法穿透查不存在的數(shù)據(jù)緩存不命中空值也緩存短期過(guò)期參數(shù)合法性校驗(yàn)前置擊穿單個(gè)熱點(diǎn) key 過(guò)期瞬間并發(fā)回源互斥重建只放一個(gè)線(xiàn)程查庫(kù)雪崩大量 key 同時(shí)過(guò)期 / 緩存集群故障過(guò)期時(shí)間加隨機(jī)抖動(dòng)二級(jí)緩存兜底數(shù)據(jù)庫(kù)限流過(guò)期時(shí)間打散是最便宜的一招寫(xiě)入時(shí)在基礎(chǔ)過(guò)期時(shí)間上疊一個(gè)幾百秒的隨機(jī)數(shù)把原本擠在一個(gè)點(diǎn)上的失效分散成一段時(shí)間的均勻分布?；コ庵亟ㄔ?4.1 的代碼里已經(jīng)用了靠 setnx 搶鎖沒(méi)搶到的線(xiàn)程短暫等待后重讀緩存?？罩稻彺嬉⒁獠荒茉O(shè)太長(zhǎng)否則正常的商品上架后用戶(hù)要等好幾分鐘才能看到一般給 60 秒到 5 分鐘。5. 高可用避坑五個(gè)把線(xiàn)上拖垮的細(xì)節(jié)和排查順序四個(gè)九意味著一年不可用時(shí)間只有 53 分鐘這個(gè)目標(biāo)不是靠買(mǎi)貴的設(shè)備實(shí)現(xiàn)的是靠把每一個(gè)可能出錯(cuò)的地方提前想到。資料里說(shuō)得很直白分布式、廉價(jià)服務(wù)器、開(kāi)源數(shù)據(jù)庫(kù)、操作系統(tǒng)這些前提決定了故障是不可避免的能做的只有縮短故障發(fā)現(xiàn)時(shí)間和恢復(fù)時(shí)間。下面這五條是我在實(shí)際排查里遇到過(guò)、并且都能在資料描述的架構(gòu)里對(duì)上號(hào)的。5.1 坑一Session 同步把內(nèi)網(wǎng)帶寬吃滿(mǎn)現(xiàn)象是每天上午十點(diǎn)左右應(yīng)用集群整體 RT 抖動(dòng)但沒(méi)有機(jī)器 CPU 打滿(mǎn)日志里也沒(méi)有異常網(wǎng)絡(luò)監(jiān)控顯示內(nèi)網(wǎng)流量在固定時(shí)間有個(gè)尖峰。原因在于用了會(huì)話(huà)復(fù)制方案而且 Session 里存了大對(duì)象——用戶(hù)的購(gòu)物車(chē)快照和推薦列表被一起塞了進(jìn)去單個(gè) Session 幾百 KB。集群從 3 臺(tái)擴(kuò)到 8 臺(tái)之后每次會(huì)話(huà)變更都要廣播到其余 7 臺(tái)流量是節(jié)點(diǎn)數(shù)的平方級(jí)增長(zhǎng)擴(kuò)機(jī)器反而讓系統(tǒng)更慢。解決分兩步先把 Session 瘦身只留用戶(hù) ID 和登錄態(tài)這類(lèi)小字段購(gòu)物車(chē)和推薦改成按需查詢(xún)?cè)贀Q成集中式存儲(chǔ)應(yīng)用節(jié)點(diǎn)徹底無(wú)狀態(tài)。改完之后集群從 8 臺(tái)擴(kuò)到 20 臺(tái)內(nèi)網(wǎng)流量基本沒(méi)變化。5.2 坑二緩存過(guò)期時(shí)間設(shè)成同一個(gè)整點(diǎn)現(xiàn)象是每天晚上零點(diǎn)零五分?jǐn)?shù)據(jù)庫(kù) CPU 從 40% 直接沖到 95%持續(xù)兩三分鐘慢查詢(xún)?nèi)罩纠锶巧唐吩斍椴樵?xún)。原因很典型類(lèi)目和商品配置是運(yùn)營(yíng)每天零點(diǎn)刷新一次代碼里統(tǒng)一setex(key, 86400, value)一萬(wàn)多個(gè) key 的過(guò)期時(shí)間精確到秒都落在同一時(shí)刻。零點(diǎn)一到全部失效請(qǐng)求全部回源數(shù)據(jù)庫(kù)瞬間被打穿。解決是把過(guò)期時(shí)間加上隨機(jī)抖動(dòng)基礎(chǔ)時(shí)間不變的情況下疊 0 到 600 秒的隨機(jī)數(shù)失效點(diǎn)被攤平到十分鐘里。另外加了一層預(yù)熱任務(wù)在運(yùn)營(yíng)刷新數(shù)據(jù)之前先把熱點(diǎn) key 主動(dòng)寫(xiě)一遍讓緩存永遠(yuǎn)不出現(xiàn)“全空”的狀態(tài)。5.3 坑三主備切換之后讀到了舊數(shù)據(jù)現(xiàn)象是大促當(dāng)天主庫(kù)所在機(jī)器故障自動(dòng)切換到備庫(kù)切換過(guò)程只用了 20 秒但之后陸續(xù)有用戶(hù)投訴“剛下的單查不到”。原因在主備復(fù)制的模式。用的是異步復(fù)制主庫(kù)寫(xiě)完就返回binlog 還沒(méi)來(lái)得及傳給備庫(kù)就掛了切換后備庫(kù)缺最后一段數(shù)據(jù)。更麻煩的是應(yīng)用側(cè)完全不知道發(fā)生了切換讀請(qǐng)求照常打到從庫(kù)讀到的還是更舊的數(shù)據(jù)。解決要做三件事核心的寫(xiě)鏈路改成半同步復(fù)制至少保證一個(gè)備庫(kù)收到 binlog 才返回成功切換后的一段時(shí)間內(nèi)涉及“剛寫(xiě)入的數(shù)據(jù)”的查詢(xún)強(qiáng)制走主庫(kù)切換動(dòng)作本身要能被監(jiān)控捕獲并推給業(yè)務(wù)方而不是靜默完成。5.4 坑四分庫(kù)分表之后跨庫(kù) JOIN 全表掃現(xiàn)象是用戶(hù)中心上線(xiàn)分庫(kù)分表之后后臺(tái)的訂單列表頁(yè)從 200 毫秒變成 8 秒DBA 那邊看到的是 16 個(gè)庫(kù)同時(shí)在被掃。原因是原來(lái)一句SELECT ... FROM orders o JOIN users u ON o.uid u.id WHERE u.city x訂單按 uid 分片、用戶(hù)按 id 分片兩個(gè)分片規(guī)則不對(duì)齊這條 SQL 被改寫(xiě)成對(duì)全部訂單分片的廣播查詢(xún)每個(gè)分片都要拉全量數(shù)據(jù)回來(lái)再合并。解決是在設(shè)計(jì)階段就把跨分片查詢(xún)列出來(lái)。這個(gè)場(chǎng)景的正確做法是讓用戶(hù)中心提供一個(gè)按城市查 uid 列表的接口先拿到 uid 集合再按 uid 路由到具體的訂單分片。異構(gòu)索引表也是一種選擇把城市到訂單的映射單獨(dú)存一份代價(jià)是多一次寫(xiě)入和一份存儲(chǔ)。5.5 坑五降級(jí)開(kāi)關(guān)只在文檔里存在現(xiàn)象是大促當(dāng)晚評(píng)論服務(wù)響應(yīng)變慢拖垮了同一臺(tái)機(jī)器上的購(gòu)物車(chē)接口最后整個(gè)下單鏈路超時(shí)。原因是評(píng)論和購(gòu)物車(chē)雖然邏輯上分了核心非核心但因?yàn)闄C(jī)器緊張被合并部署在同一批服務(wù)器上評(píng)論服務(wù)的線(xiàn)程池占滿(mǎn)之后購(gòu)物車(chē)拿不到線(xiàn)程。文檔里寫(xiě)著“可降級(jí)”但代碼里根本沒(méi)有對(duì)應(yīng)的開(kāi)關(guān)出事時(shí)只能靠人工摘節(jié)點(diǎn)。解決是降級(jí)要落在代碼里而不是文檔里。每個(gè)非核心接口都要有獨(dú)立的線(xiàn)程池或獨(dú)立的部署單元配一個(gè)可動(dòng)態(tài)修改的開(kāi)關(guān)開(kāi)關(guān)觸發(fā)后直接返回兜底數(shù)據(jù)不查庫(kù)不走下游。合并部署的前提是資源隔離做到位做不到就老老實(shí)實(shí)分開(kāi)。6. 上線(xiàn)前的驗(yàn)證把 99.99% 當(dāng)成一次可以演練的故障架構(gòu)圖畫(huà)完、代碼寫(xiě)完離“能扛住”還差一整輪驗(yàn)證。容量預(yù)估給的是理論值負(fù)載均衡配置給的是預(yù)期行為這兩個(gè)東西不經(jīng)過(guò)壓測(cè)和故障演練沒(méi)人知道實(shí)際會(huì)怎樣。我的習(xí)慣是把驗(yàn)證拆成兩塊一塊是壓測(cè)驗(yàn)證容量一塊是故障注入驗(yàn)證高可用。壓測(cè)不要只打單接口要按真實(shí)的調(diào)用鏈打。用一個(gè)混合場(chǎng)景腳本把瀏覽、搜索、加購(gòu)、下單按 50:30:15:5 的比例混著發(fā)跑出來(lái)的 RT 才有參考價(jià)值。壓測(cè)過(guò)程中重點(diǎn)看三處單機(jī) CPU 是否穩(wěn)定在 70% 到 80% 之間429 的比例是否低于 1%數(shù)據(jù)庫(kù)連接池是否有等待。任何一個(gè)指標(biāo)不對(duì)都要回頭改配置而不是加大壓力硬扛。演練項(xiàng)注入方式驗(yàn)收標(biāo)準(zhǔn)應(yīng)用節(jié)點(diǎn)宕機(jī)隨機(jī) kill 一個(gè)實(shí)例30 秒內(nèi)流量全部轉(zhuǎn)移錯(cuò)誤率低于 0.1%主庫(kù)故障切換手動(dòng)觸發(fā)主備切換寫(xiě)入中斷小于 60 秒無(wú)數(shù)據(jù)丟失緩存集群不可用切斷應(yīng)用與緩存網(wǎng)絡(luò)數(shù)據(jù)庫(kù) QPS 不超容量上限接口降級(jí)返回下游服務(wù)超時(shí)注入 5 秒延遲上游熔斷生效不出現(xiàn)線(xiàn)程池堆積流量突增三倍壓測(cè)腳本提到峰值限流觸發(fā)核心鏈路 RT 保持穩(wěn)定故障注入建議在預(yù)發(fā)環(huán)境做并且一定要有人在旁邊盯著第一次演練翻車(chē)是常事。我第一次做緩存不可用演練切完網(wǎng)絡(luò)之后數(shù)據(jù)庫(kù)三分鐘就頂不住了原因是所有回源請(qǐng)求都沒(méi)有限流緩存這層擋板一撤請(qǐng)求直接壓到庫(kù)里。后來(lái)在數(shù)據(jù)訪問(wèn)層加了一個(gè)信號(hào)量回源并發(fā)超過(guò)閾值就快速失敗讓非核心功能先返回兜底數(shù)據(jù)才算是真正實(shí)現(xiàn)了資料里說(shuō)的“優(yōu)雅降級(jí)”。從那以后我每次做架構(gòu)設(shè)計(jì)都會(huì)把降級(jí)和限流的閾值寫(xiě)進(jìn)配置中心而不是留在代碼注釋里并且上線(xiàn)前必須把故障演練表跑一遍跑不過(guò)就不發(fā)版。這套流程麻煩但它能把“架構(gòu)上支持高可用”和“實(shí)際上扛得住”之間的那道縫補(bǔ)上。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取