門戶級(jí)UGC系統(tǒng)的技術(shù)進(jìn)化路線——新浪新聞評(píng)論系統(tǒng)的架構(gòu)演進(jìn)和經(jīng)驗(yàn)總結(jié)

wang290

評(píng)論系統(tǒng)，或者稱為跟帖、留言板，是所有門戶網(wǎng)站的核心標(biāo)準(zhǔn)服務(wù)組件之一。與論壇、博客等其他互聯(lián)網(wǎng)UGC系統(tǒng)相比，評(píng)論系統(tǒng)雖然從產(chǎn)品功能角度衡量相對(duì)簡(jiǎn)單，但因?yàn)樾枰�能夠在突發(fā)熱點(diǎn)新聞事件時(shí)，在沒(méi)有任何預(yù)警和準(zhǔn)備的前提下支撐住短短幾分鐘內(nèi)上百倍甚至更高的訪問(wèn)量暴漲，而評(píng)論系統(tǒng)既無(wú)法像靜態(tài)新聞內(nèi)容業(yè)務(wù)那樣通過(guò)CDN和反向代理等中間緩存手段化解沖擊，也不可能在平時(shí)儲(chǔ)備大量冗余設(shè)備應(yīng)對(duì)突發(fā)新聞，所以如何在有限的設(shè)備資源條件下提升系統(tǒng)的抗壓性和伸縮性，也是對(duì)一個(gè)貌似簡(jiǎn)單的UGC系統(tǒng)的不小考驗(yàn)。
新聞評(píng)論系統(tǒng)的起源新浪網(wǎng)很早就在新聞中提供了評(píng)論功能，最開(kāi)始是使用Perl語(yǔ)言開(kāi)發(fā)的簡(jiǎn)單腳本，目前能找到的最早具備評(píng)論功能的新聞是2000年4月7日的，經(jīng)過(guò)多次系統(tǒng)升級(jí)，2014年前的評(píng)論地址已經(jīng)失效了，但數(shù)據(jù)仍保存在數(shù)據(jù)庫(kù)中。直到今天，評(píng)論仍是國(guó)內(nèi)所有新聞網(wǎng)站的標(biāo)配功能。
評(píng)論系統(tǒng)3.02003年左右，我接手負(fù)責(zé)評(píng)論系統(tǒng)，系統(tǒng)版本為3.0。當(dāng)時(shí)的評(píng)論系統(tǒng)運(yùn)行在單機(jī)環(huán)境，一臺(tái)x86版本Solaris系統(tǒng)的Dell 6300服務(wù)器提供了全部服務(wù)，包括MySQL和Apache，以及所有前后臺(tái)CGI程序，使用C++開(kāi)發(fā)。

圖1  3.0系統(tǒng)流程和架構(gòu)

3.0系統(tǒng)的緩存模塊設(shè)計(jì)得比較巧妙，以顯示頁(yè)面為單位緩存數(shù)據(jù)，因?yàn)樵u(píng)論頁(yè)面依照提交時(shí)間降序排列，每新增一條評(píng)論，所有帖子都需要向下移動(dòng)一位，所以緩存格式設(shè)計(jì)為每?jī)身?yè)數(shù)據(jù)一個(gè)文件，前后相鄰的兩個(gè)文件有一頁(yè)數(shù)據(jù)重復(fù)，最新的緩存文件通常情況下不滿兩頁(yè)數(shù)據(jù)。

圖2  頁(yè)面緩存算法示意圖

