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