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

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

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



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

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

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

功能分區。

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

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

失效轉移和負載均衡。

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

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

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

ACID仍然是有意義的。

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

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

使用正確的工具。

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

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

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