圖2是假設(shè)評(píng)論總數(shù)95條，每頁(yè)顯示20條時(shí)的頁(yè)面緩存結(jié)構(gòu)，此時(shí)用戶看到的第一頁(yè)數(shù)據(jù)讀取自“緩存頁(yè)4”的95~76，第二頁(yè)數(shù)據(jù)讀取自“緩存頁(yè)3”的75~56，以此類推。
這樣發(fā)帖動(dòng)作對(duì)應(yīng)的緩存更新可簡(jiǎn)化為一次文件追加寫操作，效率最高。而且可保證任意評(píng)論總量和顯示順序下的翻頁(yè)動(dòng)作，都可在一個(gè)緩存文件中讀到所需的全部數(shù)據(jù)，而不需要跨頁(yè)讀取再合并。缺點(diǎn)是更新評(píng)論狀態(tài)時(shí)（如刪除），需要清空自被刪除帖子開(kāi)始的所有后續(xù)緩存文件。緩存模塊采取主動(dòng)+被動(dòng)更新模式，發(fā)帖為主動(dòng)，每次發(fā)帖后觸發(fā)一次頁(yè)面緩存追加寫操作。更新評(píng)論狀態(tài)為被動(dòng)，所涉及緩存頁(yè)面文件會(huì)被清空，直到下一次用戶讀取頁(yè)面緩存時(shí)再連接數(shù)據(jù)庫(kù)完成查詢，然后更新頁(yè)面緩存，以備下次讀取。這個(gè)針對(duì)發(fā)帖優(yōu)化的頁(yè)面緩存算法繼續(xù)沿用到了后續(xù)版本的評(píng)論系統(tǒng)中。
此時(shí)的評(píng)論系統(tǒng)就已具備了將同一專題事件下所有新聞評(píng)論匯總顯示的能力，在很長(zhǎng)一段時(shí)間內(nèi)這都是新浪評(píng)論系統(tǒng)的獨(dú)有功能。
雖然3.0系統(tǒng)基本滿足了當(dāng)時(shí)的產(chǎn)品需求，但畢竟是單機(jī)系統(tǒng)，熱點(diǎn)新聞時(shí)瞬間涌來(lái)的大量發(fā)帖和讀取操作，經(jīng)常會(huì)壓垮這臺(tái)當(dāng)時(shí)已屬高配的4U服務(wù)器，頻繁顯示資源耗盡的錯(cuò)誤頁(yè)面。我接手后的首要任務(wù)就是盡量在最短時(shí)間內(nèi)最大限度降低系統(tǒng)的宕機(jī)頻率，通過(guò)觀察分析確定主要性能瓶頸在數(shù)據(jù)庫(kù)層面。
3.0系統(tǒng)中，每個(gè)新聞?lì)l道的全部評(píng)論數(shù)據(jù)都保存在一張MyISAM表中，部分頻道的數(shù)據(jù)量已經(jīng)超過(guò)百萬(wàn)，在當(dāng)時(shí)已屬海量規(guī)模，而且只有一個(gè)數(shù)據(jù)庫(kù)實(shí)例，讀寫競(jìng)爭(zhēng)非常嚴(yán)重。一旦有評(píng)論狀態(tài)更新，就會(huì)導(dǎo)致很多緩存頁(yè)面失效，瞬間引發(fā)大量數(shù)據(jù)庫(kù)查詢，進(jìn)一步加劇了讀寫競(jìng)爭(zhēng)。當(dāng)所有CGI進(jìn)程都阻塞在數(shù)據(jù)庫(kù)環(huán)節(jié)無(wú)法退出時(shí)，殃及Apache，進(jìn)而導(dǎo)致系統(tǒng)Load值急劇上升無(wú)法響應(yīng)任何操作，只有重啟才能恢復(fù)。
解決方案是增加了一臺(tái)FreeBSD系統(tǒng)的低配服務(wù)器用于數(shù)據(jù)庫(kù)分流，當(dāng)時(shí)MySQL的版本是3.23，Replication主從同步還未發(fā)布，采取的辦法是每天給數(shù)據(jù)表減肥，把超過(guò)一周的評(píng)論數(shù)據(jù)搬到2號(hào)服務(wù)器上，保證主服務(wù)器的評(píng)論表數(shù)據(jù)量維持在合理范圍，在這樣的臨時(shí)方案下，3.0系統(tǒng)又撐了幾個(gè)月。
現(xiàn)在看來(lái)，在相當(dāng)簡(jiǎn)陋的系統(tǒng)架構(gòu)下，新浪評(píng)論系統(tǒng)3.0與中國(guó)互聯(lián)網(wǎng)產(chǎn)業(yè)的門戶時(shí)代一起經(jīng)歷了南海撞機(jī)、911劫機(jī)、非典、孫志剛等新聞事件。
評(píng)論系統(tǒng)4.0啟動(dòng)2004年左右，運(yùn)行了近三年的3.0系統(tǒng)已無(wú)法支撐新浪新聞流量的持續(xù)上漲，技術(shù)部門啟動(dòng)了4.0計(jì)劃，核心需求就是三個(gè)字：不宕機(jī)。
因?yàn)楫?dāng)時(shí)我還負(fù)責(zé)了新浪聊天系統(tǒng)的工作，不得不分身應(yīng)對(duì)新舊系統(tǒng)的開(kāi)發(fā)維護(hù)和其他項(xiàng)目任務(wù)，所以在現(xiàn)有評(píng)論系統(tǒng)線上服務(wù)不能中斷的前提下，制定了數(shù)據(jù)庫(kù)結(jié)構(gòu)不變，歷史數(shù)據(jù)全部保留，雙系統(tǒng)逐步無(wú)縫切換，升級(jí)期間新舊系統(tǒng)并存的大方針。
第一階段：文件系統(tǒng)代替數(shù)據(jù)庫(kù)，基于ICE的分布式系統(tǒng)既然3.0系統(tǒng)數(shù)據(jù)庫(kù)結(jié)構(gòu)不可變，除了把數(shù)據(jù)庫(kù)升級(jí)到MySQL 4.0啟用Repliaction分解讀寫壓力以外，最開(kāi)始的設(shè)計(jì)重點(diǎn)是如何把數(shù)據(jù)庫(kù)與用戶行為隔離開(kāi)。
解決方案是在MySQL數(shù)據(jù)庫(kù)和頁(yè)面緩存模塊之間，新建一個(gè)帶索引的數(shù)據(jù)文件層，每條新聞的所有評(píng)論都單獨(dú)保存在一個(gè)索引文件和一個(gè)數(shù)據(jù)文件中，期望通過(guò)把對(duì)數(shù)據(jù)庫(kù)單一表文件的讀寫操作，分解為文件系統(tǒng)上互不干涉可并發(fā)執(zhí)行的讀寫操作，來(lái)提高系統(tǒng)并發(fā)處理能力。在新的索引數(shù)據(jù)模塊中，查詢?cè)u(píng)論總數(shù)、追加評(píng)論、更新評(píng)論狀態(tài)都是針對(duì)性優(yōu)化過(guò)的高效率操作。從這時(shí)起，MySQL數(shù)據(jù)庫(kù)就降到了只提供歸檔備份和內(nèi)部管理查詢的角色，不再直接承載任何用戶更新和查詢請(qǐng)求了。
同時(shí)引入了數(shù)據(jù)庫(kù)更新隊(duì)列來(lái)緩解數(shù)據(jù)庫(kù)并發(fā)寫操作的壓力，因?yàn)楫?dāng)時(shí)消息隊(duì)列中間件遠(yuǎn)不如現(xiàn)在百花齊放，自行實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的文件方式消息隊(duì)列模塊，逐步應(yīng)用到4.0系統(tǒng)各個(gè)模塊間異步通信場(chǎng)合中。

