一、需求緣起

明明架構要求高可用，?為何系統中還會存在單點？

回答：單點?master?的設計，會?大大簡化系統設計，何況有時候避免不了單點

在哪些場景中會存在單點？先來看一下一個?典型互聯網高可用架構?。

典型互聯網高可用架構：

（?1?）?客戶端層?，這一層是瀏覽器或者?APP?，第一步先訪問?DNS-server?，由域名拿到?nginx?的外網?IP

（?2?）?負載均衡層?，?nginx?是整個服務端的入口，負責反向代理與負載均衡工作

（?3?）?站點層?，?web-server?層，典型的是?tomcat?或者?apache

（?4?）?服務層?，?service?層，典型的是?dubbo?或者?thrift?等提供?RPC?調用的后端服務

（?5?）?數據層?，包含?cache?和?db?，典型的是主從復制讀寫分離的?db?架構

在這個互聯網架構中，站點層、服務層、數據庫的從庫都可以通過冗余的方式來保證高可用，但至少

（?1?）?nginx?層是一個潛在的單點

（?2?）數據庫?寫庫?master?也是一個潛在的單點

再舉一個?GFS?（?Google File System?）架構的例子。

GFS?的系統架構里主要有這么幾種角色：

（?1?）?client?，就是發起文件讀寫的調用端

（?2?）?master?，這是一個單點服務，它有全局事業，掌握文件元信息

（?3?）?chunk-server?，實際存儲文件額服務器

這個系統里，?master?也是一個單點的服務，?Map-reduce?系統里也有類似的全局協調的?master?單點角色。

系統架構設計中，像?nginx?，?db-master?，?gfs-master?這樣的單點服務，會存在什么問題，有什么方案來優化呢，這是本文要討論的問題。

二、單點架構存在的問題

單點系統一般來說存在?兩個很大的問題?：

（?1?）?非高可用?：既然是單點，?master?一旦發生故障，服務就會受到影響

（?2?）?性能瓶頸?：既然是單點，不具備良好的擴展性，服務性能總有一個上限，這個單點的性能上限往往就是整個系統的性能上限

接下來，就看看有什么優化手段可以優化上面提到的兩個問題

三、?shadow-master?解決單點高可用問題

shadow-master?是一種很常見的解決單點高可用問題的技術方案。

“?影子?master”?，顧名思義，服務正常時，它只是單點?master?的一個影子，在?master?出現故障時，?shadow-master?會自動變成?master?，繼續提供服務。

shadow-master?它能夠解決高可用的問題，并且故障的轉移是自動的，不需要人工介入，但不足是它使?服務資源的利用率降為了?50%?，?業內經常使用?keepalived+vip的方式實現這類單點的高可用?。

以?GFS?的?master?為例，?master?正常時：

（?1?）?client?會連接正常的?master?，?shadow-master?不對外提供服務

（?2?）?master?與?shadow-master?之間有一種存活探測機制

（?3?）?master?與?shadow-master?有相同的虛?IP?（?virtual-IP?）

當發現?master?異常時：

shadow-master?會自動頂上成為?master?，虛?IP?機制可以保證?這個過程對調用方是透明的

除了?GFS?與?MapReduce?系統中的主控?master?，?nginx?亦可用類似的方式保證高可用，數據庫的主庫?master?（主庫）亦可用類似的方式來保證高可用，只是細節上有些地方要注意：

傳統的一主多從，讀寫分離的?db?架構，只能保證讀庫的高可用，是無法保證寫庫的高可用的，要想保證寫庫的高可用，也可以使用上述的?shadow-master?機制：

（?1?）兩個主庫設置?相互同步的雙主模式

（?2?）平時只有一個主庫提供服務，言下之意，?shadow-master?不會往?master?同步數據

（?3?）異常時，虛?IP?漂移到另一個主庫，?shadow-master?變成主庫繼續提供服務

需要說明的是，由于數據庫的特殊性，數據同步需要時延，如果數據還沒有同步完成，流量就切到了?shadow-master?，可能引起小部分數據的不一致。

四、減少與單點的交互，是存在單點的系統優化的核心方向

