這里的架構(gòu)和設計模式存在很多問題，有些只用于非常有限的幾種環(huán)境中，之所以在這幾種環(huán)境中有用，是因為你真的明白在做什么。要是這樣的話，你可以跳過這章不讀。但為了使我的說法能夠安全地適用于所有情況，我建議你不要使用這些架構(gòu)。

分片

經(jīng)常能夠聽到這樣的建議:“要盡早分片，經(jīng)常分片。”我的建議則大為不同“除非不得已，不要分片”。假如有足夠的經(jīng)驗，明白不得不分片，那就要對分片做好準備，但仍然要等到需要分片的時候再進行分片。分片存在一些問題。

主要問題是分片現(xiàn)在已經(jīng)很流行，而且人們分片做得太早、太頻繁。我看到的大多數(shù)系統(tǒng)，要么已經(jīng)做了分片，要么正在考慮做分片，實際上根本就不需要一一只需要對目前可用的商品硬件進行充分利用即可。以我的觀點看來，對一個中等規(guī)模的應用，就要將其構(gòu)建在跨越數(shù)百臺低檔機器的分片架構(gòu)上，試圖提供無限伸縮能力，是非常愚蠢的。其實，只需要購買幾臺足夠好的機器，在工程上多做些考慮，就足夠了。對每個睜大眼睛、指著分片的成功故事的人(我曾經(jīng)就是其中之一)，我可以給你看一些沒有使用分片的大規(guī)模應用，只是靠了幾個聰明的人，就能運維這種大規(guī)模應用。我的同事，還有我，也曾經(jīng)看到過大量的*流行的分片應用，透過表面現(xiàn)象，內(nèi)部卻是資源的*大浪費。

分片架構(gòu)比你預想的要昂貴得多，甚至在短期內(nèi)也是如此，長期則一定如此。這方面的例子有:分片一旦建立，則無法為了重新均衡的目的而再次構(gòu)建；或者使用一種過于簡單的方法，如用簡單的取模算法作為分片函數(shù)。用低劣的工程方法構(gòu)建分片架構(gòu)，無疑是一種短視行為，從而也是根本無法實現(xiàn)可伸縮的。對于真正重要的事情也就很難考慮和設計，如常見的失效情形。如果要在很多臺機器上分布應用，或哪怕只有幾臺，都要認真地考慮失效轉(zhuǎn)移和故障后回切。應用程序也可能需要考慮失效的容錯性，假如一部分數(shù)據(jù)集不可用，要能夠降級運行。

分片的第三個問題涉及過度設計(overengineering)的風險。大多數(shù)事情都很難做到正好，不是做過頭了，就是沒有做到位。害怕架構(gòu)沒有足夠的靈活性，或害怕不知道怎么做到正好，很容易導致過度設計。這不僅使事情過于復雜，還會產(chǎn)生無休止的麻煩。

寫入多臺主服務器

存在很多誘惑性的陷阱，其中之一就是，將復制拓撲中的多臺服務器配置成可寫的，你認為這樣做就萬事大吉了。通常的想法是，“這樣就能夠提高寫操作的性能”或者“所有節(jié)點都是平等的，從而失效轉(zhuǎn)移就容易實現(xiàn)了。”然而，這兩者都是錯誤的。
 
在主-主配置中，通過向兩臺主服務器寫，是無法提高性能的。所有的寫操作都要通過復制發(fā)送給從服務器，在每個節(jié)點上都要重復執(zhí)行該寫操作，所以，寫操作從哪臺服務器上發(fā)出，是無關(guān)緊要的。

因為復制是異步執(zhí)行的8，在多個位置進行寫操作非常容易出錯，而且?guī)缀蹩隙ㄔ诤芏嗲闆r下都會產(chǎn)生麻煩，這些情況包括失效轉(zhuǎn)移、應用程序錯誤、程序員錯誤，以及大量的其他常見情形。通常導致的結(jié)果有丟失數(shù)據(jù)，以及長時間的、沒日沒夜的苦干，試圖將系統(tǒng)恢復到合理的、一致的狀態(tài)。試圖說服你的老板或同事不要這樣做，肯定很困難，但一定要試試。

多級復制

如果可能的話，盡量不要使用多級復制。使用一臺主服務器和N臺從服務器，而不是從服務器的從服務器的從服務器，要簡單得多。麻花鏈鏈的從服務器結(jié)構(gòu)，有的時候是有優(yōu)點的，但可能的話*好避免使用。孫子輩的從服務器和重孫子輩的從服務器很難管理，假如在這些從服務器和位于金字塔頂端的主服務器之間的中間級別上發(fā)生問題的話。常見的問題有復制延遲、服務器崩潰、錯誤以及網(wǎng)絡問題。

環(huán)形復制(多于兩個節(jié)點)

要像躲避瘟疫一樣避免使用環(huán)形復制，其失效情形，不管是數(shù)量還是復雜度，都大得超乎想象。就在幾天前，我接到一個請求支持的電話，那是由5臺服務器構(gòu)成的環(huán)，在試圖移掉其中一臺而用另外的服務器替換時，卻發(fā)生了語句死循環(huán)的問題。這種架構(gòu)非常脆弱，隨時都會引發(fā)災難。

依賴于DNS

我已經(jīng)說過這一點，但仍然值得再重復一次。DNS很脆弱，依賴于DNS*終會自食苦果。將DNS用于域名查詢是沒問題的，但DNS不應該受失效轉(zhuǎn)移的影響。不要將循環(huán)DNS∞用于負載均衡。同理，也不要使用/letc/hosts，對這個文件的版本變更、管理以及部署都要是原子操作。

所謂的實體一屬性一值(EAV)設計模式

每當有人對我說，“我有一個托管的多租戶Saas應用…”我都能夠補充他的下半句：“你使用的是EAV，而且有性能問題。”在你不知道*終的數(shù)據(jù)模式是什么，或者根本就沒有*終的數(shù)據(jù)模式時，EAV是有誘惑力的。這往往出現(xiàn)在“托管的、多租戶的SaaS應用”中，這只是因為公司想銷售有靈活性的東西。他們想這樣告訴客戶:“不管你的數(shù)據(jù)是什么樣的，都會適合我們的系統(tǒng)的。”但這并不是關(guān)系數(shù)據(jù)庫的工作方式。因為很快就會產(chǎn)生100個表的自連接(self-joins)，而產(chǎn)生的查詢計劃除了由于搜索整個磁盤而產(chǎn)生的隨機IO之外，不會做更多的事情。這些搜索在網(wǎng)站建設索引中找到一點兒數(shù)據(jù)，然后將這些簡單的值按行拼接起來一一這個過程很慢的。在 MYSQL中，你是無法做100個連接的， MYSQL的限制是每個查詢只能*多對61個表做連接，實際上不到20個表的時候就已經(jīng)有問題了，因為執(zhí)行計劃的計算太復雜了。