圖3  4.0系統(tǒng)流程

選用了ICE作為RPC組件，用于所有的模塊間調(diào)用和網(wǎng)絡(luò)通信，這大概是剛設(shè)計(jì)4.0系統(tǒng)時(shí)唯一沒(méi)做錯(cuò)的選擇，在整個(gè)4.0系統(tǒng)項(xiàng)目生命周期，ICE的穩(wěn)定性和性能表現(xiàn)從未成為過(guò)問(wèn)題。

圖4  4.0索引緩存結(jié)構(gòu)

4.0系統(tǒng)開(kāi)發(fā)語(yǔ)言仍為C++，因?yàn)橥瑫r(shí)選用了MySQL 4.0、ICE、Linux系統(tǒng)和新文件系統(tǒng)等多項(xiàng)應(yīng)用經(jīng)驗(yàn)不足的新技術(shù)，也為后來(lái)的系統(tǒng)表現(xiàn)動(dòng)蕩埋下了伏筆（新浪到2005年左右才逐步從FreeBSD和Solaris遷移到了CentOS系統(tǒng)）。

圖5  4.0系統(tǒng)架構(gòu)

此時(shí)的4.0評(píng)論系統(tǒng)已從雙機(jī)互備擴(kuò)容到五機(jī)集群，進(jìn)入小范圍試用階段，雖然扛過(guò)了劉翔第一次奪金時(shí)創(chuàng)紀(jì)錄的發(fā)帖高峰，但倒在了2004年亞洲杯中國(guó)隊(duì)1 : 3敗于日本隊(duì)的那個(gè)夜晚。
當(dāng)時(shí)系統(tǒng)在進(jìn)入宕機(jī)之前的最高發(fā)帖速度大約是每分鐘千帖量級(jí)，在十年前還算得上是業(yè)界同類系統(tǒng)的峰值，最終確認(rèn)問(wèn)題出在文件系統(tǒng)的I/O負(fù)載上。
設(shè)計(jì)索引緩存模塊時(shí)的設(shè)想過(guò)于理想化，雖然把單一數(shù)據(jù)表的讀寫操作分解到了文件系統(tǒng)的多個(gè)文件上，但不可避免地帶來(lái)了對(duì)機(jī)械磁盤的大量隨機(jī)讀寫操作，在CentOS默認(rèn)的Ext3文件系統(tǒng)上，每條新聞對(duì)應(yīng)兩個(gè)文件的設(shè)計(jì)（2004年新浪新聞總量為千萬(wàn)左右），雖然已采取了128×256的兩層目錄HASH來(lái)預(yù)防單目錄下文件過(guò)多隱患，但剛上線時(shí)還表現(xiàn)良好的系統(tǒng)，稍過(guò)幾個(gè)月后就把文件系統(tǒng)徹底拖垮了。
既然Ext3無(wú)法應(yīng)對(duì)大數(shù)量文件的頻繁隨機(jī)讀寫，當(dāng)時(shí)我們還可以選擇使用B*樹(shù)數(shù)據(jù)結(jié)構(gòu)專為海量文件優(yōu)化的ReiserFS文件系統(tǒng)，在與系統(tǒng)部同事配合反復(fù)對(duì)比測(cè)試，解決了ReiserFS與特定Linux Kernel版本搭配時(shí)的kswapd進(jìn)程大量消耗CPU資源的問(wèn)題后，終于選定了可以正常工作的Kernel和ReiserFS對(duì)應(yīng)版本，當(dāng)然這也埋下了ReiserFS作者殺妻入獄后新裝的CentOS服務(wù)器找不到可用的ReiserFS安裝包這個(gè)大隱患。
第二階段：全系統(tǒng)異步化，索引分頁(yè)算法優(yōu)化直到這個(gè)階段，新浪評(píng)論系統(tǒng)的前端頁(yè)面仍是傳統(tǒng)的Apache+CGI模式，隨著剩余頻道的逐步切換，新浪評(píng)論系統(tǒng)升級(jí)為靜態(tài)HTML頁(yè)面使用XMLHTTP組件異步加載XML數(shù)據(jù)的AJAX模式，當(dāng)時(shí)跨域限制更少的JSON還未流行。升級(jí)為當(dāng)時(shí)剛剛開(kāi)始流行的AJAX模式并不是盲目追新，而是為了實(shí)現(xiàn)一個(gè)非常重要的目標(biāo)：緩存被動(dòng)更新的異步化。
隨著消息隊(duì)列的普遍應(yīng)用，4.0系統(tǒng)中所有的數(shù)據(jù)庫(kù)寫操作和緩存主動(dòng)更新（即后臺(tái)程序邏輯觸發(fā)的更新）都異步化了，當(dāng)時(shí)已在實(shí)踐中證明，系統(tǒng)訪問(wèn)量大幅波動(dòng)時(shí)，模塊間異步化通信是解決系統(tǒng)伸縮性和保證系統(tǒng)響應(yīng)性的唯一途徑。但在CGI頁(yè)面模式下，由用戶動(dòng)作觸發(fā)的緩存被動(dòng)更新，只能阻塞在等待狀態(tài)，直到查詢數(shù)據(jù)和更新緩存完成后才能返回，會(huì)導(dǎo)致前端服務(wù)器Apache CGI進(jìn)程的堆積。
使用AJAX模式異步加載數(shù)據(jù)，可在幾乎不影響用戶體驗(yàn)的前提下完成等待和循環(huán)重試動(dòng)作，接收緩存更新請(qǐng)求的支持優(yōu)先級(jí)的消息隊(duì)列還可合并對(duì)同一頁(yè)面的重復(fù)請(qǐng)求，也隔離了用戶行為對(duì)前端服務(wù)器的直接沖擊，極大提高了前端服務(wù)器的伸縮性和適應(yīng)能力，甚至連低硬件配置的客戶端電腦在AJAX模式加載數(shù)據(jù)時(shí)都明顯更順暢了。前端頁(yè)面靜態(tài)化還可將全部數(shù)據(jù)組裝和渲染邏輯，包括分頁(yè)計(jì)算都轉(zhuǎn)移到了客戶端瀏覽器上，充分借用用戶端資源，唯一的缺點(diǎn)是對(duì)SEO不友好。
通過(guò)以上各項(xiàng)措施，此時(shí)的4.0系統(tǒng)抗沖擊能力已有明顯改善，但是接下來(lái)出現(xiàn)了新的問(wèn)題。在3.0系統(tǒng)時(shí)代，上萬(wàn)條評(píng)論的新聞已屬少見(jiàn)，隨著業(yè)務(wù)的增長(zhǎng)，類似2005年超女專題或者體育頻道NBA專題這樣千萬(wàn)評(píng)論數(shù)級(jí)別的巨無(wú)霸留言板開(kāi)始出現(xiàn)。
為了提高分頁(yè)操作時(shí)定位和讀取索引的效率，4.0系統(tǒng)的算法是先通過(guò)mmap操作把一個(gè)評(píng)論的索引文件加載到內(nèi)存，然后按照評(píng)論狀態(tài)（通過(guò)或者刪除）和評(píng)論時(shí)間進(jìn)行快速排序，篩選出通過(guò)狀態(tài)的帖子并按時(shí)間降序排列，這樣讀取任意一頁(yè)的索引數(shù)據(jù)，都是內(nèi)存中一次常量時(shí)間成本的偏移量定位和讀取操作。幾百條或者幾千條評(píng)論時(shí)，上述方案運(yùn)作得很好，但在千萬(wàn)留言數(shù)量的索引文件上進(jìn)行全量排序，占用大量?jī)?nèi)存和CPU資源，嚴(yán)重影響系統(tǒng)性能。我們?cè)鴩L試改用BerkeleyDB的Btree模式來(lái)存儲(chǔ)評(píng)論索引，但性能不升反降。
為避免大數(shù)據(jù)量排序操作的成本，只能改為簡(jiǎn)單遍歷方式，從頭開(kāi)始依次讀取，直到獲取所需的數(shù)據(jù)。雖可通過(guò)從索引文件的兩端分別作為起點(diǎn)，來(lái)提升較新和較早頁(yè)面的定位效率，但遍歷讀取本身就是一個(gè)隨著請(qǐng)求頁(yè)數(shù)增大越來(lái)越慢的線性算法，并且隨著4.0系統(tǒng)滑動(dòng)翻頁(yè)功能的上線，原本用戶無(wú)法輕易訪問(wèn)到的中間頁(yè)面數(shù)據(jù)也開(kāi)始被頻繁請(qǐng)求，因此最終改為了兩端精確分頁(yè)，中間模糊分頁(yè)的方式。模糊分頁(yè)就是根據(jù)評(píng)論帖子的通過(guò)比例，假設(shè)可顯示帖子均勻分布，一步跳到估算的索引偏移位置。畢竟在數(shù)十萬(wàn)甚至上百萬(wàn)頁(yè)的評(píng)論里，精確計(jì)算分頁(yè)偏移量沒(méi)有太大實(shí)際意義。

