coolfiry

1、一臺服務(wù)器

一 臺別人捐助的服務(wù)器，LJ最初就跑在上面，就像Google開始時候用的破服務(wù)器一樣，值得我們尊敬。這個階段，LJ的人以驚人的速度熟悉的Unix的操 作管理，服務(wù)器性能出現(xiàn)過問題，不過還好，可以通過一些小修小改應(yīng)付過去。在這個階段里L(fēng)J把CGI升級到了FastCGI。

最終問題出現(xiàn)了，網(wǎng)站越來越慢，已經(jīng)無法通過優(yōu)過化來解決的地步，需要更多的服務(wù)器，這時LJ開始提供付費服務(wù)，可能是想通過這些錢來購買新的服務(wù)器，以解決當(dāng)時的困境。
毫無疑問，當(dāng)時LJ存在巨大的單點問題，所有的東西都在那臺服務(wù)器的鐵皮盒子里裝著。

2、兩臺服務(wù)器

用付費服務(wù)賺來的錢LJ買了兩臺服務(wù)器：一臺叫做Kenny的Dell 6U機器用于提供Web服務(wù)，一臺叫做Cartman的Dell 6U服務(wù)器用于提供數(shù)據(jù)庫服務(wù)。

LJ有了更大的磁盤，更多的計算資源。但同時網(wǎng)絡(luò)結(jié)構(gòu)還是非常簡單，每臺機器兩塊網(wǎng)卡，Cartman通過內(nèi)網(wǎng)為Kenny提供MySQL數(shù)據(jù)庫服務(wù)。

暫時解決了負(fù)載的問題，新的問題又出現(xiàn)了：

• 原來的一個單點變成了兩個單點。
• 沒有冷備份或熱備份。
• 網(wǎng)站速度慢的問題又開始出現(xiàn)了，沒辦法，增長太快了。
• Web服務(wù)器上CPU達(dá)到上限，需要更多的Web服務(wù)器。

3、四臺服務(wù)器

又買了兩臺，Kyle和Stan，這次都是1U的，都用于提供Web服務(wù)。目前LJ一共有3臺Web服務(wù)器和一臺數(shù)據(jù)庫服務(wù)器。這時需要在3臺Web服務(wù)器上進行負(fù)載均橫。

LJ把Kenny用于外部的網(wǎng)關(guān)，使用mod_backhand進行負(fù)載均橫。

然后問題又出現(xiàn)了：

• 單點故障。數(shù)據(jù)庫和用于做網(wǎng)關(guān)的Web服務(wù)器都是單點，一旦任何一臺機器出現(xiàn)問題將導(dǎo)致所有服務(wù)不可用。雖然用于做網(wǎng)關(guān)的Web服務(wù)器可以通過保持心跳同步迅速切換，但還是無法解決數(shù)據(jù)庫的單點，LJ當(dāng)時也沒做這個。
• 網(wǎng)站又變慢了，這次是因為IO和數(shù)據(jù)庫的問題，問題是怎么往應(yīng)用里面添加數(shù)據(jù)庫呢？

4、五臺服務(wù)器

又買了一臺數(shù)據(jù)庫服務(wù)器。在兩臺數(shù)據(jù)庫服務(wù)器上使用了數(shù)據(jù)庫同步(Mysql支持的Master-Slave模式)，寫操作全部針對主數(shù)據(jù)庫（通過Binlog，主服務(wù)器上的寫操作可以迅速同步到從服務(wù)器上），讀操作在兩個數(shù)據(jù)庫上同時進行(也算是負(fù)載均橫的一種吧)。

實現(xiàn)同步時要注意幾個事項：

• 讀操作數(shù)據(jù)庫選擇算法處理，要選一個當(dāng)前負(fù)載輕一點的數(shù)據(jù)庫。
• 在從數(shù)據(jù)庫服務(wù)器上只能進行讀操作
• 準(zhǔn)備好應(yīng)對同步過程中的延遲，處理不好可能會導(dǎo)致數(shù)據(jù)庫同步的中斷。只需要對寫操作進行判斷即可，讀操作不存在同步問題。

5、更多服務(wù)器

有錢了，當(dāng)然要多買些服務(wù)器。部署后快了沒多久，又開始慢了。這次有更多的Web服務(wù)器，更多的數(shù)據(jù)庫服務(wù)器，存在 IO與CPU爭用。于是采用了BIG-IP作為負(fù)載均衡解決方案。

