一、分布式系統(tǒng)面臨的挑戰(zhàn)有哪些
分布式系統(tǒng)需要大量機器協(xié)作，面臨諸多的挑戰(zhàn)，其中主要的挑戰(zhàn)有：
1、異構的機器與網(wǎng)絡
分布式系統(tǒng)中的機器，配置不一樣，其上運行的服務也可能由不同的語言、架構實現(xiàn)，因此處理能力也不一樣；節(jié)點間通過網(wǎng)絡連接，而不同網(wǎng)絡運營商提供的網(wǎng)絡的帶寬、延時、丟包率又不一樣。怎么保證大家齊頭并進，共同完成目標，這是個不小的挑戰(zhàn)。
2、普遍的節(jié)點故障
雖然單個節(jié)點的故障概率較低，但節(jié)點數(shù)目達到一定規(guī)模，出故障的概率就變高了。分布式系統(tǒng)需要保證故障發(fā)生的時候，系統(tǒng)仍然是可用的，這就需要監(jiān)控節(jié)點的狀態(tài)，在節(jié)點故障的情況下將該節(jié)點負責的計算、存儲任務轉移到其他節(jié)點。
3、不可靠的網(wǎng)絡
節(jié)點間通過網(wǎng)絡通信，而網(wǎng)絡是不可靠的?？赡艿木W(wǎng)絡問題包括：網(wǎng)絡分割、延時、丟包、亂序。相比單機過程調(diào)用，網(wǎng)絡通信最讓人頭疼的是超時：節(jié)點A向節(jié)點B發(fā)出請求，在約定的時間內(nèi)沒有收到節(jié)點B的響應，那么B是否處理了請求，這個是不確定的，這個不確定會帶來諸多問題，最簡單的，是否要重試請求，節(jié)點B會不會多次處理同一個請求。
總而言之，分布式的挑戰(zhàn)來自不確定性，不確定計算機什么時候crash、斷電，不確定磁盤什么時候損壞，不確定每次網(wǎng)絡通信要延遲多久，也不確定通信對端是否處理了發(fā)送的消息。而分布式的規(guī)模放大了這個不確定性，不確定性是令人討厭的，所以有諸多的分布式理論、協(xié)議來保證在這種不確定性的情況下，系統(tǒng)還能繼續(xù)正常工作。
二、分布式系統(tǒng)帶來的問題及解答
1、如何找到所需的服務？——服務發(fā)現(xiàn)組件
問題描述：線上生產(chǎn)環(huán)境中，尤其容器部署情況下服務實例地址（服務器端口）是動態(tài)分配的，服務調(diào)用者無法提前獲取服務實例地址和端口。
解決方案：在服務運行時，通過服務發(fā)現(xiàn)組件解析服務名來獲取服務實例地址和端口。
2、如何找到實例？——請求分發(fā)的策略
問題描述：找到服務器后，還應該確定將當前請求發(fā)往服務器的哪一個實例。
解決方案：
（1）如果同一個服務的實例都是完全對等的（無狀態(tài)），那么按負載均衡策略來處理就足夠（隨機、輪詢、權重、hash、一致性hash、fair等各種策略）。
（2）如果同一個服務的實例不是對等的（有狀態(tài)），那么需要通過路由服務（元數(shù)據(jù)服務等）先確定當前要訪問的請求數(shù)據(jù)在哪一個實例上，然后再進行訪問。
3、如何避免雪崩？
問題描述：一個故障由于正反饋不斷被擴大，從而導致整個系統(tǒng)故障
解決方案：
（1）【快速失敗】和【降級機制】：熔斷、降級、限流等，通過快速減少系統(tǒng)負載來避免雪崩的發(fā)生。
（2）【彈性擴容機制】，通過快速增加系統(tǒng)的服務能力來避免雪崩的發(fā)生。
4、如何對系統(tǒng)進行監(jiān)控？
問題描述：對于一個分布式系統(tǒng)，如果我們不能很清楚地了解內(nèi)部的狀態(tài)，那么高可用是沒有辦法完全保障的。
解決方案：監(jiān)控系統(tǒng)的各層
（1）【硬件層面】：服務器溫度、磁盤RAID陣列等。
（2）【系統(tǒng)層面】：存活狀態(tài)、CPU、RAM、load負載。
（3）【應用層】：mysql、Nginx、Django、LVS、HAProxy。
（4）【業(yè)務層面】：PV、UV、訂單。
5、分布式存儲如何做數(shù)據(jù)切片？
問題描述：既然要實現(xiàn)分布式數(shù)據(jù)庫，那么應該如何將數(shù)據(jù)進行切片？
解決方案：Hash、Consistent Hash和Range Based分片策略。
6、如何設置冗余？如何復制數(shù)據(jù)？
問題描述：分布式存儲的高可用性需要冗余來保證，那么如何做冗余？如何對數(shù)據(jù)進行復制、更新時保證兩份數(shù)據(jù)的一致性？
解決方案：
（1）【中心化方案】：主從復制、一致性協(xié)議（Raft和Paxos）。
（2）【去中心化的方案】：Quorum、Vector Clock。