圖6  異步緩存更新流程

2005年非常受關(guān)注的日本申請(qǐng)加入聯(lián)合國(guó)常任理事國(guó)事件，引發(fā)了各家網(wǎng)站的民意沸騰，新浪推出了征集反日入常簽名活動(dòng)并在短短幾天內(nèi)征集到2000多萬(wàn)簽名。因?yàn)闆](méi)有預(yù)計(jì)到會(huì)有如此多的網(wǎng)民參與，最開(kāi)始簡(jiǎn)單實(shí)現(xiàn)的PHP+MySQL系統(tǒng)在很短時(shí)間內(nèi)就無(wú)法響應(yīng)了，然后基于4.0評(píng)論系統(tǒng)緊急加班開(kāi)發(fā)了一個(gè)簽名請(qǐng)?jiān)腹δ�，系統(tǒng)表現(xiàn)穩(wěn)定。
評(píng)論系統(tǒng)4.0第三階段：簡(jiǎn)化緩存策略，進(jìn)一步降低文件系統(tǒng)I/O到了這個(gè)階段，硬件資源進(jìn)一步擴(kuò)容，評(píng)論系統(tǒng)的服務(wù)器數(shù)量終于達(dá)到了兩位數(shù)，4.0系統(tǒng)已實(shí)現(xiàn)了當(dāng)初的“不宕機(jī)”設(shè)計(jì)目標(biāo)，隨著網(wǎng)站的改版，所有新聞頁(yè)面（包括網(wǎng)站首頁(yè)）都開(kāi)始實(shí)時(shí)加載和顯示最新的評(píng)論數(shù)量和最新的帖子列表，此時(shí)4.0系統(tǒng)承受的Hits量級(jí)已接近新浪新聞靜態(tài)池的水平。從這時(shí)起，新浪評(píng)論系統(tǒng)再?zèng)]有因?yàn)榱髁繅毫﹀礄C(jī)或者暫停服務(wù)過(guò)。
前面提到，新裝的CentOS系統(tǒng)很難找到足夠新版本的ReiserFS安裝包，甚至不得不降級(jí)系統(tǒng)版本，一直困擾性能表現(xiàn)的文件系統(tǒng)也接近了優(yōu)化的極限，這時(shí)候Memcached出現(xiàn)了。

