分布式與集群的區別
分布式系統架構的第一原則是不要分布！這句話看似矛盾，但實則揭示了分布式系統的很多特徵。
分布式系統的目標是提公升系統整體效能和吞吐量另外還要盡量保證分布式系統的容錯性。
即使採用了分布式系統，我們也要盡力運用併發程式設計，高效能網路框架等等手段來提公升單機上的程式效能。
兩個角色：
中心化的設計思想很簡單，分布式集群中的節點機器按照角色分工，大體上分為兩種角色： 「領導」 和 「幹活的」。
角色職責：
「領導」通常負責分發任務並監督「幹活的」，發現誰太閒了，就想發設法地給其安排新任務，確保沒有乙個「幹活的」能夠偷懶，如果「領導」發現某個「幹活的」因為勞累過度而病倒了，則是不會考慮先嘗試「醫治」他的，而是一腳踢出去，然後把他的任務分給其他人。其中微服務架構kubernetes就恰好採用了這一設計思路。
中心化設計的問題：
中心化的設計存在的最大問題是「領導」的安危問題，如果「領導」出了問題，則群龍無首，整個集群就奔潰了。但我們難以同時安排兩個「領導」以避免單點問題。
中心化設計還存在另外乙個潛在的問題，既「領導」的能力問題：
可以領導10個人高效工作並不意味著可以領導100個人高效工作，所以如果系統設計和實現得不好，問題就會卡在「領導」身上。
領導安危問題的解決辦法：
大多數中心化系統都採用了主備兩個「領導」的設計方案，可以是熱備或者冷備，也可以是自動切換或者手動切換，而且越來越多的新系統都開始具備自動選舉切換「領導」的能力，以提公升系統的可用性。
眾生地位平等：
在去中心化的設計裡，通常沒有「領導」和「幹活的」這兩種角色的區分，大家的角色都是一樣的，地位是平等的，全球網際網路就是乙個典型的去中心化的分布式系統，聯網的任意節點裝置宕機，都只會影響很小範圍的功能。
「去中心化」不是不要中心，而是由節點來自由選擇中心。
（集群的成員會自發的舉行「會議」選舉新的「領導」主持工作。最典型的案例就是zookeeper及go語言實現的etcd）
去中心化設計的問題：
去中心化設計裡最難解決的乙個問題是 「腦裂」問題 ，這種情況的發聲概率很低，但影響很大。
腦裂指乙個集群由於網路的故障，被分為至少兩個彼此無法通訊的單獨集群，此時如果兩個集群都各自工作，則可能會產生嚴重的資料衝突和錯誤。一般的設計思路是，當集群判斷發生了腦裂問題時，規模較小的集群就「自殺」或者拒絕服務。
分布式：
乙個業務分拆多個子業務，部署在不同的伺服器上
集群：同乙個業務，部署在多個伺服器上
分布式系統 CAP理論
cp 天貓雙十一下單搶購,要保證一致性,沒貨了下單失敗 一般來說，如果不需要儲存服務級別的資訊，且服務例項是通過 nacos client 註冊，並能夠保證心跳上報，那麼就可以選擇 ap 模式。當前主流的服務如 spring cloud 和 dubbo 服務，都適用於 ap 模式，ap模式為了服務的...
分布式系統CAP理論
c是一致性，a是可用性，p是分割槽容錯。前兩個沒什麼好說的，主要是p我不太清楚。然後我看文章中最後的證明，有點明白了。分割槽是指兩個伺服器之間傳送資訊失敗。而分割槽容錯就是系統允許發生這種兩個伺服器之間無法傳輸資料的情況。也就是說c和a如果算是正面的 好的性質，那麼p就是負面的 壞的性質。那為什麼允...
分布式理論 分布式事務
資料庫事務 事務的基本特性 事務有4個非常重要的特性，即我們常說的 acid atomicity 原子性 是說事務是乙個不可分割的整體，所有操作要麼全做，要麼全不做 只要事務中有乙個操作出錯，回滾到事務開始前的狀態的話，那麼之前已經執行的所有操作都是無效的，都應該回滾到開始前的狀態。consiste...