設計分布式系統主要考慮以下四個大點，兩個小點：
四個大點：
兩個小點：
我們都知道，系統出現故障是非常常見的，所以我們應該把處理故障的**當成正常的功能做在架構裡寫在**裡，使得故障真正發生時，系統還可以執行
分布式鎖設計原則：
什麼是系統的可伸縮性？
如果你的系統對乙個使用者來說是快的，但是在使用者不斷增長的高訪問量下就慢了
伸縮性方案
垂直伸縮: 公升級到更強大的伺服器（多cpu 昂貴大中型機）。
水平伸縮:
弱一致性：資料經過乙個時間視窗之後，只要多嘗試幾次，最終的狀態是一致的，是最新的資料。比如發了一條微博，改了某些配置，可能不會馬上生效，但重新整理幾次後就可以看到了
重試：由於網路等問題，一些請求無法確定是否成功，這個時候需要重試，即在此傳送請求給服務端，處理邏輯是將請求包在乙個重試迴圈裡
1、解耦（mq）
在軟體工程中，物件之間的耦合度就是物件之間的依賴性。物件之間的耦合越高，維護成本越高，因此物件的設計應使模組之間的耦合度盡量小。
在軟體架構設計中，模組之間的解耦有兩種，假設有兩個模組a、b，a依賴b：
第一種：模組a和模組b只通過接**互，只要介面設計不變，那麼模組b內部細節的變化不影響模組a對模組b服務能力的消費。
面向介面設計下真正實現了將介面契約的定義和介面的實現徹底分離，實現變化不影響到介面契約，自然不影響到基於介面的互動。
模組a和b之間的松耦合，主要通過合理的模組劃分、介面設計來完成。如果出現迴圈依賴，可以將模組a、b共同依賴的部分移除到另乙個模組c中，將a、b之間的相互依賴，轉換為a、b同時對c的依賴。
第二種：將同步呼叫轉換成非同步訊息互動。
比如在買機票系統中，機票支付完成後需要通知出票系統出票、代金券系統發券。如果使用同步呼叫，那麼出票系統、代金券系統宕機是會影響到機票支付系統，如果另乙個系統比如專車系統也想要在機票支付完成後向使用者推薦專車服務，那麼同步呼叫模式下機票支付系統就需要為此而改動，容易影響核心支付業務的可靠性。
如果我們將同步呼叫替換成非同步訊息，機票支付系統傳送機票支付成功的訊息到訊息中介軟體，出票系統、代金券系統從訊息中介軟體訂閱訊息。這樣一來，出票系統、代金券系統的宕機也就不會對機票支付系統造成任何影響了。專車系統想要知道機票支付完成這一事件，也只需要從訊息中介軟體訂閱訊息即可，機票支付系統完全不需要做任何改動。
非同步訊息解耦，適合那些資訊流單向流動（類似發布-訂閱這樣的），實時性要求不高的系統。常見的開源訊息佇列框架有：kafka、rabbitmq、rocketmq。
2、執行緒池
執行緒池：如果併發的執行緒數量很多，並且每個執行緒都是執行乙個時間很短的任務就結束了，這樣頻繁建立執行緒就會大大降低系統的效率，因為頻繁建立執行緒和銷毀執行緒需要時間，且建立過多的執行緒會耗費系統資源，頻繁的上下文切換也影響系統的效能。
分布式服務如何設計分布式事務
1 如果a b c強相關 考慮採用tcc框架 try confirm cancel bytetcc，himly 阿里的fescar，seata 推薦使用seata tcc框架 2 如果a 與bc並不強相關 考慮可靠訊息最終一致性解決方案，例如a成功後通過傳送kafka事件，bc監聽事件來處理。roc...
Redis設計分布式鎖
通過redis高版本的原子命令 jedis.set lockname,nx px expiretime 分析 redis的set命令可以攜帶複雜引數，第乙個是鎖的key，第二個是value，可以存放獲取鎖的客戶端id，通過這個校驗是否當前客戶端獲取到了鎖，第三個引數取值nx xx,第四個引數 ex ...
分布式 分布式系統的設計
在計算機領域，當單機效能達到瓶頸時，一般有兩種方式解決效能問題 而分布式系統的設計說白了就是 如何合理將乙個系統拆分成多個子系統部署到不同機器上。講設計方法前，先介紹分布式系統的特性 1 分布性 空間中隨機分布。這些計算機可以分布在不同的機房，不同的城市，甚至不同的國家。2 對等性 分布式系統中的計...