圖7  系統(tǒng)架構(gòu)

2006年左右Memcached取代了4.0系統(tǒng)中索引緩存模塊的實(shí)體數(shù)據(jù)部分（主要是評(píng)論正文），索引緩存模塊在文件系統(tǒng)上只存儲(chǔ)索引數(shù)據(jù)，評(píng)論文本都改用Memcached存儲(chǔ)，極大降低了文件系統(tǒng)的I/O壓力。因?yàn)橄到y(tǒng)流量與熱點(diǎn)事件的時(shí)間相關(guān)性，僅保存最近幾周的評(píng)論就足以保證系統(tǒng)性能，極少量過(guò)期數(shù)據(jù)訪問(wèn)即使穿透到MySQL也問(wèn)題不大，當(dāng)然服務(wù)器宕機(jī)重啟和新裝服務(wù)器上線時(shí)要非常留意數(shù)據(jù)的加載預(yù)熱。
之后4.0系統(tǒng)進(jìn)入穩(wěn)定狀態(tài)，小修小補(bǔ)，又堅(jiān)持服役了若干年，并逐步拓展到股票社區(qū)、簽名活動(dòng)、三方辯論、專家答疑、觀點(diǎn)投票等產(chǎn)品線，直到2010年之后5.0系統(tǒng)的上線。
2008年5月12日，我發(fā)現(xiàn)很多網(wǎng)友在地震新聞評(píng)論中詢問(wèn)親友信息，就立即開(kāi)發(fā)了基于評(píng)論系統(tǒng)的地震尋親功能并于當(dāng)晚上線。大約一周后為了配合Google發(fā)起的尋親數(shù)據(jù)匯總項(xiàng)目，還專門為Google爬蟲(chóng)提供了非異步加載模式的數(shù)據(jù)頁(yè)面以方便其抓取。
2004年上線的4.0系統(tǒng)，2010~2011年后被5.0系統(tǒng)取代逐步下線，從上線到下線期間系統(tǒng)處理的用戶提交數(shù)據(jù)量變化趨勢(shì)如圖8所示。

