我們虛構的應用將是每天24小時(shí)一直在線(xiàn)。在流量上將會(huì )有浪涌和波峰，隨著(zhù)美國的東西海岸起床時(shí)間不同，每天會(huì )有兩次波峰。而且我們的波峰足夠高，從而能夠在平緩期進(jìn)行維護操作，但不能停機，只能減少容量來(lái)做這些維護操作。停機會(huì )直接影響系統底線(xiàn)。將來(lái)，我們會(huì )擴展到歐洲和亞洲，從而停機就更不可行了。會(huì )有季節性的高流量，在某些流行網(wǎng)站的首頁(yè)也可能會(huì )提到我們，從而導致流量驟增。沒(méi)關(guān)系一一我們可以將功能降級，而不是垮掉。
數據庫的讀操作將占95%，而寫(xiě)占5%。多數寫(xiě)操作都是單行的，會(huì )有一些復雜查詢(xún)。這些查詢(xún)會(huì )非常耗時(shí)，為了提高效率，不得不把一些匯總預先計算出來(lái)，或對某些數據做非規范化處理，這將是一個(gè)非非常耗CPU的過(guò)程。我們將把這些耗時(shí)的分析工作的成本分推到整天，這樣一來(lái)，所用的數據會(huì )稍微有些過(guò)時(shí)。有日時(shí)候使用這些過(guò)時(shí)的數據是沒(méi)問(wèn)題的，而有的時(shí)候，我們不得不在一天之內對數據進(jìn)行逐步的增量更新。
數據庫模式的問(wèn)題還沒(méi)有解決；應用還沒(méi)有成熟，正在快速開(kāi)發(fā)中，包括數據庫模式也在不斷變化。結果就是必須進(jìn)行在線(xiàn)部署。從而不得不在生產(chǎn)環(huán)境中運行 ALTER TABLE，作為更新數據庫模式的例行手段，而且還不能影響可用性。我們知道數據會(huì )越來(lái)越大，而ALTER花費的時(shí)間也會(huì )越來(lái)越長(cháng)，以至于長(cháng)到無(wú)法忍受。
持續增長(cháng)的負載會(huì )超過(guò)單臺服務(wù)器的能力。能走多遠并不重要，因為只有三個(gè)數:零、1和多。無(wú)論如何，我們都不認為應用會(huì )增長(cháng)到互聯(lián)網(wǎng)的規模，所以我們會(huì )考慮幾臺到幾十臺之間的情況。
在一定范圍內的數據丟失是可以接受的。如果一臺服務(wù)器消失了一段時(shí)間，將會(huì )損失一小筆錢(qián)，但將會(huì )無(wú)顏面對管理機構。不管怎么說(shuō)，我們還是強烈希望數據庫服務(wù)器是高可用的，要求一年的容機時(shí)間加起來(lái)不要超過(guò)一天。因為，5分鐘的宕機時(shí)間比損失5分鐘的數據要昂貴得多。
為了災難恢復的目的，我們要求數據庫在最壞情況下能夠恢復到昨天的數據，而在多數情況下，我們當然希望能夠恢復到剛才的數據，使損失的數據不多于幾秒鐘。希望通常情況下恢復過(guò)程不要超過(guò)一小時(shí)，而在最壞情況，如損失大量的數據或服務(wù)器，則希望恢復時(shí)間不多于一天。
團隊對數據庫只有一般的能力，我們的團隊實(shí)際上是 Ruby on Rails的專(zhuān)家，所以高級的數據庫問(wèn)題還是需要外部的幫助。系統管理團隊也非常優(yōu)秀，但同樣不太擅長(cháng)數據庫。
記住這些，我們來(lái)看看如何滿(mǎn)足這些需求。
易于成功的事情
開(kāi)始研究特定的架構之前，我想指出一些需要計劃劃的事情，而不管最終的架構是什么：
● 要做的第一件事是增加緩存層。memcached非常好用，使用 memcached可以為數據庫減輕太多的負載，不用它簡(jiǎn)直太蠢了。
● 不要讓用戶(hù)產(chǎn)生異常情況，如有10000個(gè)好友，或者1000張.照片。對于你認為成本昂貴的那些關(guān)鍵區域，要限制規模，不要允許無(wú)限制的增長(cháng)，就可以將事情保持在合理的范圍內，而不會(huì )等到出現問(wèn)題時(shí)，再向那些導致異常的人發(fā)火。防患于未然，就不會(huì )出現令人驚訝的事情，從而也就構成了良好的用戶(hù)體驗的一部分。
● 對待需求要小心，不要將自己的網(wǎng)站建設標準立得高于用戶(hù)的期望，不要為應用構建太昂貴的功能。顯示搜索結果的精確數量，以及精確的搜索結果頁(yè)面，就是一個(gè)經(jīng)典的錯誤。Google不這樣做，所以你也不需要這樣做。
本文地址：http://havencoinwallet.com//article/3318.html
