一、需求緣起

明明架構(gòu)要求高可用，?為何系統(tǒng)中還會存在單點(diǎn)？

回答：單點(diǎn)?master?的設(shè)計(jì)，會?大大簡化系統(tǒng)設(shè)計(jì)，何況有時候避免不了單點(diǎn)

在哪些場景中會存在單點(diǎn)？先來看一下一個?典型互聯(lián)網(wǎng)高可用架構(gòu)?。

典型互聯(lián)網(wǎng)高可用架構(gòu)：

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

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

（?3?）?站點(diǎn)層?，?web-server?層，典型的是?tomcat?或者?apache

（?4?）?服務(wù)層?，?service?層，典型的是?dubbo?或者?thrift?等提供?RPC?調(diào)用的后端服務(wù)

（?5?）?數(shù)據(jù)層?，包含?cache?和?db?，典型的是主從復(fù)制讀寫分離的?db?架構(gòu)

在這個互聯(lián)網(wǎng)架構(gòu)中，站點(diǎn)層、服務(wù)層、數(shù)據(jù)庫的從庫都可以通過冗余的方式來保證高可用，但至少

（?1?）?nginx?層是一個潛在的單點(diǎn)

（?2?）數(shù)據(jù)庫?寫庫?master?也是一個潛在的單點(diǎn)

再舉一個?GFS?（?Google File System?）架構(gòu)的例子。

GFS?的系統(tǒng)架構(gòu)里主要有這么幾種角色：

（?1?）?client?，就是發(fā)起文件讀寫的調(diào)用端

（?2?）?master?，這是一個單點(diǎn)服務(wù)，它有全局事業(yè)，掌握文件元信息

（?3?）?chunk-server?，實(shí)際存儲文件額服務(wù)器

這個系統(tǒng)里，?master?也是一個單點(diǎn)的服務(wù)，?Map-reduce?系統(tǒng)里也有類似的全局協(xié)調(diào)的?master?單點(diǎn)角色。

系統(tǒng)架構(gòu)設(shè)計(jì)中，像?nginx?，?db-master?，?gfs-master?這樣的單點(diǎn)服務(wù)，會存在什么問題，有什么方案來優(yōu)化呢，這是本文要討論的問題。

二、單點(diǎn)架構(gòu)存在的問題

單點(diǎn)系統(tǒng)一般來說存在?兩個很大的問題?：

（?1?）?非高可用?：既然是單點(diǎn)，?master?一旦發(fā)生故障，服務(wù)就會受到影響

（?2?）?性能瓶頸?：既然是單點(diǎn)，不具備良好的擴(kuò)展性，服務(wù)性能總有一個上限，這個單點(diǎn)的性能上限往往就是整個系統(tǒng)的性能上限

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

三、?shadow-master?解決單點(diǎn)高可用問題

shadow-master?是一種很常見的解決單點(diǎn)高可用問題的技術(shù)方案。

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

shadow-master?它能夠解決高可用的問題，并且故障的轉(zhuǎn)移是自動的，不需要人工介入，但不足是它使?服務(wù)資源的利用率降為了?50%?，?業(yè)內(nèi)經(jīng)常使用?keepalived+vip的方式實(shí)現(xiàn)這類單點(diǎn)的高可用?。

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

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

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

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

當(dāng)發(fā)現(xiàn)?master?異常時：

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

除了?GFS?與?MapReduce?系統(tǒng)中的主控?master?，?nginx?亦可用類似的方式保證高可用，數(shù)據(jù)庫的主庫?master?（主庫）亦可用類似的方式來保證高可用，只是細(xì)節(jié)上有些地方要注意：

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

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

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

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

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

四、減少與單點(diǎn)的交互，是存在單點(diǎn)的系統(tǒng)優(yōu)化的核心方向

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

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

批量寫

批量寫是一種常見的提升單點(diǎn)性能的方式。

例如一個利用數(shù)據(jù)庫寫單點(diǎn)生成做?“ID?生成器?”?的例子：

（?1?）業(yè)務(wù)方需要?ID

（?2?）利用數(shù)據(jù)庫寫單點(diǎn)的?auto increament id?來生成和返回?ID

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

潛在的問題是：生成?ID?的并發(fā)上限，取決于單點(diǎn)數(shù)據(jù)庫的寫性能上限。

如何提升性能呢？批量寫

（?1?）中間加一個服務(wù)，每次從數(shù)據(jù)庫拿出?100?個?id

（?2?）業(yè)務(wù)方需要?ID

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

這樣一來，每分配?100?個才會寫數(shù)據(jù)庫一次，分配?id?的性能可以認(rèn)為提升了?100倍。

客戶端緩存

客戶端緩存也是一種降低與單點(diǎn)交互次數(shù)，提升系統(tǒng)整體性能的方法。

還是以?GFS?文件系統(tǒng)為例：

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

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

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

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

根據(jù)經(jīng)驗(yàn)，這類緩存的命中非常非常高，可能在?99.9%?以上（因?yàn)槲募淖詣舆w移是小概率事件），這樣與?master?的交互次數(shù)就降低了?1000?倍。

五、水平擴(kuò)展是提升單點(diǎn)系統(tǒng)性能的好方案

無論怎么批量寫，客戶端緩存，單點(diǎn)畢竟是單機(jī)，還是有性能上限的。

想方設(shè)法水平擴(kuò)展，消除系統(tǒng)單點(diǎn)，理論上才能夠無限的提升系統(tǒng)系統(tǒng)。

以?nginx?為例，如何來進(jìn)行水平擴(kuò)展呢？

第一步的?DNS?解析，只能返回一個?nginx?外網(wǎng)?IP?么？答案顯然是否定的，?“?DNS輪詢”技術(shù)?支持?DNS-server?返回不同的?nginx?外網(wǎng)?IP?，這樣就能實(shí)現(xiàn)?nginx?負(fù)載均衡層的水平擴(kuò)展。

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

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

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

六、總結(jié)

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

（?1?）?單點(diǎn)系統(tǒng)存在的問題?：?可用性問題，性能瓶頸問題

（?2?）?shadow-master?是一種常見的解決單點(diǎn)系統(tǒng)可用性問題的方案

（?3?）?減少與單點(diǎn)的交互?，是存在單點(diǎn)的系統(tǒng)優(yōu)化的核心方向，常見方法有?批量寫，客戶端緩存

（?4?）?水平擴(kuò)展?也是提升單點(diǎn)系統(tǒng)性能的好方案

如果有收獲，幫忙隨手轉(zhuǎn)發(fā)喲。

==【完】==

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

轉(zhuǎn)載于:https://www.cnblogs.com/CoreXin/articles/5688012.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。