圖8  系統(tǒng)流量變化圖

高訪問(wèn)量UGC系統(tǒng)設(shè)計(jì)總結(jié)縱觀整個(gè)4.0系統(tǒng)的設(shè)計(jì)和優(yōu)化過(guò)程，在硬件資源有限的約束下，依靠過(guò)渡設(shè)計(jì)的多層緩沖，完成了流量劇烈波動(dòng)時(shí)保障服務(wù)穩(wěn)定的最基本目標(biāo)，但也確實(shí)影響到了UGC系統(tǒng)最重要的數(shù)據(jù)更新實(shí)時(shí)性指標(biāo)，數(shù)據(jù)更新的實(shí)時(shí)性也是之后5.0系統(tǒng)的重點(diǎn)改進(jìn)方向。
總結(jié)下來(lái)，一般UGC系統(tǒng)的設(shè)計(jì)方針就是通過(guò)降低系統(tǒng)次要環(huán)節(jié)的實(shí)時(shí)一致性，在合理的成本范圍內(nèi)，盡量提高系統(tǒng)響應(yīng)性能，而提高響應(yīng)性能的手段歸根結(jié)底就是三板斧：隊(duì)列（Queue）、緩存（Cache）和分區(qū)（Sharding）。

• 隊(duì)列：可以緩解并發(fā)寫操作的壓力，提高系統(tǒng)伸縮性，同時(shí)也是異步化系統(tǒng)的最常見(jiàn)實(shí)現(xiàn)手段。
• 緩存：從文件系統(tǒng)到數(shù)據(jù)庫(kù)再到內(nèi)存的各級(jí)緩存模塊，解決了數(shù)據(jù)就近讀取的需求。
• 分區(qū)：保證了系統(tǒng)規(guī)模擴(kuò)張和長(zhǎng)期數(shù)據(jù)積累時(shí)，頻繁操作的數(shù)據(jù)集規(guī)模在合理范圍。
  

