在互聯(lián)網(wǎng)大行其道的今天妓雾，各種分布式系統(tǒng)已經(jīng)司空見(jiàn)慣垒迂。搜索引擎机断、電商網(wǎng)站绣夺、微博欢揖、微信、O2O平臺(tái)物臂。产上。凡是涉及到大規(guī)模用戶晋涣、高并發(fā)訪問(wèn)的，無(wú)一不是分布式算吩。
關(guān)于分布式系統(tǒng)佃扼，并沒(méi)有一個(gè)標(biāo)準(zhǔn)答案，說(shuō)某某架構(gòu)一定是最好的压昼。不同的業(yè)務(wù)形態(tài)所面對(duì)的挑戰(zhàn)不一樣瘤运，使用的架構(gòu)設(shè)計(jì)也不一樣拯坟，通常都需要具體業(yè)務(wù)具體分析。
但不管那種業(yè)務(wù)冷溃，不管何種分布式系統(tǒng)梦裂，有一些基本的思想還是相通的塞琼。本文將對(duì)這些基本思想進(jìn)行一個(gè)梳理匯總。
分拆
系統(tǒng)分拆
微信的架構(gòu)師說(shuō)過(guò)一句話：“大系統(tǒng)小做“毅往。對(duì)于一個(gè)大的復(fù)雜系統(tǒng)，首先想到的就是對(duì)其分拆洁桌，拆成多個(gè)子系統(tǒng)侯嘀。每個(gè)子系統(tǒng)自己的存儲(chǔ)/Service/接口層戒幔，各個(gè)子系統(tǒng)獨(dú)立開(kāi)發(fā)、測(cè)試工坊、部署敢订、運(yùn)維楚午。
從團(tuán)隊(duì)管理角度講，也可以不同團(tuán)隊(duì)用自己熟悉的語(yǔ)言體系阱驾，團(tuán)隊(duì)之間基于接口進(jìn)行協(xié)作把沼，職責(zé)清晰吁伺，各司其職篮奄。
子系統(tǒng)分拆
拆成子系統(tǒng)之后，子系統(tǒng)內(nèi)部又可以分層昼丑，分模塊夸赫。當(dāng)然，這里“系統(tǒng)“呼奢，“子系統(tǒng)“握础，“層“，“模塊“ 都只是一個(gè)相對(duì)概念简烘。在一個(gè)系統(tǒng)里面定枷，某個(gè)模塊復(fù)雜到一定程度，會(huì)把它抽出來(lái)亥至，單獨(dú)做成一個(gè)系統(tǒng)贱迟；而在初期衣吠，很大簡(jiǎn)單模塊，可能不回拆分惊搏，集中在一個(gè)系統(tǒng)里面忧换。
這就像一個(gè)生物組織亚茬，自身是在不斷成長(zhǎng)、演化碗暗、有分有合梢夯，不斷變化發(fā)展的颂砸。
存儲(chǔ)分拆
Nosql：對(duì)于Nosql數(shù)據(jù)庫(kù)死姚，比如MongoDB勤篮，其天生就是分布式的叙谨，很容易實(shí)現(xiàn)數(shù)據(jù)的分片。
Mysql: 對(duì)于Mysql涤垫，或者其它關(guān)系型數(shù)據(jù)庫(kù)竟终，就會(huì)設(shè)計(jì)到分庫(kù)分表统捶。而分庫(kù)分表，就會(huì)涉及到幾個(gè)關(guān)鍵性的問(wèn)題：切分維度匆绣，join的處理什黑，分布式事務(wù)
計(jì)算分拆
計(jì)算的分拆有2種思路：
數(shù)據(jù)分拆：一個(gè)大的數(shù)據(jù)集愕把，拆分成多個(gè)小的數(shù)據(jù)集，并行計(jì)算嚣镜。
比如大規(guī)模數(shù)據(jù)歸并排序
任務(wù)分拆：把一個(gè)長(zhǎng)的任務(wù)菊匿，拆分成幾個(gè)環(huán)節(jié)扮匠，各個(gè)環(huán)節(jié)并行計(jì)算。
Java中多線程的Fork/Join框架，Hadoop中的Map/Reduce力麸，都是計(jì)算分拆的典型框架。其思路都是相似的闺鲸，先分拆計(jì)算摸恍，再合并結(jié)果赤屋。
再比如分布式的搜索引擎中类早，數(shù)據(jù)分拆，分別建索引缭召，查詢結(jié)果再合并逆日。
并發(fā)
最常見(jiàn)的就是多線程室抽，盡可能提高程序的并發(fā)度。
比如多次rpc順序調(diào)用噩死，通過(guò)異步rpc轉(zhuǎn)化為并發(fā)調(diào)用神年；
比如數(shù)據(jù)分片已日，你的一個(gè)Job要掃描全表，跑幾個(gè)小時(shí)堂鲜，數(shù)據(jù)分片护奈，用多線程霉旗，性能會(huì)加快好幾倍蛀骇。
緩存
緩存大家都不陌生擅憔，遇到性能問(wèn)題檐晕，大家首先想到的就是緩存辟灰。關(guān)于緩存，一個(gè)關(guān)鍵點(diǎn)就是：緩存的粒度問(wèn)題笛洛。
比如Tweet的架構(gòu)苛让，緩存的粒度從小到大湿诊，有Row Cache, Vector Cache, Fragment Cache, Page Cache厅须。
粒度越小，重用性越好错沽，但查詢需要多次眶拉，需要數(shù)據(jù)拼裝忆植；
粒度越大，越容易會(huì)失效耀里，任何一個(gè)小的地方改動(dòng)冯挎，都可能造成緩存的失效痪枫。
在線計(jì)算 vs. 離線計(jì)算 / 同步 vs. 異步
在實(shí)際的業(yè)務(wù)需求中奶陈，并不是所有需要都需要完全實(shí)時(shí)的：
比如內(nèi)部針對(duì)產(chǎn)品、運(yùn)營(yíng)開(kāi)發(fā)的各種報(bào)表查詢潦俺、分析系統(tǒng)事示；
比如微博的傳播僻肖，我發(fā)了一個(gè)微博臀脏，我的粉絲延遲幾秒才看到，這是可以接受的秒啦，因?yàn)樗⒉粫?huì)注意到晚了幾秒余境；
比如搜索引擎的索引灌诅，我發(fā)了一篇博客猜拾，可能幾分鐘之后，才會(huì)被搜索引擎索引到侥涵；
比如支付寶轉(zhuǎn)帳芜飘、提現(xiàn)磨总，也并非這邊轉(zhuǎn)出之后蚪燕，對(duì)方立即收到奔浅；
汹桦。鉴裹。径荔。
這類例子很多总处。這種“非實(shí)時(shí)也可以接受“的場(chǎng)景，就為架構(gòu)的設(shè)計(jì)贏得了充分的回旋余地胧谈。
因?yàn)榉菍?shí)時(shí)第岖，我們就可以做異步，比如使用消息隊(duì)列试溯，比如使用后臺(tái)的Job蔑滓，周期性處理某類任務(wù)；
也因?yàn)榉菍?shí)時(shí)遇绞，我們可以做讀寫(xiě)分離键袱，讀和寫(xiě)不是完全同步，比如Mysql的Master-Slave摹闽。
全量 ＋ 增量
全量/增量其實(shí)也是在線/離線的思路：
比如搜索引擎的全量索引 ＋ 增量索引蹄咖，前者是為了吞吐，后者為了實(shí)時(shí)付鹿；
比如OceanBase數(shù)據(jù)庫(kù)，每次更新存在一個(gè)小表里面舵匾，定期merge俊抵；
Push vs. Pull
在所有分布式系統(tǒng)中，都涉及到一個(gè)基本問(wèn)題：節(jié)點(diǎn)之間（或者2個(gè)子系統(tǒng)之間）的狀態(tài)通知坐梯。比如一個(gè)節(jié)點(diǎn)狀態(tài)變更了徽诲，要通知另外一個(gè)節(jié)點(diǎn)，都有2種策略：
Push: 節(jié)點(diǎn)A狀態(tài)變了， push給節(jié)點(diǎn)B
Pull: 也就是輪詢谎替。節(jié)點(diǎn)B周期性的去詢問(wèn)節(jié)點(diǎn)A的狀態(tài)偷溺。
這個(gè)問(wèn)題不光出現(xiàn)在分布式系統(tǒng)中，可以說(shuō)是編寫(xiě)代碼的一個(gè)基本問(wèn)題钱贯。對(duì)應(yīng)到面向?qū)ο蟮木幊讨写焯停簿褪浅Ｕf(shuō)的“雙向關(guān)聯(lián)”這種耦合問(wèn)題。
A調(diào)用B喷舀，B再回調(diào)A砍濒，這種情形淋肾，在系統(tǒng)開(kāi)發(fā)中經(jīng)常出現(xiàn)硫麻。再?gòu)?fù)雜一點(diǎn)，多個(gè)模塊之間樊卓，彼此調(diào)用拿愧，調(diào)用關(guān)系跟蜘蛛網(wǎng)一樣启上。
這個(gè)問(wèn)題的出現(xiàn)拾因，就和Push/Pull的策略密切相關(guān)：
A調(diào)用B，那邏輯就會(huì)寫(xiě)在B這邊岖研；B調(diào)用A唾戚，邏輯就會(huì)寫(xiě)在A這邊柳洋。所以是采用主動(dòng)調(diào)用的pull方式，還是回調(diào)的push方式叹坦，會(huì)嚴(yán)重影響職責(zé)在各個(gè)模塊或者子系統(tǒng)里面的分配熊镣。
批量
批量其實(shí)也是在線/離線的一種思想，把實(shí)時(shí)問(wèn)題募书，轉(zhuǎn)化為一個(gè)批量處理的問(wèn)題绪囱，從而降低對(duì)系統(tǒng)吞吐量的壓力
比如Kafka中的批量發(fā)消息；
比如廣告扣費(fèi)系統(tǒng)中莹捡，把多次點(diǎn)擊累積在一起扣費(fèi)鬼吵；
。篮赢。
重寫(xiě)輕讀 vs 重讀輕寫(xiě)
重寫(xiě)輕讀齿椅，本質(zhì)就是“空間換時(shí)間“。你不是計(jì)算起來(lái)耗時(shí)启泣，延遲高嗎涣脚，那我可以提前計(jì)算，然后存儲(chǔ)起來(lái)种远。取的時(shí)候涩澡，直接去取。
我們通常對(duì)Mysql的用法，都是重讀輕寫(xiě)妙同，寫(xiě)的時(shí)候射富，簡(jiǎn)單；查的時(shí)候粥帚，做復(fù)雜的join計(jì)算胰耗，返回結(jié)果。這樣做的好處是容易做到數(shù)據(jù)的強(qiáng)一致性芒涡，不會(huì)因?yàn)樽侄稳哂嗖竦疲斐蓴?shù)據(jù)的不一致。但是性能可能就是問(wèn)題费尽。
而微博的Feeds架構(gòu)赠群，就是典型的重寫(xiě)輕讀。我要去看Feeds旱幼，按通常的mysql的做法查描，我要先去查我關(guān)注的所有的人，然后把所有人的消息排序柏卤，分頁(yè)返回冬三。很顯然，在大數(shù)據(jù)量下缘缚，這個(gè)會(huì)很耗時(shí)勾笆。
而如果采用重寫(xiě)輕讀，怎么做呢桥滨？你不是要看Feeds嗎窝爪，那就為每個(gè)人準(zhǔn)備一個(gè)Feeds，或者說(shuō)收件箱该园。某個(gè)人發(fā)了微博之后酸舍，把他的微博擴(kuò)散到所有人的收件箱，這個(gè)擴(kuò)散是異步的里初，在后臺(tái)擴(kuò)散啃勉。這樣每個(gè)人看自己的Feeds的時(shí)候，直接去自己的收件箱取就可以了双妨。
讀寫(xiě)分離
同樣淮阐，對(duì)傳統(tǒng)的單機(jī)Mysql數(shù)據(jù)庫(kù)，讀和寫(xiě)是完全同步的刁品。寫(xiě)進(jìn)去的內(nèi)容泣特，立馬就可以讀到。
但在很多業(yè)務(wù)場(chǎng)景下挑随，讀和寫(xiě)并不需要完全同步状您。這個(gè)時(shí)候，就可以分開(kāi)存儲(chǔ)，寫(xiě)到一個(gè)地方膏孟，再異步的同步到另一個(gè)地方眯分。這樣就可以實(shí)現(xiàn)讀寫(xiě)分離。
比如Mysql的Master/Slave就是個(gè)典型柒桑，Slave上面的數(shù)據(jù)并不是和Master實(shí)時(shí)同步的弊决；
再比如各種報(bào)表分析，OLTP/OLAP魁淳，線上/線下數(shù)據(jù)分離飘诗，線上數(shù)據(jù)定期同步到Hive集群，再做分析界逛。
動(dòng)靜分離
動(dòng)靜分離的典型例子就是網(wǎng)站的前端昆稿，動(dòng)態(tài)的頁(yè)面，放在web服務(wù)器上仇奶；靜態(tài)的css/jss/img貌嫡，直接放到CDN上，這樣既提高性能该溯，也極大的降低服務(wù)器壓力。
按照這個(gè)思路别惦，很多大型網(wǎng)站都致力于動(dòng)態(tài)內(nèi)容的靜態(tài)化狈茉，靜態(tài)化之后，就可以很容易的緩存掸掸。
冷熱分離
比如定期把mysql中的歷史數(shù)據(jù)氯庆，同步到hive
限流
現(xiàn)在很多電商都會(huì)有秒殺活動(dòng)，秒殺的一個(gè)特點(diǎn)就是商品很少扰付，但短時(shí)間內(nèi)流量暴增堤撵，服務(wù)器完全處理不了這么多請(qǐng)求。
應(yīng)對(duì)這類問(wèn)題的一個(gè)基本思路就是限流羽莺，既然處理不了那么多請(qǐng)求实昨，既然很大人進(jìn)去了，也是搶不到的盐固。那索性不要放那么多人進(jìn)去荒给。
這個(gè)和我們?nèi)粘Ｉ钪校?jié)假日刁卜，某個(gè)景點(diǎn)人數(shù)過(guò)多志电，限制人流量是同樣的道理。
服務(wù)熔斷與降級(jí)
服務(wù)降級(jí)是系統(tǒng)的最后一道保險(xiǎn)蛔趴。在一個(gè)復(fù)雜系統(tǒng)內(nèi)部挑辆，一個(gè)系統(tǒng)往往會(huì)調(diào)用其它很大系統(tǒng)的服務(wù)。在大流量的情況下，我們可能會(huì)在保證主流程能正常工作的情況下鱼蝉，對(duì)其它服務(wù)做降級(jí)茉继。
所謂降級(jí)，也就是當(dāng)某個(gè)服務(wù)不可用時(shí)蚀乔，干脆就別讓其提供服務(wù)了烁竭，直接返回一個(gè)缺省的結(jié)果。雖然這個(gè)服務(wù)不可用吉挣，但它不至于讓整個(gè)主流程癱瘓派撕，這就可以最大限度的保證核心系統(tǒng)可用。
CAP理論
上面講的各種思想睬魂，用一個(gè)更大的思想來(lái)概括的話终吼，就是CAP。
Consistency：數(shù)據(jù)一致性氯哮，這個(gè)很容易理解际跪，就是沒(méi)有臟數(shù)據(jù)。我們知道喉钢，在Mysql中有一致性的概念姆打，比如參照完整性約束、事務(wù)等肠虽。但這里的C主要特指同1份數(shù)據(jù)的多個(gè)備份之間的一致性幔戏。
Availability：可用性有2重意思，一個(gè)是說(shuō)穩(wěn)定性税课，服務(wù)可用闲延，不會(huì)掛；另外一個(gè)是性能韩玩，也就是要快垒玲，如果延遲很高，經(jīng)常超時(shí)找颓，那和掛了也就區(qū)別不大了合愈。
Partition tolerance(分區(qū)容錯(cuò)性)：分區(qū)，其實(shí)指網(wǎng)絡(luò)分區(qū)叮雳。當(dāng)你把數(shù)據(jù)從1個(gè)物理設(shè)備想暗，分到多個(gè)物理設(shè)備之后，設(shè)備之間必然是通過(guò)網(wǎng)絡(luò)進(jìn)行通信帘不。這就會(huì)遇到網(wǎng)絡(luò)分區(qū)说莫，也就是典型的“2將軍問(wèn)題“，網(wǎng)絡(luò)超時(shí)時(shí)間不定寞焙。學(xué)術(shù)上有個(gè)詞储狭，叫“異步通信環(huán)境“互婿。
以前說(shuō)CAP理論，說(shuō)對(duì)于一個(gè)分布式系統(tǒng)辽狈，上面3個(gè)慈参，只能同時(shí)滿足2個(gè)。但這個(gè)其實(shí)不準(zhǔn)確刮萌，P其實(shí)一定存在驮配，是你避免不了的。能做的着茸，其實(shí)主要是在C和A之間權(quán)衡壮锻。
比如拿Mysql來(lái)說(shuō)，它的C最強(qiáng)涮阔，A次之猜绣，P最弱。如果你為了A敬特，給數(shù)據(jù)做冗余掰邢，比如重寫(xiě)輕讀，那C就很難保證伟阔；為了P辣之，給數(shù)據(jù)做分庫(kù)分表，那就做不了事務(wù)减俏；
比如Nosql召烂，P最強(qiáng)，可以很好的做數(shù)據(jù)拆分娃承，但C就不夠，做不了事務(wù)怕篷；
比如微博系統(tǒng)历筝，對(duì)C的要求降低，就可以加很多緩存廊谓，提高A梳猪；數(shù)據(jù)分片，提高P蒸痹；
而支付春弥，交易轉(zhuǎn)帳，對(duì)C的要求很高叠荠，就不能簡(jiǎn)單的用Cache來(lái)提高性能
在此我向大家推薦一個(gè)架構(gòu)學(xué)習(xí)交流群匿沛。交流學(xué)習(xí)群號(hào)：855801563? 里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis榛鼎，Netty源碼分析逃呼，高并發(fā)鳖孤、高性能、分布式抡笼、微服務(wù)架構(gòu)的原理苏揣，JVM性能優(yōu)化、分布式架構(gòu)等這些成為架構(gòu)師必備的知識(shí)體系推姻。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源平匈，目前受益良多
最終一致性
前面提到，在分布式系統(tǒng)中藏古，因?yàn)閿?shù)據(jù)的分拆增炭，服務(wù)的分拆，強(qiáng)一致性就很難保證校翔。這個(gè)時(shí)候弟跑，用的最多的就是“最終一致性“。
強(qiáng)一致性防症，弱一致性孟辑，最終一致性，是一致性的幾個(gè)不同的等級(jí)蔫敲。在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)中饲嗽，通過(guò)事務(wù)來(lái)保證強(qiáng)一致性。
但在分布式系統(tǒng)中奈嘿，通常都會(huì)把強(qiáng)一致性折中成最終一致性貌虾，從而變相的解決分布式事務(wù)問(wèn)題。
典型的轉(zhuǎn)帳的例子裙犹，A給B轉(zhuǎn)帳1萬(wàn)塊錢尽狠，A的賬號(hào)扣1萬(wàn)，B的賬號(hào)加1萬(wàn)叶圃。但這2步未必需要同時(shí)發(fā)生, A的扣完之后袄膏，B的賬號(hào)上面未必立馬就有，但只要保證B最終可以收到就可以了掺冠。
最終一致性的實(shí)現(xiàn)沉馆，通常都需要一個(gè)高可靠的消息隊(duì)列。
