分片
經(jīng)常能夠聽到這樣的建議:“要盡早分片,經(jīng)常分片。”我的建議則大為不同“除非不得已,不要分片”。假如有足夠的經(jīng)驗(yàn),明白不得不分片,那就要對分片做好準(zhǔn)備,但仍然要等到需要分片的時候再進(jìn)行分片。分片存在一些問題。
主要問題是分片現(xiàn)在已經(jīng)很流行,而且人們分片做得太早、太頻繁。我看到的大多數(shù)系統(tǒng),要么已經(jīng)做了分片,要么正在考慮做分片,實(shí)際上根本就不需要一一只需要對目前可用的商品硬件進(jìn)行充分利用即可。以我的觀點(diǎn)看來,對一個中等規(guī)模的應(yīng)用,就要將其構(gòu)建在跨越數(shù)百臺低檔機(jī)器的分片架構(gòu)上,試圖提供無限伸縮能力,是非常愚蠢的。其實(shí),只需要購買幾臺足夠好的機(jī)器,在工程上多做些考慮,就足夠了。對每個睜大眼睛、指著分片的成功故事的人(我曾經(jīng)就是其中之一),我可以給你看一些沒有使用分片的大規(guī)模應(yīng)用,只是靠了幾個聰明的人,就能運(yùn)維這種大規(guī)模應(yīng)用。我的同事,還有我,也曾經(jīng)看到過大量的最流行的分片應(yīng)用,透過表面現(xiàn)象,內(nèi)部卻是資源的極大浪費(fèi)。
分片架構(gòu)比你預(yù)想的要昂貴得多,甚至在短期內(nèi)也是如此,長期則一定如此。這方面的例子有:分片一旦建立,則無法為了重新均衡的目的而再次構(gòu)建;或者使用一種過于簡單的方法,如用簡單的取模算法作為分片函數(shù)。用低劣的工程方法構(gòu)建分片架構(gòu),無疑是一種短視行為,從而也是根本無法實(shí)現(xiàn)可伸縮的。對于真正重要的事情也就很難考慮和設(shè)計(jì),如常見的失效情形。如果要在很多臺機(jī)器上分布應(yīng)用,或哪怕只有幾臺,都要認(rèn)真地考慮失效轉(zhuǎn)移和故障后回切。應(yīng)用程序也可能需要考慮失效的容錯性,假如一部分?jǐn)?shù)據(jù)集不可用,要能夠降級運(yùn)行。
分片的第三個問題涉及過度設(shè)計(jì)(overengineering)的風(fēng)險。大多數(shù)事情都很難做到正好,不是做過頭了,就是沒有做到位。害怕架構(gòu)沒有足夠的靈活性,或害怕不知道怎么做到正好,很容易導(dǎo)致過度設(shè)計(jì)。這不僅使事情過于復(fù)雜,還會產(chǎn)生無休止的麻煩。
寫入多臺主服務(wù)器
存在很多誘惑性的陷阱,其中之一就是,將復(fù)制拓?fù)渲械亩嗯_服務(wù)器配置成可寫的,你認(rèn)為這樣做就萬事大吉了。通常的想法是,“這樣就能夠提高寫操作的性能”或者“所有節(jié)點(diǎn)都是平等的,從而失效轉(zhuǎn)移就容易實(shí)現(xiàn)了。”然而,這兩者都是錯誤的。
在主-主配置中,通過向兩臺主服務(wù)器寫,是無法提高性能的。所有的寫操作都要通過復(fù)制發(fā)送給從服務(wù)器,在每個節(jié)點(diǎn)上都要重復(fù)執(zhí)行該寫操作,所以,寫操作從哪臺服務(wù)器上發(fā)出,是無關(guān)緊要的。
因?yàn)閺?fù)制是異步執(zhí)行的8,在多個位置進(jìn)行寫操作非常容易出錯,而且?guī)缀蹩隙ㄔ诤芏嗲闆r下都會產(chǎn)生麻煩,這些情況包括失效轉(zhuǎn)移、應(yīng)用程序錯誤、程序員錯誤,以及大量的其他常見情形。通常導(dǎo)致的結(jié)果有丟失數(shù)據(jù),以及長時間的、沒日沒夜的苦干,試圖將系統(tǒng)恢復(fù)到合理的、一致的狀態(tài)。試圖說服你的老板或同事不要這樣做,肯定很困難,但一定要試試。
多級復(fù)制
如果可能的話,盡量不要使用多級復(fù)制。使用一臺主服務(wù)器和N臺從服務(wù)器,而不是從服務(wù)器的從服務(wù)器的從服務(wù)器,要簡單得多。麻花鏈鏈的從服務(wù)器結(jié)構(gòu),有的時候是有優(yōu)點(diǎn)的,但可能的話最好避免使用。孫子輩的從服務(wù)器和重孫子輩的從服務(wù)器很難管理,假如在這些從服務(wù)器和位于金字塔頂端的主服務(wù)器之間的中間級別上發(fā)生問題的話。常見的問題有復(fù)制延遲、服務(wù)器崩潰、錯誤以及網(wǎng)絡(luò)問題。
環(huán)形復(fù)制(多于兩個節(jié)點(diǎn))
要像躲避瘟疫一樣避免使用環(huán)形復(fù)制,其失效情形,不管是數(shù)量還是復(fù)雜度,都大得超乎想象。就在幾天前,我接到一個請求支持的電話,那是由5臺服務(wù)器構(gòu)成的環(huán),在試圖移掉其中一臺而用另外的服務(wù)器替換時,卻發(fā)生了語句死循環(huán)的問題。這種架構(gòu)非常脆弱,隨時都會引發(fā)災(zāi)難。
依賴于DNS
我已經(jīng)說過這一點(diǎn),但仍然值得再重復(fù)一次。DNS很脆弱,依賴于DNS最終會自食苦果。將DNS用于域名查詢是沒問題的,但DNS不應(yīng)該受失效轉(zhuǎn)移的影響。不要將循環(huán)DNS∞用于負(fù)載均衡。同理,也不要使用/letc/hosts,對這個文件的版本變更、管理以及部署都要是原子操作。
所謂的實(shí)體一屬性一值(EAV)設(shè)計(jì)模式
每當(dāng)有人對我說,“我有一個托管的多租戶Saas應(yīng)用…”我都能夠補(bǔ)充他的下半句:“你使用的是EAV,而且有性能問題。”在你不知道最終的數(shù)據(jù)模式是什么,或者根本就沒有最終的數(shù)據(jù)模式時,EAV是有誘惑力的。這往往出現(xiàn)在“托管的、多租戶的SaaS應(yīng)用”中,這只是因?yàn)楣鞠脘N售有靈活性的東西。他們想這樣告訴客戶:“不管你的數(shù)據(jù)是什么樣的,都會適合我們的系統(tǒng)的。”但這并不是關(guān)系數(shù)據(jù)庫的工作方式。因?yàn)楹芸炀蜁a(chǎn)生100個表的自連接(self-joins),而產(chǎn)生的查詢計(jì)劃除了由于搜索整個磁盤而產(chǎn)生的隨機(jī)IO之外,不會做更多的事情。這些搜索在網(wǎng)站建設(shè)索引中找到一點(diǎn)兒數(shù)據(jù),然后將這些簡單的值按行拼接起來一一這個過程很慢的。在 MYSQL中,你是無法做100個連接的, MYSQL的限制是每個查詢只能最多對61個表做連接,實(shí)際上不到20個表的時候就已經(jīng)有問題了,因?yàn)閳?zhí)行計(jì)劃的計(jì)算太復(fù)雜了。
本文地址:http://m.blackside-inc.com//article/3320.html