關(guān)于數(shù)據(jù)庫(kù)，區(qū)分冷熱數(shù)據(jù)，按照讀寫操作規(guī)律合理拆分存儲(chǔ)，一般UGC系統(tǒng)近期數(shù)據(jù)才是熱點(diǎn)，歷史數(shù)據(jù)是冷數(shù)據(jù)。

• 區(qū)分索引和實(shí)體數(shù)據(jù)，索引數(shù)據(jù)是Key，易變，一般用于篩選和定位，要保證充分的拆分存儲(chǔ)，極端情況下要把關(guān)系數(shù)據(jù)庫(kù)當(dāng)NoSQL用；實(shí)體數(shù)據(jù)是Value，一般是正文文本，通常不變，一般業(yè)務(wù)下只按主鍵查詢；兩者要分開(kāi)。
• 區(qū)分核心業(yè)務(wù)和附加業(yè)務(wù)數(shù)據(jù)，每一項(xiàng)附加的新業(yè)務(wù)數(shù)據(jù)都單獨(dú)存儲(chǔ)，與核心業(yè)務(wù)數(shù)據(jù)表分開(kāi)，既可降低核心業(yè)務(wù)數(shù)據(jù)庫(kù)的變更成本，還可避免新業(yè)務(wù)頻繁調(diào)整上下線時(shí)影響核心業(yè)務(wù)。
  

目前的互聯(lián)網(wǎng)系統(tǒng)大都嚴(yán)重依賴MySQL的Replication主從同步來(lái)實(shí)現(xiàn)系統(tǒng)橫向擴(kuò)展，雖然MySQL在新版本中陸續(xù)加入RBR復(fù)制和半同步等機(jī)制，但從庫(kù)的單線程寫操作限制還是最大的制約因素，到現(xiàn)在還沒(méi)有看到很理想的革新性解決方案。
關(guān)于緩存，從瀏覽器到文件系統(tǒng)很多環(huán)節(jié)都有涉及，這里主要說(shuō)的是應(yīng)用系統(tǒng)自己的部分。

• 最好的緩存方案是不用緩存，緩存帶來(lái)的問(wèn)題往往多于它解決的問(wèn)題。
• 只有一次更新多次讀取的數(shù)據(jù)才有必要緩存，個(gè)性化的冷數(shù)據(jù)沒(méi)必要緩存。
• 緩存分為主動(dòng)（Server推）和被動(dòng)（Client拉）兩種更新方式，各自適用于不用場(chǎng)景。主動(dòng)更新方式一般適用于更新頻率較高的熱數(shù)據(jù)，可保證緩存未命中時(shí)，失控的用戶行為不會(huì)引發(fā)系統(tǒng)連鎖反應(yīng)，導(dǎo)致雪崩。被動(dòng)更新方式一般適用于更新頻率相對(duì)較低的數(shù)據(jù)，也可以通過(guò)上文提到的異步更新模式，避免連鎖反應(yīng)和雪崩。
• 緩存的更新操作盡量設(shè)計(jì)為覆蓋方式，避免偶發(fā)數(shù)據(jù)錯(cuò)誤的累積效應(yīng)。
  

一個(gè)UGC系統(tǒng)流量剛開(kāi)始上漲時(shí)，初期的表面性能瓶頸一般會(huì)表現(xiàn)在Web Server層面，而實(shí)際上大多是數(shù)據(jù)庫(kù)的原因，但經(jīng)充分優(yōu)化后，最終會(huì)落在文件系統(tǒng)或網(wǎng)絡(luò)通信的I/O瓶頸上。直接承載用戶訪問(wèn)沖擊的前端服務(wù)器最好盡量設(shè)計(jì)為無(wú)狀態(tài)模式，降低宕機(jī)重啟后的修復(fù)工作量。
順帶提及，我在新浪聊天和評(píng)論系統(tǒng)的開(kāi)發(fā)過(guò)程中，逐步積累了一個(gè)Web應(yīng)用開(kāi)發(fā)組件庫(kù)，在新浪全面轉(zhuǎn)向PHP之前，曾用于新浪的內(nèi)容管理（CMS）、用戶注冊(cè)和通行證、日志分析和論壇等使用C++的系統(tǒng)，目前發(fā)布于github.com/pi1ot/webapplib。
評(píng)論系統(tǒng)5.0方案2010年后針對(duì)4.0系統(tǒng)的缺陷，啟動(dòng)了5.0系統(tǒng)工作。因?yàn)楣ぷ鞯慕唤樱?.0系統(tǒng)我只負(fù)責(zé)了方案設(shè)計(jì)，具體開(kāi)發(fā)是交給其他同事負(fù)責(zé)的，線上的具體實(shí)現(xiàn)與原始設(shè)計(jì)方案可能會(huì)有區(qū)別。5.0系統(tǒng)極大簡(jiǎn)化了系統(tǒng)層次，在保證抵抗突發(fā)流量波動(dòng)性能的前提下，數(shù)據(jù)更新的及時(shí)性有了明顯提高。