既然知道單點存在性能上限，單點的性能（例如?GFS?中的?master?）有可能成為系統的瓶頸，那么，?減少與單點的交互，便成了存在單點的系統優化的核心方向。

怎么來減少與單點的交互，這里提兩種常見的方法。

批量寫

批量寫是一種常見的提升單點性能的方式。

例如一個利用數據庫寫單點生成做?“ID?生成器?”?的例子：

（?1?）業務方需要?ID

（?2?）利用數據庫寫單點的?auto increament id?來生成和返回?ID

這是一個很常見的例子，很多公司也就是這么生成?ID?的，它利用了數據庫寫單點的特性，方便快捷，無額外開發成本，是一個非常帥氣的方案。

潛在的問題是：生成?ID?的并發上限，取決于單點數據庫的寫性能上限。

如何提升性能呢？批量寫

（?1?）中間加一個服務，每次從數據庫拿出?100?個?id

（?2?）業務方需要?ID

（?3?）服務直接返回?100?個?id?中的?1?個，?100?個分配完，再訪問數據庫

這樣一來，每分配?100?個才會寫數據庫一次，分配?id?的性能可以認為提升了?100倍。

客戶端緩存

客戶端緩存也是一種降低與單點交互次數，提升系統整體性能的方法。

還是以?GFS?文件系統為例：

（?1?）?GFS?的調用客戶端?client?要訪問?shenjian.txt?，先查詢本地緩存，?miss?了

（?2?）?client?訪問?master?問說文件在哪里，?master?告訴?client?在?chunk3?上

（?3?）?client?把?shenjian.txt?存放在?chunk3?上記錄到本地的緩存，然后進行文件的讀寫操作

（?4?）未來?client?要訪問文件，從本地緩存中查找到對應的記錄，就不用再請求?master?了，可以直接訪問?chunk-server?。如果文件發生了轉移，?chunk3?返回?client?說“文件不在我這兒了”，?client?再訪問?master?，詢問文件所在的服務器。

根據經驗，這類緩存的命中非常非常高，可能在?99.9%?以上（因為文件的自動遷移是小概率事件），這樣與?master?的交互次數就降低了?1000?倍。

五、水平擴展是提升單點系統性能的好方案

無論怎么批量寫，客戶端緩存，單點畢竟是單機，還是有性能上限的。

想方設法水平擴展，消除系統單點，理論上才能夠無限的提升系統系統。

以?nginx?為例，如何來進行水平擴展呢？

第一步的?DNS?解析，只能返回一個?nginx?外網?IP?么？答案顯然是否定的，?“?DNS輪詢”技術?支持?DNS-server?返回不同的?nginx?外網?IP?，這樣就能實現?nginx?負載均衡層的水平擴展。

DNS-server?部分，一個域名可以配置多個?IP?，每次?DNS?解析請求，輪詢返回不同的?IP?，就能實現?nginx?的水平擴展，擴充負載均衡層的整體性能。

數據庫單點寫庫也是同樣的道理，在數據量很大的情況下，可以通過水平拆分，來提升寫入性能。

遺憾的是，?并不是所有的業務場景都可以水平拆分?，例如秒殺業務，商品的條數可能不多，數據庫的數據量不大，就不能通過水平拆分來提升秒殺系統的整體寫性能（總不能一個庫?100?條記錄吧？）。

六、總結

今天的話題就討論到這里，內容很多，占用大家寶貴的時間深表內疚，估計大部分都記不住，至少記住這幾個點吧：

（?1?）?單點系統存在的問題?：?可用性問題，性能瓶頸問題

（?2?）?shadow-master?是一種常見的解決單點系統可用性問題的方案

（?3?）?減少與單點的交互?，是存在單點的系統優化的核心方向，常見方法有?批量寫，客戶端緩存

（?4?）?水平擴展?也是提升單點系統性能的好方案

如果有收獲，幫忙隨手轉發喲。

==【完】==

http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959480&idx=1&sn=337bd74410a6bef616128fd17abd08a8&scene=0&utm_source=tuicool&utm_medium=referral

轉載于:https://www.cnblogs.com/CoreXin/articles/5688012.html

總結

以上是生活随笔為你收集整理的单点系统架构的可用性与性能优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。