明明架構要求高可用，為何系統中還會存在單點？
回答：單點master的設計，會大大簡化系統設計，何況有時候避免不了單點
在哪些場景中會存在單點？先來看一下乙個典型網際網路高可用架構。
典型網際網路高可用架構：
（2）負載均衡層，nginx是整個服務端的入口，負責反向**與負載均衡工作
（3）站點層，web-server層，典型的是tomcat或者apache
（4）服務層，service層，典型的是dubbo或者thrift等提供rpc呼叫的後端服務
（5）資料層，包含cache和db，典型的是主從複製讀寫分離的db架構
在這個網際網路架構中，站點層、服務層、資料庫的從庫都可以通過冗餘的方式來保證高可用，但至少
（1）nginx層是乙個潛在的單點
（2）資料庫寫庫master也是乙個潛在的單點
二、單點架構存在的問題
單點系統一般來說存在兩個很大的問題：
（1）非高可用：既然是單點，master一旦發生故障，服務就會受到影響
（2）效能瓶頸：既然是單點，不具備良好的擴充套件性，服務效能總有乙個上限，這個單點的效能上限往往就是整個系統的效能上限
三、shadow-master解決單點高可用缺陷
shadow-master是一種很常見的解決單點高可用問題的技術方案。
「影子master」，顧名思義，服務正常時，它只是單點master的乙個影子，在master出現故障時，shadow-master會自動變成master，繼續提供服務。
shadow-master它能夠解決高可用的問題，並且故障的轉移是自動的，不需要人工介入，但不足是它使服務資源的利用率降為了50%，業內經常使用keepalived+vip的方式實現這類單點的高可用。
master正常時：
（1）client會連線正常的master，shadow-master不對外提供服務
（2）master與shadow-master之間有一種存活探測機制
（3）master與shadow-master有相同的虛ip（virtual-ip）
當發現master異常時：
shadow-master會自動頂上成為master，虛ip機制可以保證這個過程對呼叫方是透明的。
舉例：資料庫的主庫master（主庫）亦可用類似的方式來保證高可用，只是細節上有些地方要注意：
傳統的一主多從，讀寫分離的db架構，只能保證讀庫的高可用，是無法保證寫庫的高可用的，要想保證寫庫的高可用，也可以使用上述的shadow-master機制：
（1）兩個主庫設定相互同步的雙主模式
（2）平時只有乙個主庫提供服務，言下之意，shadow-master不會往master同步資料
（3）異常時，虛ip漂移到另乙個主庫，shadow-master變成主庫繼續提供服務
需要說明的是，由於資料庫的特殊性，資料同步需要時延，如果資料還沒有同步完成，流量就切到了shadow-master，可能引起小部分資料的不一致。
既然知道單點存在效能上限，單點的效能有可能成為系統的瓶頸，那麼，減少與單點的互動，便成了存在單點的系統優化的核心方向。
怎麼來減少與單點的互動，這裡提兩種常見的方法。
批量寫
批量寫是一種常見的提公升單點效能的方式。
例如乙個利用資料庫寫單點生成做「id生成器」的例子：
（1）業務方需要id
（2）利用資料庫寫單點的auto increament id來生成和返回id
這是乙個很常見的例子，很多公司也就是這麼生成id的，它利用了資料庫寫單點的特性，方便快捷，無額外開發成本，是乙個非常帥氣的方案。
潛在的問題是：生成id的併發上限，取決於單點資料庫的寫效能上限。
如何提公升效能呢？批量寫
（1）中間加乙個服務，每次從資料庫拿出100個id
（2）業務方需要id
（3）服務直接返回100個id中的1個，100個分配完，再訪問資料庫
這樣一來，每分配100個才會寫資料庫一次，分配id的效能可以認為提公升了100倍。
客戶端快取
客戶端快取也是一種降低與單點互動次數，提公升系統整體效能的方法。
還是以檔案系統為例：
（1）呼叫客戶端client要訪問shenjian.txt，先查詢本地快取，miss了
（2）client訪問master問說檔案在**，master告訴client在chunk3上
（3）client把shenjian.txt存放在chunk3上記錄到本地的快取，然後進行檔案的讀寫操作
（4）未來client要訪問檔案，從本地快取中查詢到對應的記錄，就不用再請求master了，可以直接訪問chunk3。如果檔案發生了轉移，chunk3返回client說「檔案不在我這兒了」，client再訪問master，詢問檔案所在的伺服器。
這類快取的命中非常非常高，可能在99.9%以上（因為檔案的自動遷移是小概率事件），這樣與master的互動次數就降低了1000倍。
無論怎麼批量寫，客戶端快取，單點畢竟是單機，還是有效能上限的。
想方設法水平擴充套件，消除系統單點，理論上才能夠無限的提公升系統系統。
以nginx為例，如何來進行水平擴充套件呢？
第一步的dns解析，只能返回乙個nginx外網ip麼？答案顯然是否定的，「dns輪詢」技術支援dns-server返回不同的nginx外網ip，這樣就能實現nginx負載均衡層的水平擴充套件。
dns-server部分，乙個網域名稱可以配置多個ip，每次dns解析請求，輪詢返回不同的ip，就能實現nginx的水平擴充套件，擴充負載均衡層的整體效能。
資料庫單點寫庫也是同樣的道理，在資料量很大的情況下，可以通過水平拆分，來提公升寫入效能。
（1）單點系統存在的問題：可用性問題，效能瓶頸問題
（2）shadow-master是一種常見的解決單點系統可用性問題的方案
（3）減少與單點的互動，是存在單點的系統優化的核心方向，常見方法有批量寫，客戶端快取
（4）水平擴充套件也是提公升單點系統效能的好方案
單點系統架構的優化
明明架構要求高可用，為何系統中還會存在單點？回答 單點master的設計，會大大簡化系統設計，何況有時候避免不了單點 在哪些場景中會存在單點？先來看一下乙個典型網際網路高可用架構。典型網際網路高可用架構 2 負載均衡層，nginx是整個服務端的入口，負責反向 與負載均衡工作 3 站點層，web se...
單點系統架構可用性與效能優化
單點master的設計會大大簡化系統設計，何況有時候避免不了單點。先看乙個典型網際網路高可用架構 2 負載均衡層 nginx是整個服務端的入口，負責反向 與負責均衡工作 3 站點層 web server層，典型的是tomcat或apache 4 服務層 service層，典型的是dubbo或thri...
12306系統架構優化
coolshell陳皓優化方案 原文 一 業務複雜度比對 二 瓶頸 庫存業務的操作模式基本是這樣的 1 佔住庫存 2 付款 3 扣除庫存 這個過程中，是要對資料進行加鎖的，高併發下資料的一致性保證非常之難。併發究竟有多大呢？12306的業務特點是，突然放票，大家去搶。幾十分鐘內，馬上幾千萬的訪問量，...