欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

1、一臺服務(wù)器

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

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

2、兩臺服務(wù)器

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

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

暫時(shí)解決了負載的問(wèn)題，新的問(wèn)題又出現了：

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

3、四臺服務(wù)器

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

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

然后問(wèn)題又出現了：

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

4、五臺服務(wù)器

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

實(shí)現同步時(shí)要注意幾個(gè)事項：

• 讀操作數據庫選擇算法處理，要選一個(gè)當前負載輕一點(diǎn)的數據庫。
• 在從數據庫服務(wù)器上只能進(jìn)行讀操作
• 準備好應對同步過(guò)程中的延遲，處理不好可能會(huì )導致數據庫同步的中斷。只需要對寫(xiě)操作進(jìn)行判斷即可，讀操作不存在同步問(wèn)題。

5、更多服務(wù)器

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

6、現在我們在哪里：

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

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

由一臺分布到兩臺

最終效果

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

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

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

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

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

在具體的實(shí)現時(shí)需要注意幾個(gè)問(wèn)題：

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

7、現在我們在哪里

問(wèn)題：

• 一個(gè)全局主服務(wù)器，掛掉的話(huà)所有用戶(hù)注冊及寫(xiě)操作就掛掉。
• 每個(gè)數據庫組一個(gè)主服務(wù)器，掛掉的話(huà)這組用戶(hù)的寫(xiě)操作就掛掉。
• 數據庫組從服務(wù)器掛掉的話(huà)會(huì )導致其它服務(wù)器負載過(guò)大。

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

Master-Master實(shí)現時(shí)需要注意：

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

解決方案：

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

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

8、現在我們在哪里

現在插播一條廣告，MyISAM VS InnoDB。

使用InnoDB：

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

使用MyISAM：

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

9、緩存

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

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

如何建立緩存策略？

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

緩存的缺點(diǎn)？

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

10、Web訪(fǎng)問(wèn)負載均衡

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

所以，LJ又開(kāi)發(fā)了Perlbal。特點(diǎn)：

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

11、MogileFS

LJ使用開(kāi)源的MogileFS作為分布式文件存儲系統。MogileFS使用非常簡(jiǎn)單，它的主要設計思想是：

• 文件屬于類(lèi)（類(lèi)是最小的復制單位）
• 跟蹤文件存儲位置
• 在不同主機上存儲
• 使用MySQL集群統一存儲分布信息
• 大容易廉價(jià)磁盤(pán)

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

參考資料：http://www.danga.com/words/2005_oscon/oscon-2005.pdf

感謝向靜推薦了這篇文檔給我。