6、現(xiàn)在我們在哪里：

現(xiàn)在服務(wù)器基本上夠了，但性能還是有問題，原因出在架構(gòu)上。

數(shù)據(jù)庫的架構(gòu)是最大的問題。由于增加的數(shù)據(jù)庫都是以Slave模式添加到應(yīng)用內(nèi)，這樣唯一的好處就是將讀操作分布到了多臺機器，但這樣帶來的后果就是寫操作被大量分發(fā)，每臺機器都要執(zhí)行，服務(wù)器越多，浪費就越大，隨著寫操作的增加，用于服務(wù)讀操作的資源越來越少。

由一臺分布到兩臺

最終效果

現(xiàn)在我們發(fā)現(xiàn)，我們并不需要把這些數(shù)據(jù)在如此多的服務(wù)器上都保留一份。服務(wù)器上已經(jīng)做了RAID，數(shù)據(jù)庫也進行了備份，這么多的備份完全是對資源的浪費，屬于冗余極端過度。那為什么不把數(shù)據(jù)分布存儲呢？

問題發(fā)現(xiàn)了，開始考慮如何解決。現(xiàn)在要做的就是把不同用戶的數(shù)據(jù)分布到不同的服務(wù)器上進行存儲，以實現(xiàn)數(shù)據(jù)的分布式存儲，讓每臺機器只為相對固定的用戶服務(wù)，以實現(xiàn)平行的架構(gòu)和良好的可擴展性。

為 了實現(xiàn)用戶分組，我們需要為每一個用戶分配一個組標(biāo)記，用于標(biāo)記此用戶的數(shù)據(jù)存放在哪一組數(shù)據(jù)庫服務(wù)器中。每組數(shù)據(jù)庫由一個master及幾個slave 組成，并且slave的數(shù)量在2-3臺，以實現(xiàn)系統(tǒng)資源的最合理分配，既保證數(shù)據(jù)讀操作分布，又避免數(shù)據(jù)過度冗余以及同步操作對系統(tǒng)資源的過度消耗。

由一臺（一組）中心服務(wù)器提供用戶分組控制。所有用戶的分組信息都存儲在這臺機器上，所有針對用戶的操作需要先查詢這臺機器得到用戶的組號，然后再到相應(yīng)的數(shù)據(jù)庫組中獲取數(shù)據(jù)。

這樣的用戶架構(gòu)與目前LJ的架構(gòu)已經(jīng)很相像了。

在具體的實現(xiàn)時需要注意幾個問題：

• 在數(shù)據(jù)庫組內(nèi)不要使用自增ID，以便于以后在數(shù)據(jù)庫組之間遷移用戶，以實現(xiàn)更合理的I/O，磁盤空間及負(fù)載分布。
• 將userid，postid存儲在全局服務(wù)器上，可以使用自增，數(shù)據(jù)庫組中的相應(yīng)值必須以全局服務(wù)器上的值為準(zhǔn)。全局服務(wù)器上使用事務(wù)型數(shù)據(jù)庫InnoDB。
• 在數(shù)據(jù)庫組之間遷移用戶時要萬分小心，當(dāng)遷移時用戶不能有寫操作。

7、現(xiàn)在我們在哪里

問題：

• 一個全局主服務(wù)器，掛掉的話所有用戶注冊及寫操作就掛掉。
• 每個數(shù)據(jù)庫組一個主服務(wù)器，掛掉的話這組用戶的寫操作就掛掉。
• 數(shù)據(jù)庫組從服務(wù)器掛掉的話會導(dǎo)致其它服務(wù)器負(fù)載過大。

對于Master-Slave模式的單點問題，LJ采取了Master-Master模式來解決。所謂Master-Master實際上是人工實現(xiàn)的，并不是由MySQL直接提供的，實際上也就是兩臺機器同時是Master，也同時是Slave，互相同步。

Master-Master實現(xiàn)時需要注意：

• 一個Master出錯后恢復(fù)同步，最好由服務(wù)器自動完成。
• 數(shù)字分配，由于同時在兩臺機器上寫，有些ID可能會沖突。

解決方案：

