一、交易型系統(tǒng)設(shè)計(jì)的一些原則
1.在設(shè)計(jì)系統(tǒng)時(shí)，應(yīng)該多思考墨菲定律：
* 任何事情都沒(méi)有表面看起來(lái)那么簡(jiǎn)單
* 所有的事都會(huì)比你預(yù)計(jì)的時(shí)間長(zhǎng)
* 可能出錯(cuò)的事總會(huì)出錯(cuò)
* 如果你擔(dān)心某種情況發(fā)生，那么它就更有可能發(fā)生
2.系統(tǒng)劃分時(shí)，要思考康威定律：
* 系統(tǒng)架構(gòu)是公司組織架構(gòu)的反映
* 應(yīng)該按照業(yè)務(wù)閉環(huán)進(jìn)行系統(tǒng)拆分/組織架構(gòu)劃分，實(shí)現(xiàn)閉環(huán)/高內(nèi)聚/低耦合，減少溝通成本
* 如果溝通出現(xiàn)問(wèn)題，那么就應(yīng)該考慮進(jìn)行系統(tǒng)和組織架構(gòu)的調(diào)整
* 在合適時(shí)機(jī)進(jìn)行系統(tǒng)拆分，不要一開(kāi)始就把系統(tǒng)/服務(wù)拆得非常細(xì)，雖然閉環(huán)，但是每個(gè)人維護(hù)的系統(tǒng)多，維護(hù)成本高
3.在有限資源的情況下，一定是先解決當(dāng)下最核心的問(wèn)題，預(yù)測(cè)并發(fā)現(xiàn)未來(lái)可能出現(xiàn)的問(wèn)題，一步步解決最痛點(diǎn)的問(wèn)題，即滿足需求的系統(tǒng)是不斷迭代優(yōu)化出來(lái)的
A.高并發(fā)原則
1.無(wú)狀態(tài)：比較容易進(jìn)行水平擴(kuò)展，應(yīng)用無(wú)狀態(tài)，配置文件有狀態(tài)
2.拆分：在系統(tǒng)設(shè)計(jì)初期，是做一個(gè)大而全的系統(tǒng)還是按功能模塊拆分系統(tǒng)，這個(gè)需要根據(jù)環(huán)境進(jìn)行權(quán)衡
* 系統(tǒng)維度：按照系統(tǒng)功能/業(yè)務(wù)拆分
* 功能維度：對(duì)一個(gè)系統(tǒng)進(jìn)行功能再拆分
* 讀寫(xiě)維度：根據(jù)讀寫(xiě)比例特征進(jìn)行拆分
* AOP維度：根據(jù)訪問(wèn)特征，按照AOP進(jìn)行拆分
* 模塊維度：按照基礎(chǔ)或者代碼維護(hù)特征進(jìn)行拆分
3.服務(wù)化
* 判斷是不是只需要簡(jiǎn)單的單點(diǎn)遠(yuǎn)程服務(wù)調(diào)用，單機(jī)不行集群是不是就可以解決？在客戶(hù)端注冊(cè)多臺(tái)機(jī)器并使用Nginx進(jìn)行負(fù)載均衡是不是就可以解決？隨著調(diào)用方越來(lái)越多，應(yīng)該考慮使用服務(wù)自動(dòng)注冊(cè)和發(fā)現(xiàn)（Dubbo使用ZooKeeper）
* 考慮服務(wù)的分組/隔離
* 后期隨著調(diào)用量的增加還要考慮服務(wù)的限流、黑白名單等
* 進(jìn)程內(nèi)服務(wù)->單機(jī)遠(yuǎn)程服務(wù)->集群手動(dòng)注冊(cè)服務(wù)->自動(dòng)注冊(cè)和發(fā)現(xiàn)服務(wù)->服務(wù)的分組/隔離/路由->服務(wù)治理如限流/黑白名單
4.消息隊(duì)列
* 用來(lái)解耦一些不需要同步調(diào)用的服務(wù)或者訂閱一些自己系統(tǒng)關(guān)心的變化
* 可以實(shí)現(xiàn)服務(wù)解耦（一對(duì)多消費(fèi)）、異步處理、流量削峰/緩沖等
* 要注意處理生產(chǎn)消息失敗，以及消息重復(fù)接收時(shí)的場(chǎng)景
* 大流量緩沖（電商大促等），犧牲強(qiáng)一致性，而保證最終一致性，需要考慮并發(fā)處理和重復(fù)處理的問(wèn)題
* 在使用了消息異步機(jī)制的場(chǎng)景下，可能存在消息的丟失，需要考慮進(jìn)行數(shù)據(jù)校對(duì)和修正來(lái)保證數(shù)據(jù)的一致性和完整性
5.數(shù)據(jù)異構(gòu)
* 對(duì)訂單表進(jìn)行異構(gòu)，異構(gòu)一套用戶(hù)訂單表，按照用戶(hù)ID進(jìn)行分庫(kù)分表，還需要考慮對(duì)歷史訂單數(shù)據(jù)進(jìn)行歸檔處理
* 數(shù)據(jù)閉環(huán)如商品詳情頁(yè)，通過(guò)如MQ機(jī)制接收數(shù)據(jù)變更，然后原子化存儲(chǔ)到合適的存儲(chǔ)引擎，如Redis或持久化KV存儲(chǔ)；使用數(shù)據(jù)聚合，前端就可以一個(gè)調(diào)用拿到所有數(shù)據(jù)，一般存儲(chǔ)在KV存儲(chǔ)中；前端通過(guò)一次或少量幾次調(diào)用拿到所需要的數(shù)據(jù)；
* 如果一次需要多個(gè)數(shù)據(jù)，可以考慮使用Hash Tag機(jī)制將相關(guān)的數(shù)據(jù)聚合到一個(gè)實(shí)例
6.緩存銀彈
* 瀏覽器緩存：設(shè)置請(qǐng)求過(guò)期時(shí)間，如對(duì)響應(yīng)頭Expires、Cache-control進(jìn)行控制，適用于對(duì)實(shí)時(shí)性不太敏感的數(shù)據(jù)
* APP客戶(hù)端緩存：一般會(huì)在大促之前把APP需要訪問(wèn)的一些素材提前下發(fā)到客戶(hù)端進(jìn)行緩存
* CDN緩存：將頁(yè)面、活動(dòng)頁(yè)、圖片推送到離用戶(hù)最近的CDN節(jié)點(diǎn)，要考慮URL的設(shè)計(jì)
* 接入層緩存：考慮使用如Nginx搭建一層接入層，URL重寫(xiě)、一致性哈希、proxy_cache、proxy_cache_lock、shared_dict
* 應(yīng)用層緩存：Redis等
* 分布式緩存：Redis集群
7.并發(fā)化
B.高可用原則
1.降級(jí)
* 開(kāi)關(guān)集中化管理：通過(guò)推送機(jī)制把開(kāi)關(guān)推送到各個(gè)應(yīng)用
* 可降級(jí)的多級(jí)讀服務(wù)：比如服務(wù)調(diào)用降級(jí)為只讀本地緩存、只讀分布式緩存、只讀默認(rèn)降級(jí)數(shù)據(jù)
* 開(kāi)關(guān)前置化：如架構(gòu)是Nginx->Tomcat，可以將開(kāi)關(guān)前置到Nginx接入層
* 業(yè)務(wù)降級(jí)：把一些同步調(diào)用改成異步調(diào)用，優(yōu)先處理高優(yōu)先級(jí)數(shù)據(jù)或特殊特征的數(shù)據(jù)
2.限流
* 惡意請(qǐng)求流量只訪問(wèn)到cache
* 對(duì)于穿透到后端應(yīng)用的流量可以考慮使用Nginx的limit模塊處理
* 對(duì)于惡意IP可以使用nginx deny進(jìn)行屏蔽
3.切流量
* DNS：切換機(jī)房入口
* HttpDNS：主要APP場(chǎng)景下，在客戶(hù)端分配好流量入口，繞過(guò)運(yùn)營(yíng)商LocalDNS并實(shí)現(xiàn)更精準(zhǔn)流量調(diào)度
* LVS/HaProxy：切換故障的Nginx接入層
4.可回滾：版本化
C.業(yè)務(wù)設(shè)計(jì)原則
1.防重設(shè)計(jì)：考慮防重key、防重表
2.冪等設(shè)計(jì)：在重復(fù)消息消費(fèi)時(shí)進(jìn)行冪等處理
3.流程可定義
4.狀態(tài)與狀態(tài)機(jī)：正向狀態(tài)（付款、發(fā)貨）和逆向狀態(tài)（取消、退款）應(yīng)該根據(jù)系統(tǒng)和特征來(lái)決定要不要分離存儲(chǔ)，狀態(tài)設(shè)計(jì)時(shí)應(yīng)有狀態(tài)軌跡，方便跟蹤當(dāng)前訂單的軌跡并記錄相關(guān)日志，還有訂單狀態(tài)的變遷以及并發(fā)狀態(tài)修改問(wèn)題
5.后臺(tái)系統(tǒng)操作可反饋：需要考慮效果的可預(yù)覽，可反饋
6.后臺(tái)系統(tǒng)審批化：對(duì)于有些重要的后臺(tái)功能需要設(shè)計(jì)審批流，并記錄日志，從而保證操作可追溯、可審計(jì)
7.文檔和注釋?zhuān)涸谝粋€(gè)系統(tǒng)發(fā)展的一開(kāi)始就應(yīng)該有文檔庫(kù)（設(shè)計(jì)架構(gòu)、設(shè)計(jì)思想、數(shù)據(jù)字典/業(yè)務(wù)流程、現(xiàn)有問(wèn)題），業(yè)務(wù)代碼和特殊需求都要有注釋
8.備份：代碼備份和人員備份
二、負(fù)載均衡與反向代理
1.外網(wǎng)DNS應(yīng)該用來(lái)實(shí)現(xiàn)用GSLB（全局負(fù)載均衡）進(jìn)行流量調(diào)度，如將用戶(hù)分配到離他最近的服務(wù)器上以提升體驗(yàn)
2.對(duì)于內(nèi)網(wǎng)DNS，可以實(shí)現(xiàn)簡(jiǎn)單的輪詢(xún)負(fù)載均衡，但會(huì)有一定的緩存時(shí)間并且沒(méi)有失敗重試機(jī)制，我們可以考慮選擇如HaProxy和Nginx
3.Nginx一用于七層負(fù)載，其吞吐量是有一定限制的，為了提升整體吞吐，會(huì)在DNS和Nginx之間引入接入層，如使用LVS、F5可以做四層負(fù)載均衡，即首先DNS解析到LVS/F5、然后LVS/F5轉(zhuǎn)發(fā)給Nginx，再由Nginx轉(zhuǎn)發(fā)給后端RealServer
4.Nginx目前提供了HTTP（ngx_http_upstreamm_module）七層負(fù)載均衡，1.9.0版本支持TCP（ngx_stream_upstream_module）四層負(fù)載均衡
5.二層負(fù)載均衡是通過(guò)改寫(xiě)報(bào)文的目標(biāo)MAC地址為上游服務(wù)器MAC地址，源IP地址和目標(biāo)IP地址是沒(méi)有變的，負(fù)載均衡服務(wù)器和真實(shí)服務(wù)器共享同一個(gè)VIP，如LVS DR工作模式
6.四層負(fù)載均衡是根據(jù)端口將報(bào)文轉(zhuǎn)發(fā)到上游服務(wù)器（不同的IP地址+端口），如LVS NAT模式、HaProxy
7.七層負(fù)載均衡是根據(jù)端口號(hào)和應(yīng)用層協(xié)議如HTTP協(xié)議的主機(jī)名、URL，轉(zhuǎn)發(fā)報(bào)文到上游服務(wù)器（不同的IP地址+端口），如HaProxy、Nginx
A.upstream配置
1.在http指令下配置upstream即可
2.主要配置：
* IP地址和端口
* 權(quán)重：默認(rèn)是1，越高分配給這臺(tái)服務(wù)器的請(qǐng)求就越多
B.負(fù)載均衡算法
1.用來(lái)解決用戶(hù)請(qǐng)求到來(lái)時(shí)如何選擇upstream server進(jìn)行處理，默認(rèn)采用的是round-robin(輪詢(xún))，同時(shí)支持ip_hash
2.hash key [consistent]，對(duì)某個(gè)key進(jìn)行哈?；蛘呤褂靡恢滦怨Ｋ惴ㄟM(jìn)行負(fù)載均衡，建議考慮使用一致性哈希算法
3.least_conn，將請(qǐng)求均衡到最少活躍連接的上游服務(wù)器
C.失敗重試
1.主要兩部分配置：
* upstream server：server xxxx:80 max_fails=2 fail_timeout=10s weight=1;...
* proxy_pass：配置proxy_next_upstream相關(guān)配置，proxy_next_upstream、proxy_next_upstream_timeout、proxy_next_upstream_tries
D.健康檢查
1.nginx對(duì)上游服務(wù)器的健康檢查默認(rèn)采用的是惰性策略
2.TCP心跳檢查：check interval=3000 rise=1 fall=3 timeout=2000 type=tcp;
3.HTTP心跳檢查：
* check_http_send "HEAD /status HTTP/1.0\r\n\r\n";
* check_http_expect_alive http_2xx http_3xx;
3.使用的是opensresty模塊，安裝nginx之前需要先打nginx_upstream_check_module補(bǔ)丁
E.其他配置
1.備份上游服務(wù)器，backup
2.不可用上游服務(wù)器，down
F.長(zhǎng)連接
1.可以通過(guò)keepalive指令配置長(zhǎng)連接數(shù)量
G.HTTP反向代理
1.反向代理除了實(shí)現(xiàn)負(fù)載均衡之外，還提供如緩存來(lái)減少上游服務(wù)器的壓力
2.還可以開(kāi)啟gzip壓縮，減少網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)包大小
H.HTTP動(dòng)態(tài)負(fù)載均衡
1.Consul是一款開(kāi)源的分布式服務(wù)注冊(cè)與發(fā)瑞系統(tǒng)，通過(guò)HTTP API可以使得服務(wù)注冊(cè)、發(fā)現(xiàn)實(shí)現(xiàn)起來(lái)非常簡(jiǎn)單
2.Consul+Consul-template
2.Consul+OpenResty
I.Nginx四層負(fù)載均衡
1.靜態(tài)負(fù)載均衡
* 啟用ngx_stream_core_module，安裝Nginx時(shí)，添加--with-stream
* 配置在stream指令下
* 可配置數(shù)據(jù)庫(kù)連接
2.動(dòng)態(tài)負(fù)載均衡
* nginx-upsync-module，提升了HTTP七層動(dòng)態(tài)負(fù)載均衡，動(dòng)態(tài)更新上游服務(wù)器不需要reload nginx
三、隔離術(shù)
1.隔離是指將系統(tǒng)或資源分割開(kāi)，系統(tǒng)隔離是為了在系統(tǒng)發(fā)生故障時(shí)，能限定傳播范圍和影響范圍，即發(fā)生故障后不會(huì)出現(xiàn)滾雪球效應(yīng)，從而保證只有出問(wèn)題的服務(wù)不可用，其他服務(wù)還是可用的
2.資源隔離通過(guò)隔離來(lái)減少資源競(jìng)爭(zhēng)，保障服務(wù)間的相互不影響和可用性
A.線程隔離
1.主要是指線程池隔離，在實(shí)際使用時(shí)，我們會(huì)把請(qǐng)求分類(lèi)，然后交給不同的線程池處理
B.進(jìn)程隔離
1.在公司發(fā)展初期，一般是先從零到一，不會(huì)一上來(lái)就進(jìn)行系統(tǒng)拆分，這樣就會(huì)開(kāi)發(fā)出一些大而全的系統(tǒng)，系統(tǒng)中的一個(gè)模塊/功能出現(xiàn)問(wèn)題，整個(gè)系統(tǒng)就不可用了
2.通過(guò)將系統(tǒng)拆分為多個(gè)子系統(tǒng)來(lái)實(shí)現(xiàn)物理隔離，通過(guò)進(jìn)程隔離使得某一個(gè)子系統(tǒng)出現(xiàn)問(wèn)題時(shí)不會(huì)影響到其他子系統(tǒng)
C.集群隔離
1.隨著系統(tǒng)的發(fā)展，單實(shí)例服務(wù)無(wú)法滿足需求，此時(shí)需要服務(wù)化技術(shù)，通過(guò)部署多個(gè)服務(wù)形成服務(wù)集群，來(lái)提升系統(tǒng)容量
D.機(jī)房隔離
1.隨著對(duì)系統(tǒng)可用性的要求，會(huì)進(jìn)行多機(jī)房部署，每個(gè)機(jī)房的服務(wù)都有自己的服務(wù)分組，本機(jī)房的服務(wù)應(yīng)該只調(diào)用本機(jī)房服務(wù)，不進(jìn)行跨機(jī)房調(diào)用
2.當(dāng)一個(gè)機(jī)房服務(wù)發(fā)生問(wèn)題時(shí)，可以通過(guò)DNS/負(fù)載均衡將請(qǐng)求全部切到另一個(gè)機(jī)房，或者考慮服務(wù)能自動(dòng)重試其他機(jī)房的服務(wù)
3.一種辦法是根據(jù)IP（不同機(jī)房IP段不一樣）自動(dòng)分組，還有一種較靈活的辦是通過(guò)在分組名中加上機(jī)房名
E.讀寫(xiě)隔離
1.通過(guò)主從模式將讀和寫(xiě)集群分離
F.動(dòng)靜隔離
1.將動(dòng)態(tài)內(nèi)容和靜態(tài)資源分離，將靜態(tài)資源放在CDN上
G.爬蟲(chóng)隔離
1.爬蟲(chóng)和正常流量的比例能達(dá)到5:1，甚至更高，一種解決辦法是通過(guò)限流解決，另一種解決辦法是在負(fù)載均衡層面將爬蟲(chóng)路由到單獨(dú)集群，Nginx即可配置
2.使用OpenResty，不僅對(duì)爬蟲(chóng)user-agent過(guò)濾，還會(huì)過(guò)濾一些惡意IP ，可以考慮IP+Cookie的方式
H.資源隔離
1.最常見(jiàn)的資源，如磁盤(pán)、CPU、網(wǎng)絡(luò)，這些寶貴的資源，都會(huì)存在競(jìng)爭(zhēng)問(wèn)題
I.使用Hystrix實(shí)現(xiàn)隔離
1.Hystrix是Netflix開(kāi)源的一款針對(duì)分布式系統(tǒng)的延遲和容錯(cuò)庫(kù)，目的是用來(lái)隔離分布式服務(wù)故障
2.提供線程和信號(hào)量隔離，以減少不同服務(wù)之間資源競(jìng)爭(zhēng)帶來(lái)的相互影響：提供優(yōu)雅降級(jí)機(jī)制；提供熔斷機(jī)制使得服務(wù)可以快速失敗，而不是一直阻塞等待服務(wù)響應(yīng)，并能從中快速恢復(fù)
3.解決的問(wèn)題：
* 限制調(diào)用分布式服務(wù)的資源使用，某一個(gè)調(diào)用的服務(wù)出現(xiàn)問(wèn)題不會(huì)影響其他服務(wù)調(diào)用，通過(guò)線程池隔離和信號(hào)量隔離實(shí)現(xiàn)
* 提供了優(yōu)雅降級(jí)機(jī)制：超時(shí)降級(jí)、資源不足時(shí)（線程或信號(hào)量）降級(jí)，降級(jí)后可以配合降級(jí)接口返回拖底數(shù)據(jù)
* 提供了熔斷器實(shí)現(xiàn)，當(dāng)失敗率達(dá)到閾值自動(dòng)觸發(fā)降級(jí)（如因網(wǎng)絡(luò)故障/超時(shí)造成的失敗率高），熔斷器觸發(fā)的快速失敗會(huì)進(jìn)行快速恢復(fù)
* 提供了請(qǐng)求緩存、請(qǐng)求合并實(shí)現(xiàn)
J.基于Servlet3實(shí)現(xiàn)請(qǐng)求隔離
四、限流詳解
1.限流的目的是通過(guò)對(duì)并發(fā)訪問(wèn)/請(qǐng)求進(jìn)行限速或者一個(gè)時(shí)間窗口內(nèi)的請(qǐng)求進(jìn)行限速來(lái)保護(hù)系統(tǒng)，一旦達(dá)到限制速率則可以拒絕服務(wù)（定向到錯(cuò)誤頁(yè)或告知資源沒(méi)有了）、排隊(duì)或等待（比如秒殺、評(píng)論、下單）、降級(jí)（返回兜底數(shù)據(jù)或默認(rèn)數(shù)據(jù)）
2.在壓測(cè)時(shí)我們能找出每個(gè)系統(tǒng)的處理峰值，然后通過(guò)設(shè)定峰值閾值，來(lái)防止系統(tǒng)過(guò)載時(shí)，通過(guò)拒絕處理過(guò)載的請(qǐng)求來(lái)保障系統(tǒng)可用，另外，也應(yīng)根據(jù)系統(tǒng)的吞吐量、響應(yīng)時(shí)間、可用率來(lái)動(dòng)態(tài)調(diào)整限流閾值
3.常見(jiàn)的限流有
限制總并發(fā)數(shù)（比如數(shù)據(jù)庫(kù)連接池、線程池）
限制瞬時(shí)并發(fā)數(shù)（如Nginx的limit_conn模塊）
限制時(shí)間窗口內(nèi)的平均速率（如Guava的RateLimiter、Nginx的limit_req模塊，用來(lái)限制每秒的平均速率）
限制遠(yuǎn)程接口調(diào)用速率
限制MQ的消費(fèi)速率
還可以根據(jù)網(wǎng)絡(luò)連接數(shù)、網(wǎng)絡(luò)流量、CPU或內(nèi)存負(fù)載來(lái)限流
4.緩存目的是提升系統(tǒng)訪問(wèn)速度和增大系統(tǒng)處理能力，可謂是抗高并發(fā)的銀彈。降級(jí)是當(dāng)服務(wù)出問(wèn)題或者影響到核心流程的性能，需要暫時(shí)屏蔽掉，待高峰過(guò)去或者問(wèn)題解決后再打開(kāi)的場(chǎng)景
A.限流算法
1.令牌桶算法：是一個(gè)存放固定容量令牌的桶，按照固定速率往桶里添加令牌
2.漏桶算法：漏桶作為計(jì)量工具（The Leaky Bucket Algorithm as a Meter）時(shí)，可以用于流量整形（Traffic Shaping）和流量控制（Traffic Policing）
B.應(yīng)用級(jí)限流
1.限流總資源數(shù)：可以使用池化技術(shù)，如連接池、線程池
2.限流總并發(fā)/連接/請(qǐng)求數(shù)：Tomcat配置、MySQL（max_connections）、Redis（tcp-backlog）
3.限流某個(gè)接口的總并發(fā)/請(qǐng)求數(shù)：Java的AtomicLong或Semaphore
C.分布式限流
1.Redis+Lua
2.Nginx+Lua
D.接入層限流
1.接入層通常指請(qǐng)求流量的入口，該層的主要目的有：負(fù)載均衡、非法請(qǐng)求過(guò)濾、請(qǐng)求聚合、緩存、降級(jí)、限流、A/B測(cè)試、服務(wù)質(zhì)量監(jiān)控等
2.ngx_http_limit_conn_module，limit_conn是對(duì)某個(gè)key對(duì)應(yīng)的總的網(wǎng)絡(luò)連接數(shù)進(jìn)行限流，可以按照IP來(lái)限制IP維度的總連接數(shù)，或者按照服務(wù)域名來(lái)限制某個(gè)域名的總連接數(shù)，只有被Nginx處理的且已經(jīng)讀取了整個(gè)請(qǐng)求頭的請(qǐng)求連接才會(huì)被計(jì)數(shù)器統(tǒng)計(jì)
3.ngx_http_limit_req_module，limit_req是漏桶算法實(shí)現(xiàn)，用于對(duì)指定key對(duì)應(yīng)的請(qǐng)求進(jìn)行限流，比如按照IP維度限制請(qǐng)求速率
4.lua-resty-limit-traffic，OpenResty了Lua限流模塊，可以按照更復(fù)雜的業(yè)務(wù)邏輯進(jìn)行動(dòng)態(tài)限流處理，提供了limit.conn和limit.req實(shí)現(xiàn)
E.節(jié)流
1.我們想在特定埋單窗口內(nèi)對(duì)重復(fù)的相同事件最多只處理一次，或者想限制多個(gè)連續(xù)相同事件最小執(zhí)行時(shí)間間隔，可使用節(jié)流（Throttle）實(shí)現(xiàn)，其防止多個(gè)相同事件連續(xù)重復(fù)執(zhí)行，主要有：throttleFirst、throttleLast、throttleWithTimeout
2.throttleFirst/throttleLast
* 是指在一個(gè)時(shí)間窗口內(nèi)，如果有重復(fù)的多個(gè)相同事件要處理，則只處理第一個(gè)或最后一個(gè)，其相當(dāng)于一個(gè)事件頻率控制器，把一段時(shí)間內(nèi)重復(fù)的多個(gè)相同事件變?yōu)橐粋€(gè)，減少事件處理頻頻率，從而減少無(wú)用處理
* 前端開(kāi)發(fā)可以使用jquery-throttle-debounce-plugin實(shí)現(xiàn)
* Android開(kāi)發(fā)可以使用RxAndroid實(shí)現(xiàn)
3.throttleWithTimeout
* 也叫作debounce（去抖），限制兩個(gè)連續(xù)事件的先后執(zhí)行時(shí)間不得小于某個(gè)時(shí)間窗口
* 當(dāng)兩個(gè)連續(xù)事件的時(shí)間間隔小于最小間隔時(shí)間窗口，就會(huì)丟棄上一個(gè)事件，而如果最后一個(gè)事件等待了最小間隔時(shí)間窗口后還沒(méi)有新的事件到來(lái)，那么會(huì)處理最后一個(gè)事件
* 可用于搜索關(guān)鍵詞自動(dòng)補(bǔ)全等功能
五、降級(jí)特技
1.當(dāng)訪問(wèn)量劇增、服務(wù)出現(xiàn)問(wèn)題（如響應(yīng)時(shí)間長(zhǎng)或不響應(yīng)）或非核心服務(wù)影響到核心流程的性能時(shí)，仍然需要保證服務(wù)還是可用的，即使是有損服務(wù)。系統(tǒng)可以根據(jù)一些關(guān)鍵數(shù)據(jù)進(jìn)行自動(dòng)降級(jí)，也可以配置開(kāi)關(guān)實(shí)現(xiàn)人工降級(jí)
2.降級(jí)的最終目的是保證核心服務(wù)可用，即使是有損的。而且有些服務(wù)是無(wú)法降級(jí)的（如購(gòu)物車(chē)、結(jié)算）。降級(jí)也需要根據(jù)系統(tǒng)的吞吐量、響應(yīng)時(shí)間、可用率等條件進(jìn)行手工降級(jí)或自動(dòng)降級(jí)
A.降級(jí)預(yù)案
1.參考日志級(jí)別設(shè)置預(yù)案
* 一般：有些服務(wù)偶爾因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或者服務(wù)正在上線而超時(shí)，可以自動(dòng)降級(jí)
* 警告：有些服務(wù)在一段時(shí)間內(nèi)成功率有波動(dòng)，可以自動(dòng)降級(jí)或人工降級(jí)并發(fā)送警告
* 錯(cuò)誤：可用率低于90%，或數(shù)據(jù)庫(kù)連接池用完了，或訪問(wèn)量突然猛增到系統(tǒng)能承受的最大閾值
* 嚴(yán)重錯(cuò)誤：因?yàn)樘厥庠驍?shù)據(jù)出現(xiàn)錯(cuò)誤，需要緊急人工降級(jí)
2.降級(jí)按照是否自動(dòng)化可分為：自動(dòng)開(kāi)關(guān)降級(jí)和人工開(kāi)關(guān)降級(jí)
3.降級(jí)按照功能可分為：讀服務(wù)降級(jí)和寫(xiě)服務(wù)降級(jí)
4.降級(jí)按照處于系統(tǒng)層次可分為：多級(jí)降級(jí)
5.降級(jí)的功能點(diǎn)主要從服務(wù)器端鏈路考慮，即根據(jù)用戶(hù)訪問(wèn)的服務(wù)調(diào)用鏈路來(lái)梳理哪里需要降級(jí)
* 頁(yè)面降級(jí)
* 頁(yè)面片段降級(jí)
* 頁(yè)面異步請(qǐng)求降級(jí)
* 服務(wù)功能降級(jí)
* 讀降級(jí)：如多級(jí)緩存模式，如果后端服務(wù)有問(wèn)題，則可以降級(jí)為只讀緩存，適用于對(duì)讀一致性要求不高的場(chǎng)景
* 寫(xiě)降級(jí)：秒殺搶購(gòu)，可以只進(jìn)行Cache的更新，然后異步扣減庫(kù)存到DB，保證最終一致性即可，此時(shí)可以將DB降級(jí)為Cache
* 爬蟲(chóng)降級(jí)：大促活動(dòng)時(shí)，可以將爬蟲(chóng)流量導(dǎo)向靜態(tài)頁(yè)或者返回空數(shù)據(jù)，從而保護(hù)后端稀缺資源
* 風(fēng)控降級(jí)：搶購(gòu)/秒殺等業(yè)務(wù)，完全可以識(shí)別機(jī)器人、用戶(hù)畫(huà)像或者根據(jù)用戶(hù)風(fēng)控級(jí)別進(jìn)行降級(jí)處理，直接拒絕高風(fēng)險(xiǎn)用戶(hù)
B.自動(dòng)開(kāi)關(guān)降級(jí)
1.超時(shí)降級(jí)
* 當(dāng)訪問(wèn)的數(shù)據(jù)庫(kù)/HTTP服務(wù)/遠(yuǎn)程調(diào)用響應(yīng)慢或者長(zhǎng)時(shí)間響應(yīng)慢，且該服務(wù)不是核心服務(wù)的話，可以在超時(shí)后自動(dòng)降級(jí)
* 如果是調(diào)用別人的遠(yuǎn)程服務(wù)，則可以和對(duì)方定義一個(gè)服務(wù)響應(yīng)最大時(shí)間，如果超時(shí)了，則自動(dòng)降級(jí)
* 在實(shí)際場(chǎng)景中一定要配置好超時(shí)時(shí)間和超時(shí)重試次數(shù)及機(jī)制
2.統(tǒng)計(jì)失敗次數(shù)降級(jí)：當(dāng)失敗調(diào)用次數(shù)達(dá)到一定閾值自動(dòng)降級(jí)（熔斷器），然后通過(guò)異步線程去探測(cè)服務(wù)是否恢復(fù)了
3.故障降級(jí)：要調(diào)用的遠(yuǎn)程服務(wù)掛掉了，則可以直接降級(jí)，降級(jí)后的處理方案：默認(rèn)值（比如庫(kù)存掛了返回默認(rèn)） 、兜底數(shù)據(jù)（比如廣告掛了返回提前準(zhǔn)備好的靜態(tài)頁(yè)面）、緩存
4.限流降級(jí)：當(dāng)達(dá)到限流閾值時(shí)，后續(xù)請(qǐng)求會(huì)被降級(jí)，降級(jí)后的處理方案：排隊(duì)頁(yè)面、無(wú)貨、錯(cuò)誤頁(yè)
C.人工開(kāi)關(guān)降級(jí)
1.開(kāi)關(guān)可以存放到配置文件、數(shù)據(jù)庫(kù)、Redis/ZooKeeper，可以定期同步開(kāi)關(guān)數(shù)據(jù)，然后通過(guò)判斷某個(gè)KEY的值來(lái)決定是否降級(jí)
2.對(duì)于新開(kāi)發(fā)的服務(wù)進(jìn)行灰度測(cè)試，就需要設(shè)置開(kāi)關(guān)，還有多機(jī)房服務(wù)，也可以通過(guò)開(kāi)關(guān)完成
3.還有一引起是因?yàn)楣δ軉?wèn)題需要暫時(shí)屏蔽掉某些功能
D.讀服務(wù)降級(jí)
1.一般采取的策略有：暫時(shí)切換讀（降級(jí)到讀緩存、降級(jí)走靜態(tài)化）、暫時(shí)屏蔽讀（屏蔽讀入口、屏蔽某個(gè)讀服務(wù)）
2.我們會(huì)在接入層、應(yīng)用層設(shè)置開(kāi)關(guān)，當(dāng)分布式緩存、RPC服務(wù)/DB有問(wèn)題時(shí)自動(dòng)降級(jí)為不調(diào)用，適用于讀一致性要求不高的場(chǎng)景
3.頁(yè)面降級(jí)、頁(yè)面片段降級(jí)、頁(yè)面異步請(qǐng)求降級(jí)都是讀服務(wù)降級(jí)，目的是丟卒保帥
4.動(dòng)態(tài)化降級(jí)為靜態(tài)化
5.靜態(tài)化降級(jí)為動(dòng)態(tài)化
E.寫(xiě)服務(wù)降級(jí)
1.大多數(shù)場(chǎng)景下是不可降級(jí)的，不過(guò)可以：將同步操作轉(zhuǎn)換為異步操作、限制寫(xiě)的量/比例（如評(píng)論開(kāi)關(guān)量大時(shí)不可見(jiàn)）
F.多級(jí)降級(jí)
1.降級(jí)是離用戶(hù)走越近越對(duì)系統(tǒng)保護(hù)得好，因?yàn)闃I(yè)務(wù)的復(fù)雜性導(dǎo)致越到后端QPS/TPS越低
* 頁(yè)面JS降級(jí)開(kāi)關(guān)：控制頁(yè)面功能降級(jí)
* 接入層降級(jí)開(kāi)關(guān)：控制請(qǐng)求入口的降級(jí)
* 應(yīng)用層降級(jí)開(kāi)關(guān)：控制業(yè)務(wù)的降級(jí)
G.配置中心
1.應(yīng)用層API封裝
2.使用配置文件實(shí)現(xiàn)開(kāi)關(guān)配置
3.使用配置中心實(shí)現(xiàn)開(kāi)關(guān)配置：ZooKeeper、Diamond、Disconf、Etcd 3、Consul
H.使用Hystrix實(shí)現(xiàn)降級(jí)
I.使用Hystrix實(shí)現(xiàn)熔斷
六、超時(shí)與重試機(jī)制
A.簡(jiǎn)介
1.如果應(yīng)用不設(shè)置超時(shí)，則可能會(huì)導(dǎo)致請(qǐng)求響應(yīng)慢，慢請(qǐng)求累積導(dǎo)致連鎖反應(yīng)，甚至造成應(yīng)用雪崩
2.讀服務(wù)天然適合重試，而寫(xiě)服務(wù)大多不能重試（如果寫(xiě)服務(wù)是冪等的，則重試是允許的），重試次數(shù)太多會(huì)導(dǎo)致多倍請(qǐng)求流量
3.在進(jìn)行代碼Review時(shí)，一定記得Review超時(shí)與重試機(jī)制
4.超時(shí)與重試機(jī)制：
* 代理層超時(shí)與重試
* Web容器超時(shí)
* 中間件客戶(hù)端超時(shí)與重試
* 數(shù)據(jù)庫(kù)客戶(hù)端超時(shí)
* NoSQL客戶(hù)端超時(shí)
* 業(yè)務(wù)超時(shí)
* 前端Ajax超時(shí)
B.代理層超時(shí)與重試
1.Nginx
* client_header_timeout time：設(shè)置讀取客戶(hù)端請(qǐng)求頭超時(shí)時(shí)間，默認(rèn)為60s，響應(yīng)408，如果在些超時(shí)時(shí)間內(nèi)客戶(hù)端沒(méi)有發(fā)送完請(qǐng)求頭
* client_body_timeout time：設(shè)置讀取客戶(hù)端內(nèi)容體超時(shí)時(shí)間，默認(rèn)為60s，響應(yīng)408，兩次成功讀操作間隔時(shí)間，而不是發(fā)送整個(gè)請(qǐng)求體超時(shí)時(shí)間
* send_timeout_time：設(shè)置發(fā)送響應(yīng)到客戶(hù)端的超時(shí)時(shí)間，默認(rèn)60s，兩次成功寫(xiě)操作間隔時(shí)間，而不是發(fā)送整個(gè)響應(yīng)的超時(shí)時(shí)間
* keepalive_timeout timeout [header_timeout]：設(shè)置HTTP長(zhǎng)連接超時(shí)時(shí)間，要配合keepalive_disable和keepalive_requests一起使用
2.DNS解析超時(shí)設(shè)置
* resolver_timeout 30s：設(shè)置DNS解析超時(shí)時(shí)間，默認(rèn)30s，配合resolver address ... [valid=time]進(jìn)行DNS域名解析
3.代理超時(shí)設(shè)置
* proxy_connect_timeout time：與后端/上游服務(wù)器建立連接的超時(shí)時(shí)間
* proxy_read_timeout time：設(shè)置從后端/上游服務(wù)器讀取響應(yīng)的超時(shí)時(shí)間
* proxy_send_timeout time：設(shè)置往后端/上游服務(wù)器發(fā)送請(qǐng)求的超時(shí)時(shí)間
* proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | non_idempotent | off ...：配置什么情況下需要請(qǐng)求下一臺(tái)上游服務(wù)器進(jìn)行重試ZXCV
* proxy_next_upstream_tries number：設(shè)置重試次數(shù)，指所有請(qǐng)求次數(shù)，默認(rèn)0表示不限制
* proxy_next_upstream_timeout time：設(shè)置重試最大超時(shí)時(shí)間，默認(rèn)0表示不限制
* upstream存活超時(shí)，max_fails和fail_timeout：配置什么時(shí)候Nginx將上游服務(wù)器認(rèn)定為不可用/不存活
4.Twemproxy：Twitter開(kāi)源的Redis和Memcache代理中間件，減少與后端緩存服務(wù)器的連接數(shù)
C.Web容器超時(shí)
D.中間件客戶(hù)端超時(shí)與重試
1.JSF是京東自研的SOA框架，主要有三個(gè)組件：注冊(cè)中心、服務(wù)提供端、服務(wù)消費(fèi)端
2.JMQ是京東消息中間件，主要有四個(gè)組件：注冊(cè)中心、Broker（JMQ的服務(wù)器端實(shí)例，生產(chǎn)和消費(fèi)消息都跟它交互）、生產(chǎn)者、消費(fèi)者
E.數(shù)據(jù)庫(kù)客戶(hù)端超時(shí)
F.NoSQL客戶(hù)端超時(shí)
G.業(yè)務(wù)超時(shí)
1.任務(wù)型：可以通過(guò)Worker定期掃描數(shù)據(jù)庫(kù)修改狀態(tài)，有時(shí)需要遠(yuǎn)程服務(wù)超時(shí)了，可以考慮使用隊(duì)列或者暫時(shí)記錄到本地稍后重試
2.服務(wù)調(diào)用型：可以簡(jiǎn)單地使用Futrue來(lái)解決問(wèn)題（Java）
H.前端Ajax超時(shí)
1.可以在請(qǐng)求時(shí)帶上timeout參數(shù)
2.使用setTimeout進(jìn)行超時(shí)重試
七、回滾機(jī)制
A.事務(wù)回滾
1.對(duì)于單庫(kù)事務(wù)回滾直接使用相關(guān)SQL即可
2.分布式事務(wù)常見(jiàn)的如兩階段提交、三階段提交協(xié)議，可以考慮事務(wù)表、消息隊(duì)列、補(bǔ)償機(jī)制（執(zhí)行/回滾）、TCC模式（預(yù)占/確認(rèn)/取消）、Sagas模式（拆分事務(wù)+補(bǔ)償機(jī)制）等實(shí)現(xiàn)最終一致性
B.代碼庫(kù)回滾
1.SVN、Git等
C.部署版本回滾
1.部署版本化：發(fā)布時(shí)采用全量發(fā)布，避免增量發(fā)布
2.小版本增量發(fā)布：先發(fā)布1臺(tái)驗(yàn)證，沒(méi)問(wèn)題發(fā)布10臺(tái)，最后全部發(fā)布
3.大版本灰度發(fā)布：兩個(gè)版本并行跑一段時(shí)間
4.架構(gòu)升級(jí)并發(fā)發(fā)布：通過(guò)A/B方式慢慢地將流量引入到新版本集群，如果新版本出現(xiàn)大面積故障，降級(jí)回老版本
D.數(shù)據(jù)版本回滾
1.兩種思路：全量和增量
* 全量版本化是指即使只變更了其中一個(gè)字段也將整體記錄進(jìn)行歷史版本化
* 增量版本化是只保存變化的字段
八、壓測(cè)與預(yù)案
A.系統(tǒng)壓測(cè)
1.壓測(cè)一般指性能壓力測(cè)試，用來(lái)評(píng)估系統(tǒng)的穩(wěn)定性和性能，從而決定是否需要擴(kuò)容或縮容
2.壓測(cè)之前要有壓測(cè)方案【如壓測(cè)接口、并發(fā)量、壓測(cè)策略（突發(fā)、逐步加壓、并發(fā)量）、壓測(cè)指標(biāo)（機(jī)器）】，之后要產(chǎn)出壓測(cè)報(bào)告【壓測(cè)方案、機(jī)器負(fù)載、QPS/TPS、響應(yīng)時(shí)間（平均、最小、最大）、成功率、相關(guān)參數(shù)（JVM參數(shù)、壓縮參數(shù)）】，最后根據(jù)壓測(cè)報(bào)告分析的結(jié)果進(jìn)行系統(tǒng)優(yōu)化和容災(zāi)
3.線下壓測(cè)：通過(guò)如JMeter、Apache ab壓測(cè)系統(tǒng)的某個(gè)接口或者某個(gè)組件
4.線上壓測(cè)：按讀寫(xiě)分為讀壓測(cè)、寫(xiě)壓測(cè)和混合壓測(cè)，按數(shù)據(jù)仿真度分為仿真壓測(cè)和引流壓測(cè)，按是否給用戶(hù)提供服務(wù)分為隔離集群壓測(cè)和線上集群壓測(cè)
5.讀壓測(cè)是壓測(cè)系統(tǒng)的讀流量，寫(xiě)壓測(cè)是辱沒(méi)系統(tǒng)的寫(xiě)流量，讀和寫(xiě)是會(huì)相互影響 的，因此，這種情況下要進(jìn)行混合壓測(cè)
6.仿真壓測(cè)是通過(guò)模擬請(qǐng)求進(jìn)行系統(tǒng)壓測(cè)，數(shù)據(jù)可以是使用程序構(gòu)造、人工構(gòu)造，或者使用Nginx訪問(wèn)日志
7.隔離集群壓測(cè)是指將對(duì)外提供服務(wù)的部分服務(wù)器從線上集群摘除，然后將線上流量引流到該集群進(jìn)行壓測(cè)，這種方式很安全
8.單機(jī)壓測(cè)是指對(duì)集群中的一臺(tái)機(jī)器進(jìn)行壓測(cè)，從而評(píng)估出單機(jī)極限處理能力，發(fā)現(xiàn)單機(jī)的瓶頸點(diǎn)，這樣可以把單機(jī)性能優(yōu)化到極致
9.離散壓測(cè)，即選擇的數(shù)據(jù)應(yīng)該是分散的或者長(zhǎng)尾的
10.全鏈路壓測(cè)
B.系統(tǒng)優(yōu)化和容災(zāi)
1.拿到壓測(cè)報(bào)告 后，接下來(lái)會(huì)分析報(bào)告，然后進(jìn)行一些有針對(duì)性的優(yōu)化，如硬件升級(jí)、系統(tǒng)擴(kuò)容、參數(shù)調(diào)優(yōu)、代碼優(yōu)化、架構(gòu)優(yōu)化
2.在進(jìn)行系統(tǒng)優(yōu)化時(shí)，要進(jìn)行代碼走查，發(fā)現(xiàn)不合理的參數(shù)配置，如超時(shí)時(shí)間、降級(jí)策略、緩存時(shí)間等，在系統(tǒng)壓測(cè)中進(jìn)行慢查詢(xún)排查，包括Redis、MySQL等，通過(guò)優(yōu)化查詢(xún)解決慢查詢(xún)問(wèn)題
3.在應(yīng)用系統(tǒng)擴(kuò)容方面，可以根據(jù)去年流量、與運(yùn)營(yíng)業(yè)務(wù)方溝通促銷(xiāo)力度、最近一段時(shí)間的流量來(lái)評(píng)估出是否需要進(jìn)行擴(kuò)容，需要擴(kuò)容多少倍
4.在擴(kuò)容時(shí)要考慮系統(tǒng)容災(zāi)，比如分組部署、跨機(jī)房部署，容災(zāi)是通過(guò)部署多組（單機(jī)房/多機(jī)房）相同應(yīng)用系統(tǒng)，當(dāng)其中一組出現(xiàn)問(wèn)題時(shí)，可以切換到另一個(gè)分組
C.應(yīng)急預(yù)案
1.系統(tǒng)分級(jí)：可以按照交易核心系統(tǒng)和交易支撐系統(tǒng)進(jìn)行劃分
2.針對(duì)核心系統(tǒng)進(jìn)行全鏈路分析，從用戶(hù)入口到后端存儲(chǔ)，梳理出各個(gè)關(guān)鍵路徑，對(duì)相關(guān)路徑進(jìn)行評(píng)估并制定預(yù)案
* 網(wǎng)絡(luò)接入層：由系統(tǒng)工程師負(fù)責(zé)，關(guān)注機(jī)房不可用、DNS故障、VIP故障等預(yù)案處理
* 應(yīng)用接入層：由開(kāi)發(fā)工程師負(fù)責(zé)，關(guān)注上游應(yīng)用路由切換、限流、降級(jí)、隔離等預(yù)案處理
* Web應(yīng)用層和服務(wù)層：由開(kāi)發(fā)工程師負(fù)責(zé)，關(guān)注依賴(lài)服務(wù)的路由切換、連接池（數(shù)據(jù)庫(kù)、線程池等）異常、限流、超時(shí)降級(jí)、服務(wù)異常降級(jí)、應(yīng)用負(fù)載異常、數(shù)據(jù)庫(kù)故障切換、緩存故障切換等
* 數(shù)據(jù)層：由開(kāi)發(fā)工程師或系統(tǒng)工程師負(fù)責(zé)，關(guān)注數(shù)據(jù)庫(kù)/緩存負(fù)載高、數(shù)據(jù)庫(kù)/緩存故障等
3.制定好預(yù)案后，應(yīng)對(duì)預(yù)案進(jìn)行演習(xí)，來(lái)驗(yàn)證預(yù)案的正確性，在制定預(yù)案時(shí)也要設(shè)定故障的恢復(fù)時(shí)間
4.要對(duì)關(guān)聯(lián)路徑實(shí)施監(jiān)控報(bào)警，包括服務(wù)器監(jiān)控（CPU使用率、磁盤(pán)使用每戶(hù)、網(wǎng)絡(luò)帶寬等）、系統(tǒng)監(jiān)控（系統(tǒng)存活、URL狀態(tài)/內(nèi)容監(jiān)控、端口存活等）、JVM監(jiān)控（堆內(nèi)存、GC次數(shù)、線程數(shù)等）、接口監(jiān)控【接口調(diào)用量（每秒/每分鐘）、接口性能（TOP50/TOP99/TOP999）、接口可用率等】，然后配置報(bào)警策略如監(jiān)控時(shí)間段、報(bào)警閾值、通知方式
聯(lián)系客服
