下面的數(shù)據(jù)庫架構(gòu)，以我的經(jīng)驗(yàn)，是比較有把握的。
 
單主服務(wù)器，多從服務(wù)器。

對(duì)于主要是讀操作的應(yīng)用，傳統(tǒng)的伸縮方法是對(duì)數(shù)據(jù)進(jìn)行復(fù)制一一有的時(shí)候是多個(gè)復(fù)制這時(shí)候的伸縮可以很好地工作。使用復(fù)制從服務(wù)器分擔(dān)主服務(wù)器的負(fù)載，并在從服務(wù)器上執(zhí)行那些CPU耗時(shí)的操作。

對(duì)于從服務(wù)器，要比你執(zhí)行例行運(yùn)維任務(wù)所需要的數(shù)量要多加一臺(tái)，將這臺(tái)服務(wù)器用于特定任務(wù)。從這臺(tái)服務(wù)器上做備份，然后再將備份恢復(fù)回去，測(cè)試看有沒有問題。在這臺(tái)服務(wù)器上運(yùn)行耗時(shí)的cron作業(yè)，以對(duì)數(shù)據(jù)進(jìn)行匯總，將這些匯總數(shù)據(jù)用于數(shù)據(jù)分析的查詢，然后將結(jié)果導(dǎo)出，再批量導(dǎo)人到主服務(wù)器。使用基于會(huì)話的讀寫分離策略，以分擔(dān)主服務(wù)器的 SELECT查詢。這些事情要在應(yīng)用程序生命周期的早期就開始做。假如一臺(tái)從服務(wù)器失效了，將這臺(tái)從服務(wù)器的工作轉(zhuǎn)到另一臺(tái)從服務(wù)器即可，因?yàn)閺姆?wù)器之間并沒有什么區(qū)別。對(duì)這種簡單的失效轉(zhuǎn)移，可以使用各種負(fù)載均衡器來實(shí)現(xiàn)。



雖然這種架構(gòu)很好，但仍然存在一些令人頭痛的問題:不容易實(shí)現(xiàn)離線的數(shù)據(jù)庫模式更新，因?yàn)橥ǔ?shù)據(jù)庫模式更新是在主服務(wù)器上完成的，在更新時(shí)會(huì)阻塞對(duì)正在進(jìn)行更新的表的訪問。而在 ALTER TABLE命令復(fù)制到從服務(wù)器上時(shí)，復(fù)制可能會(huì)延遲，這樣所分擔(dān)的主服務(wù)器負(fù)載的數(shù)據(jù)就會(huì)過期或延遲。這種主-從架構(gòu)很難自動(dòng)實(shí)現(xiàn)主服務(wù)器的故障轉(zhuǎn)移，因?yàn)橹鞣?wù)器和從服務(wù)器的配置是不一樣的，所以，一旦主服務(wù)器失效，則必須手工進(jìn)行失效轉(zhuǎn)移。不過，這種單一故障點(diǎn)實(shí)際上并不那么脆弱，隨著從服務(wù)器越來越多，從服務(wù)器的失效會(huì)比主服務(wù)器的失效更為常見。

主服務(wù)器一主服務(wù)器復(fù)制，外加從服務(wù)器。

這種方式實(shí)際上與ー臺(tái)主服務(wù)器加多臺(tái)從服務(wù)器的架構(gòu)一樣，但這時(shí)候主服務(wù)器本身也成為了從服務(wù)器。這種架構(gòu)的主要優(yōu)點(diǎn)是，在協(xié)同同的主服務(wù)器之間更容易實(shí)現(xiàn)失效轉(zhuǎn)移和失效轉(zhuǎn)回。這解決了那些令人頭痛的問題，如在線更新數(shù)據(jù)庫模式。主要的缺點(diǎn)是，向兩臺(tái)主服務(wù)器進(jìn)行寫人存在風(fēng)險(xiǎn)，會(huì)導(dǎo)致數(shù)據(jù)存在某種不一致性，這種不一致很難防范，出現(xiàn)了不一致也很難解決。除非你特別小心，并使用特權(quán)級(jí)別進(jìn)行限制，否則，簡直就是期待著導(dǎo)致這種不一致的錯(cuò)誤的發(fā)生。

功能分區(qū)。

隨著應(yīng)用的增長，這倒是個(gè)好主意。將應(yīng)用中成本最高的那些部分移到特定的服務(wù)器或特定服務(wù)器的集群上，例如，將會(huì)話存儲(chǔ)從主服務(wù)器上分離。我經(jīng)?？吹?ldquo;會(huì)話”表吃掉了與其作用不成比例例的大量時(shí)間。為分析查詢另外建立一個(gè)集群，如果需要的話，使用同樣的導(dǎo)出導(dǎo)人策略，將匯總結(jié)果導(dǎo)入主應(yīng)用程序集群。將 Sphinx或Solr集群用于搜索。時(shí)間以及測(cè)量工具會(huì)告訴你，應(yīng)用中哪些部分的成本最高，如果預(yù)先不清楚，則造成延遲的那部分就是了。這種架構(gòu)對(duì)應(yīng)用的支持會(huì)比較長久。

