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