分布式的初衷是為了分隔和拆分子業務，所以分布式指的物件是應用伺服器。每個應用伺服器都可以部署單獨的子業務。
一般分析好處，我們可以從下面幾點進行考慮：
1.可用性。分布式部署，如果乙個業務節點出現問題，不會影響其他業務節點， 除非其他業務節點依賴了失敗節點。
2.易擴充套件，客觀上便於高效能。因為單獨的子業務，更容易擴充套件部署。
3.易維護，公升級部署時，只需要更新子業務本身的**即可。
每個子業務，都可以視作乙個子系統進行部署。
有分布式部署，就會涉及到另外乙個問題，就是業務之間的互動。各子系統，如何知道其他子系統的存在。這就需要註冊中心。每個子系統在啟動時，把自己的資訊註冊到註冊中心。而訪問其他子系統服務時，先從註冊中心獲取可用子系統的資訊，進而進行訪問。
而微服務可以視作分布式的乙個具體實現。
分布式的乙個目的，就是為了解耦服務。而這些服務之間通訊需要的是共享的東西。這些共享的東西，可以是儲存(例如，mysql，redis)，或者通過訊息中介軟體，例如kafka
集群要解決的問題，也是同樣的，不過，集群可以看做同乙個業務部署多份，而不是乙個業務拆分為多個子業務。通過部署多份，再加上負載均衡，提供高可用和高併發。
當集群中的一台機器出現問題時，負載均衡器，就可以發現，並將其剔除。從而保證請求正常被響應。
這些問題都解決了，貌似沒有問題了，但是這些只是業務方面。也就是應用伺服器。而應用伺服器後面，都會對應著儲存服務，就是我們常說的資料庫。
資料庫也會故障，那麼為了解決資料庫的突發故障導致的服務不可用。就需要也為資料庫進行集群部署，而集群部署的主要方式，就是主從方案。
一主一從，或者一主多從的方案，一方面提供備份，另一方面也會為讀寫分離做基礎準備。
但是主從方案會有乙個問題，資料同步會有延遲，而這種延遲主要來自於部署的位置。所以同城部署主從會是常見方案，但是一旦遇到城市級別斷電或者網路故障，仍不能保證高可用。所以，會在異地部署乙個備份，但是這個備份平時是不會使用的，也就是冷的。而乙個過冷的資料庫，是很難作為臨時啟用的資料庫來正常工作的，風險非常大。
因為同城的主從，切換角色的可能性會存在，而且從庫平時可以作為讀庫存在，可以算作是熱庫。而異地備份，雖然也可以視作從庫，但是從未被使用過，因此，緊急啟用風險較大。
這就是兩地三中心，和兩地三中心方案帶來的問題。
如果本地和異地，一熱一冷，有這麼大的弊端，那麼，異地的資料庫也變為熱的呢？其實，這就是所謂的異地雙活，或者異地多活。而活，就是熱，表示資料庫為平時的提供服務。
異地多活，主要的挑戰來自於資料同步。
從巨集觀上來說，距離帶來的傳輸延遲會比較大。所以，資料一致性會是乙個挑戰。
從細節上來說，因為部署的異地的多個服務有可能會同時修改同一條資料，而落在兩個資料庫。這兩個資料庫中的哪條資料作為最終的資料被認可，就是乙個問題了。
另外，對於新增資料，會不會出現主鍵衝突，也是另外乙個需要考慮的問題。
對於資料修改問題，可以利用時間戳，後修改的資料，覆蓋前面修改的資料。
對於資料新增問題，可以利用全域性uui，或者利用各個機房作為主鍵字首的方式來規避主鍵衝突。
而異地多活的資料同步，則需要更多的手段，例如中介軟體來實現了。
或許，我們可以從訊息中介軟體的發布訂閱機制來獲得一些解決的思路。
在一主多備的方式下，主從同步，使用拉的方式來實現。也就是主庫將自己的redolog寫到某個特定的地方，從庫主動拉取，因為會有多個從庫，不可能採用推的方式。
異地多活中的某個熱庫，對於其他熱庫來說，當然就是從庫。所以，乙個熱庫，只管將自己的redolog寫到某個地方，其他熱庫需要自行拉取。
php分布式微服務開發 分布式微服務架構
隨著業務的不斷發展,使用者體量的快速擴張.從單體 垂直架構轉移到分布式 微服務架構是自然而然的選擇.分布式理論是分布式系統的基礎,在任何情況下分布式系統都要滿足網路分割槽容錯性,因此分布式系統都是在可用性和一致性方面做平衡.cap理論指的是在乙個分布式系統中,一致性 可用性 分割槽容錯性 在任何情況...
分布式 微服務面試
分布式 微服務面試 為什麼要拆分成多個微服務？微服務架構與傳統架構的優缺點？我們為什麼要使用分布式？分布式事物問題出現場景？如何解決分布式事物的問題？tcc是什麼？實現原理是怎麼樣的？2pc，3pc的概念是什麼？實現原理是怎樣的？訊息的最終一致性是什麼意思？如何實現訊息的最終一致性？訊息的最大努力通...
python 微服務熔斷工具 分布式微服務監控工具
看看森蘇。sensu是乙個非常先進的監控工具。把它想象成分布式nagios。因此，在每台機器上安裝乙個sensu 它有大量的外掛程式可用於上面提到的每個程序。您也可以用自己選擇的語言編寫自己的外掛程式，只要它們是有效的可執行檔案。bash perl python ruby任何東西都可以。將資料發布到...