除了前面列出的有把握的架構(gòu)之外，我想下面的建議更有把握。同任何事情一樣，一旦你了解了規(guī)則，就會(huì)常常發(fā)現(xiàn)規(guī)則被破壞的情況，但我認(rèn)為，除非有很好的理由，否則，這些想法不應(yīng)該被丟棄。

失效轉(zhuǎn)移和負(fù)載均衡。

使用負(fù)載均衡器，或者浮動(dòng)的虛擬P地址。就像你知道的，失效轉(zhuǎn)移是很難實(shí)現(xiàn)的。如果有高級(jí)的負(fù)載均衡器，就用上，或者使用對(duì)等的解決方案，即在服務(wù)器之間轉(zhuǎn)移IP地址，如果做得合適的話，這種方案很好，而且也不貴。

不用使用DNS或應(yīng)用程序邏輯。一開始好像很合理，但馬上就會(huì)變成夢(mèng)魘。使用DNS查詢P地址是沒問題的，但不要使用DNS去實(shí)現(xiàn)失效轉(zhuǎn)移。換言之，將DNS作為靜態(tài)的系統(tǒng)對(duì)待，不要依賴于更新DNS、配置文件、應(yīng)用程序中的代碼或諸如此類的任何東西。

不要自動(dòng)化得太多，只讀服務(wù)器很容易實(shí)現(xiàn)失效轉(zhuǎn)移，而可寫的服務(wù)器就難得多。不要試圖構(gòu)建自動(dòng)化的失效轉(zhuǎn)移。有些事情應(yīng)該由人來完成。凌晨3點(diǎn)被叫醒做失效轉(zhuǎn)移，總比6點(diǎn)的時(shí)候被叫醒，然后在接下來的3天沒日沒夜地試圖恢復(fù)數(shù)據(jù)，要好得多。

ACID仍然是有意義的。

從一開始就使用全事務(wù)型系統(tǒng)。非事務(wù)型系統(tǒng)的假設(shè)可能已經(jīng)深深地植入了應(yīng)用程序的代碼中，很難查找與解決了。而后期再切換為事務(wù)型系統(tǒng)，會(huì)導(dǎo)致很多麻煩，如死鎖、鎖等待超時(shí)，以及其他預(yù)想不到的行為。

高可用性要求快速而可靠的災(zāi)難恢復(fù)，所以在 MYSQL中，要使用 INNODB作為存儲(chǔ)引擎，但不要用外鍵、觸發(fā)器、視圖或存儲(chǔ)過程，因?yàn)檫@些東西會(huì)導(dǎo)致復(fù)制問題、性能問題、備份以及其他很多問題。不要將 MYISAM用于讀寫數(shù)據(jù)，因?yàn)闀?huì)導(dǎo)致災(zāi)難，而恢復(fù)起來則需要相當(dāng)長的時(shí)間。

使用正確的工具。

對(duì)每顆釘子來說，數(shù)據(jù)庫都可能成為錘子。這可不是個(gè)好主意。不要使數(shù)據(jù)庫處于關(guān)鍵路徑上，如不要將其用于隊(duì)列(隊(duì)列不能很好地映射到數(shù)據(jù)庫中，而且也是我看到的最常見的麻煩之一)。不要將應(yīng)用程序的靜態(tài)信息放入數(shù)據(jù)庫中，如配置信息、可以放人緩存或應(yīng)用程序代碼中的靜態(tài)查找信息、存儲(chǔ)映像。數(shù)據(jù)庫應(yīng)該存儲(chǔ)數(shù)據(jù)，而非應(yīng)用程序本身。

將數(shù)據(jù)庫簡單化，因?yàn)檫@是最難于伸縮，也是最昂貴的資源。盡可能使用文件和cron作業(yè)。例如，在存入數(shù)據(jù)庫之前，將數(shù)據(jù)預(yù)先進(jìn)行匯總。用簡單的腳本或GNU命令行工具

做匯總，比用網(wǎng)站建設(shè)數(shù)據(jù)庫快幾個(gè)數(shù)量級(jí)!要仔細(xì)研究UNIX的核心工具，如sed、awk、sort和unqo這種做法，跟從 Oracle或 SQL Serverl的世界中學(xué)到的做法比起來，簡直就是對(duì)著干。在 Oracle或 SQL Server的世界中，應(yīng)用程序只是一種建立在大規(guī)模的數(shù)據(jù)庫之上的表現(xiàn)邏 輯，而數(shù)據(jù)庫充滿了表、視圖、觸發(fā)器、存儲(chǔ)過程以及每一項(xiàng)細(xì)小的業(yè)務(wù)邏輯。對(duì)于復(fù)雜的業(yè)務(wù)應(yīng)用，這種集中化的做法有時(shí)候是合適的，而且我自己就在這樣的環(huán)境中工作過。但是，對(duì)于Web應(yīng)用，我還是堅(jiān)持我的觀點(diǎn):分離應(yīng)用程序和數(shù)據(jù)庫，將數(shù)據(jù)庫僅用來存儲(chǔ)和檢索數(shù)據(jù)。