• 奇偶數(shù)分配ID，一臺機器上寫奇數(shù)，一臺機器上寫偶數(shù)
• 通過全局服務(wù)器進行分配(LJ采用的做法)。

 

Master-Master模式還有一種用法，這種方法與前一種相比，仍然保持兩臺機器的同步，但只有一臺機器提供服務(wù)（讀和寫），在每天晚上的時候進行輪換，或者出現(xiàn)問題的時候進行切換。

8、現(xiàn)在我們在哪里

現(xiàn)在插播一條廣告，MyISAM VS InnoDB。

使用InnoDB：

• 支持事務(wù)
• 需要做更多的配置，不過值得，可以更安全的存儲數(shù)據(jù)，以及得到更快的速度。

使用MyISAM：

• 記錄日志（LJ用它來記網(wǎng)絡(luò)訪問日志）
• 存儲只讀靜態(tài)數(shù)據(jù)，足夠快。
• 并發(fā)性很差，無法同時讀寫數(shù)據(jù)（添加數(shù)據(jù)可以）
• MySQL非正常關(guān)閉或死機時會導(dǎo)致索引錯誤，需要使用myisamchk修復(fù)，而且當(dāng)訪問量大時出現(xiàn)非常頻繁。

9、緩存

去年我寫過一篇文章介紹memcached，它就是由LJ的團隊開發(fā)的一款緩存工具，以key-value的方式將數(shù)據(jù)存儲到分布的內(nèi)存中。LJ緩存的數(shù)據(jù)：

• 12臺獨立服務(wù)器（不是捐贈的）
• 28個實例
• 30GB總?cè)萘?
• 90-93%的命中率（用過squid的人可能知道，squid內(nèi)存加磁盤的命中率大概在70-80%）

如何建立緩存策略？

想緩存所有的東西？那是不可能的，我們只需要緩存已經(jīng)或者可能導(dǎo)致系統(tǒng)瓶頸的地方，最大程度的提交系統(tǒng)運行效率。通過對MySQL的日志的分析我們可以找到緩存的對象。

緩存的缺點？

• 沒有完美的事物，緩存也有缺點：
• 增大開發(fā)量，需要針對緩存處理編寫特殊的代碼。
• 管理難度增加，需要更多人參與系統(tǒng)維護。
• 當(dāng)然大內(nèi)存也需要錢。

10、Web訪問負(fù)載均衡

在數(shù)據(jù)包級別使用BIG-IP，但BIG-IP并不知道我們內(nèi)部的處理機制，無法判斷由哪臺服務(wù)器對這些請求進行處理。反向代理并不能很好的起到作用，不是已經(jīng)夠快了，就是達(dá)不到我們想要的效果。

所以，LJ又開發(fā)了Perlbal。特點：

• 快，小，可管理的http web 服務(wù)器/代理
• 可以在內(nèi)部進行轉(zhuǎn)發(fā)
• 使用Perl開發(fā)
• 單線程，異步，基于事件，使用epoll , kqueue
• 支持Console管理與http遠(yuǎn)程管理，支持動態(tài)配置加載
• 多種模式：web服務(wù)器，反向代理，插件
• 支持插件：GIF/PNG互換？

11、MogileFS

LJ使用開源的MogileFS作為分布式文件存儲系統(tǒng)。MogileFS使用非常簡單，它的主要設(shè)計思想是：

• 文件屬于類（類是最小的復(fù)制單位）
• 跟蹤文件存儲位置
• 在不同主機上存儲
• 使用MySQL集群統(tǒng)一存儲分布信息
• 大容易廉價磁盤

到目前為止就這么多了，更多文檔可以在http://www.danga.com/words/找到。Danga.com和LiveJournal.com的 同學(xué)們拿這個文檔參加了兩次MySQL Con，兩次OS Con，以及眾多的其它會議，無私的把他們的經(jīng)驗分享出來，值得我們學(xué)習(xí)。在web2.0時代快速開發(fā)得到大家越來越多的重視，但良好的設(shè)計仍是每一個應(yīng) 用的基礎(chǔ)，希望web2.0們在成長為Top500網(wǎng)站的路上，不要因為架構(gòu)阻礙了網(wǎng)站的發(fā)展。

 http://blog.csdn.net/xmr_gxcfe/archive/2007/09/14/1785292.aspx