圖9  4.5系統(tǒng)流程

圖10  5.0系統(tǒng)流程

設(shè)計(jì)方案上的主要變化有以下幾點(diǎn)。

• 評(píng)論帖子ID從數(shù)據(jù)庫(kù)自增整數(shù)改為UUID，提交時(shí)即可確定，消除了必須等待主庫(kù)寫入后才能確定評(píng)論ID的瓶頸，對(duì)各個(gè)層面的緩存邏輯優(yōu)化有極大幫助。
• 重新設(shè)計(jì)數(shù)據(jù)庫(kù)結(jié)構(gòu)，通過(guò)充分的數(shù)據(jù)切分，保證了所有高頻業(yè)務(wù)操作都可在一個(gè)有限數(shù)據(jù)量的數(shù)據(jù)表中的一次簡(jiǎn)單讀取操作完成，索引和文本數(shù)據(jù)隔離存儲(chǔ)，在數(shù)據(jù)庫(kù)中實(shí)現(xiàn)了原4.0系統(tǒng)中索引模塊的功能，取消了4.0系統(tǒng)的索引緩存層。
• 改用內(nèi)存NoSQL緩存用戶頻繁讀取的最新10~20頁(yè)數(shù)據(jù)，取消了原4.0系統(tǒng)文件方式的頁(yè)面緩存層。
• 系統(tǒng)運(yùn)行環(huán)境遷移到新浪云的內(nèi)部版本：新浪動(dòng)態(tài)平臺(tái)，設(shè)備資源富裕度有了極大改善。
• 改為Python語(yǔ)言開(kāi)發(fā)，不用再像4.0系統(tǒng)那樣每次更新時(shí)都要等待半個(gè)小時(shí)的編譯過(guò)程，也不用再打包幾百兆的執(zhí)行文件同步到幾十臺(tái)服務(wù)器上，而語(yǔ)言層面的性能損失可以忽略不計(jì)。
  

新聞評(píng)論產(chǎn)品總結(jié)新聞評(píng)論作為微博之前最能反映輿情民意的UGC平臺(tái)，長(zhǎng)期承載了國(guó)內(nèi)互聯(lián)網(wǎng)用戶對(duì)時(shí)事新聞的匿名表達(dá)欲望，曾經(jīng)一度成為上到政府下到網(wǎng)民的關(guān)注焦點(diǎn)。雖然面臨了相對(duì)其他社區(qū)系統(tǒng)更為嚴(yán)厲的管控力度，也錯(cuò)過(guò)了實(shí)施實(shí)名制改造時(shí)邁向社區(qū)化的最佳時(shí)機(jī)，但無(wú)論如何，在21世紀(jì)的前十年，國(guó)內(nèi)門戶網(wǎng)站的新聞評(píng)論服務(wù)，都是中國(guó)互聯(lián)網(wǎng)產(chǎn)品和技術(shù)發(fā)展歷史上絕對(duì)不能錯(cuò)過(guò)的一筆。
作者劉立，2000年畢業(yè)于哈爾濱工業(yè)大學(xué)計(jì)算機(jī)系，2000-2013年工作于新浪網(wǎng)研發(fā)中心和門戶技術(shù)部門，目前在一家社交電商平臺(tái)創(chuàng)業(yè)團(tuán)隊(duì)任技術(shù)負(fù)責(zé)人。

pi1ot

多謝轉(zhuǎn)載，這里是無(wú)碼完整版：
weibo.com/p/1001603789147444803230

流氓無(wú)產(chǎn)者

這樣的技術(shù)文章很不錯(cuò)