2012年底，末日之后，看到大家都在寫年末總結(jié)，我也忍不住想一試。工作已經(jīng)3年半了，頭一次寫總結(jié)。雖然到現(xiàn)在仍是無名小碼農(nóng)一名，但工作這些年，技術(shù)著實(shí)有不少積累。成長最大的，當(dāng)然就是這篇文章標(biāo)題提到的——高性能分布式計(jì)算與存儲(chǔ)系統(tǒng)的設(shè)計(jì)和研發(fā)過程，這也是我自2010年供職于國內(nèi)最大的某著名網(wǎng)站之后，和這個(gè)系統(tǒng)一起成長，親眼見證和伴隨著它的發(fā)展，從一個(gè)嬰兒一樣的"Demo"程序，成長為現(xiàn)在可以處理千萬級(jí)日PV的強(qiáng)大系統(tǒng)，直到2012年我離開。我也順勢(shì)積累了Unix/Linux服務(wù)器、多線程、I/O、海量數(shù)據(jù)處理、注重高性能與效率的C/C++編程等寶貴的碼農(nóng)財(cái)富，當(dāng)然，遺憾和不足，仍然是有許多的。

【番外篇】2012年，其實(shí)是自工作以來，技術(shù)積淀最多的一年。因?yàn)?，?012年，我終于學(xué)會(huì)了獨(dú)立思考，我不再像以前一樣，許許多的技術(shù)只是需要用到的時(shí)候，匆忙的google（有時(shí)候還要先匆忙的先翻墻），我發(fā)現(xiàn)，“好記性不如爛筆頭”，古訓(xùn)確實(shí)毋庸置疑，有大量的、瑣碎的技術(shù)經(jīng)驗(yàn)、編程細(xì)節(jié)、技巧，需要積淀下來，可能單條的細(xì)節(jié)與技巧，并不會(huì)對(duì)一個(gè)人的職業(yè)生涯產(chǎn)生什么影響，但把它們都積聚起來，就會(huì)強(qiáng)大許多，很實(shí)際的，帶來的技術(shù)提升，能帶來更高的Offer。所以，2012年，我開始到博客園寫技術(shù)博客，和眾多園友分享我對(duì)技術(shù)的一知半解，共同進(jìn)步；也終于耐下心，為自己做了一個(gè)簡單的個(gè)人主頁，雖然10年前，我就可以做出這樣的東西……；我成為了更忠實(shí)的蘋果粉，所以我嘗試去做iOS創(chuàng)業(yè)，雖然這和我的主要工作研究方向并不一致，當(dāng)我看到自己做的demo在自己iPhone 4s上跑起來，我突然又有一了一種久違的興奮——那是每一個(gè)程序員，都體會(huì)過的，小小的成就感；2012年，我開始接觸和了解許多以前從來不懂的技術(shù)：Hadoop、GoogleFS、JVM、XCode、ARC……小到如何將vim打造成一個(gè)IDE……；2012年，我暫時(shí)離開了生活工作了6年的北京，來到了陌生的上海，雖然明年我可能就會(huì)回到北京，在上海這個(gè)繁華的城市，我又體會(huì)到了一種和京城碼農(nóng)感覺一樣的，技術(shù)氛圍和文化；最后必須一提的，2012年，我結(jié)婚了，并喜得一龍子，在這篇總結(jié)里，衷心的對(duì)我老婆說一聲：“老婆，謝謝你，我愛你。”

【正題】接下來，該進(jìn)入這篇文章的正題了， 就是簡單地談?wù)?，我這兩年，主要做的東西——高性能分布式計(jì)算與存儲(chǔ)系統(tǒng)。

這個(gè)系統(tǒng)看名字十分厲害，所涉足的目前互聯(lián)網(wǎng)最領(lǐng)先的技術(shù)領(lǐng)域。具體有什么用途？ 在我之前供職的公司，它主要是作為中間層，給網(wǎng)站頁面提供緩存服務(wù)的，并且，它對(duì)付的難題，是大數(shù)據(jù)、海量數(shù)據(jù)，相信，每一個(gè)日PV超過千萬級(jí)的網(wǎng)站，都必須會(huì)有類似的系統(tǒng)存在，如果，你曾經(jīng)看過，博客園里的《淘寶技術(shù)發(fā)展》等類似文章，就一定不會(huì)對(duì)我接來將要提到的許多概念和術(shù)語感到陌生。對(duì)于這樣大流量，需要處理大數(shù)據(jù)的網(wǎng)站而言，由Web的邏輯直接調(diào)用管理數(shù)據(jù)存儲(chǔ)，是非常不科學(xué)的，實(shí)際上也是不可能的，大數(shù)據(jù)、高并發(fā)的對(duì)數(shù)據(jù)庫進(jìn)行讀寫，通常數(shù)據(jù)庫都會(huì)掛掉，從而使網(wǎng)站也掛掉，必須要在Web和數(shù)據(jù)庫之間，通過技術(shù)手段實(shí)現(xiàn)一種“轉(zhuǎn)換”或“控制”，或“均衡”或“過渡”，我不知道這樣用詞是否正確，你只要明白其中的意思就好了。這樣的技術(shù)手段有許多，所實(shí)現(xiàn)的東東也有許多，我們用到的，就是被稱為“中間層”的一個(gè)邏輯層，在這個(gè)層，將數(shù)據(jù)庫的海量數(shù)據(jù)抓出來，做成緩存，運(yùn)行在服務(wù)器的內(nèi)存中，同理，當(dāng)有新的數(shù)據(jù)到來，也先做成緩存，再想辦法，持久化到數(shù)據(jù)庫中，就是這樣簡單的思路，但實(shí)現(xiàn)起來，從零到有，可以說難如登天，但是，任何事物，都是在曲折中，不斷發(fā)展前進(jìn)的，這是中學(xué)我們就學(xué)過的哲學(xué)理論。這個(gè)系統(tǒng)，就被我們稱簡為“緩存系統(tǒng)”，它最大的好處，就是砍掉了每天上千萬次的數(shù)據(jù)庫讀寫操作，取代而之的，是讀取服務(wù)器中提供緩存服務(wù)的進(jìn)程所控制的內(nèi)存，所以你知道，這里面節(jié)省了多少的資源申請(qǐng)、競(jìng)爭(zhēng)、I/O……當(dāng)然，后面你也會(huì)發(fā)現(xiàn)，它會(huì)帶來許多新的問題，最顯著的問題，就是數(shù)據(jù)的同步和一致性，后面我會(huì)講到。

現(xiàn)在，讓我們先看看， 這個(gè)系統(tǒng)，發(fā)展到我離開它的時(shí)候，長什么樣子？（由于涉及到商業(yè)機(jī)密，具體的技術(shù)不能提供）

就是這樣的一張架構(gòu)圖，代表著可以處理每日上千萬PV的系統(tǒng)，涉及到許多的技術(shù)，讓我們一個(gè)部分一個(gè)部分解讀它。

首先，從當(dāng)我有一個(gè)web請(qǐng)求到達(dá)時(shí)，將會(huì)發(fā)生怎樣的事情說起。比如，我是一個(gè)用戶，我在這個(gè)網(wǎng)站登陸，我的“個(gè)人”頁面上，將會(huì)加載許許多多的東西，有許許多多的圖片、文字、消息等，我們舉其中一個(gè)例子，我將要得到我的好友列表——friend list。通過常識(shí)可以知道，這個(gè)friend list，不是隨機(jī)的、臨時(shí)的，而肯定是一個(gè)（一組）持久化存儲(chǔ)于數(shù)據(jù)庫里的數(shù)據(jù)，我們就是一個(gè)用戶請(qǐng)求得到他的friend list說起，來解讀這張架構(gòu)圖。如果我的網(wǎng)站流量很小，每天不超過10萬PV，峰值可能就幾百個(gè)上千個(gè)用戶，同時(shí)請(qǐng)求他們的friend list，那么，現(xiàn)今任何一種語言配上任何一種數(shù)據(jù)庫的搭配，只要稍做處理，都可以很好的完成這個(gè)工作——從數(shù)據(jù)庫中，讀出該用戶的friend list，然后訪回給web，如果用戶對(duì)好友列表作了任何修改，web馬上將修改內(nèi)容寫入數(shù)據(jù)庫，形成新的friend list。然而，當(dāng)訪問流量持續(xù)提升，達(dá)到千萬級(jí)、甚至億級(jí)PV的時(shí)候，剛才說的方法就不可行了。因?yàn)椋瑫r(shí)可能有幾十萬甚至上百萬用戶，通過web請(qǐng)求從數(shù)據(jù)庫中讀（如果寫將會(huì)更糟糕）上百條萬數(shù)據(jù)，數(shù)據(jù)庫將不堪重負(fù)，形成巨大的延遲甚至掛掉。通過上面的系統(tǒng)，來解決這樣的問題。

現(xiàn)在，我們要設(shè)計(jì)和研發(fā)的上述系統(tǒng)，當(dāng)一個(gè)web頁面提交一個(gè)獲取friend list的請(qǐng)求后，它首先將根據(jù)一定的規(guī)則，通過負(fù)載均衡，然后到達(dá)相應(yīng)的master節(jié)點(diǎn)。上面我們提到的是DNS負(fù)載均衡，這得眾多負(fù)載均衡技術(shù)中的一種方法。也就是說，我有許許多多的master節(jié)點(diǎn)（上圖的scalabe表明，我是可擴(kuò)展的，只要有條件，可隨意橫向擴(kuò)展節(jié)點(diǎn)，以提高速度、容災(zāi)、容量等指標(biāo)），每個(gè)master節(jié)點(diǎn)的IP地址（域名）當(dāng)然不一樣，通過DNS負(fù)載均衡，合理地把該請(qǐng)求，送到相對(duì)“空閑”的master節(jié)點(diǎn)服務(wù)器?，F(xiàn)在解釋一下master節(jié)點(diǎn)服務(wù)器和slave節(jié)點(diǎn)服務(wù)器的功能：slave節(jié)點(diǎn)，主要用于"Running services"，即，實(shí)際處理請(qǐng)求的緩存服務(wù)進(jìn)程，通常運(yùn)行在slave節(jié)點(diǎn)上；master節(jié)點(diǎn)，主要用于分發(fā)通過負(fù)載均衡的請(qǐng)求（當(dāng)然，master節(jié)點(diǎn)上也可以運(yùn)行一些“緩存服務(wù)進(jìn)程”，即并發(fā)流量不高、較輔助的一些服務(wù)），找到用于處理實(shí)際請(qǐng)求的合適的slave節(jié)點(diǎn)，將該請(qǐng)求交給它處理，再次實(shí)現(xiàn)了一道“負(fù)載均衡”，同時(shí)，需要分布式計(jì)算的內(nèi)容，將可能同時(shí)分發(fā)到幾個(gè)slave節(jié)點(diǎn)，之后再對(duì)結(jié)果進(jìn)行合并返回（Map-Reduce原理）。

好了，現(xiàn)在我們已經(jīng)知道，一個(gè)friend list請(qǐng)求已經(jīng)通過DNS負(fù)載均衡、通過master節(jié)點(diǎn)進(jìn)行分配，到達(dá)了相應(yīng)的slave節(jié)點(diǎn)上。我們還知道，所說的“緩存”，正是slave節(jié)點(diǎn)中所運(yùn)行的services進(jìn)程中所管理的內(nèi)存，提供同樣功能的service可能會(huì)有很多份，同時(shí)運(yùn)行在不同slave節(jié)點(diǎn)上，以提供高并發(fā)和分布式計(jì)算的功能。例如，獲得friend list就是這樣的service，因?yàn)檫@個(gè)功能太常用了，所以，在我們的系統(tǒng)中，這樣的服務(wù)可能同時(shí)提供5份、10份甚至更多，那么我這個(gè)獲取friend list的請(qǐng)求，究竟被分配到哪個(gè)slave節(jié)點(diǎn)上的service處理呢？這正是剛才提到的master節(jié)點(diǎn)來完成這一工作。再比如，我現(xiàn)在需要獲取“二度關(guān)系”的列表（關(guān)于六度人脈理論，可google），所謂“二度關(guān)系”，就是好友的好友，那么我要取這樣的列表，即friend's every friend list，這樣的請(qǐng)求，將會(huì)把取每個(gè)friend list分配（Map）到不同slave節(jié)點(diǎn)上去做（根據(jù)一定的規(guī)則），然后再進(jìn)行合并（Reduce）（當(dāng)然，熟悉算法的同學(xué)可能已經(jīng)發(fā)現(xiàn)，這樣去獲取請(qǐng)求，非常的笨拙，有沒有更好的方法呢？當(dāng)然有！因?yàn)楹糜训暮糜眩鋵?shí)就是好友的friend list與我和好友的共同好友common friend list的“差集”，對(duì)嗎？所以我不用去取好友的每個(gè)好友的friend list，而只用取2次就可以通過計(jì)算完成請(qǐng)求，這又節(jié)省了多少資源呢？假如我有100個(gè)好友，1000個(gè)，10000萬個(gè)？會(huì)節(jié)省多少次計(jì)算呢？這也證明，一個(gè)良好的算法，對(duì)改善程序性能，有多么大的幫助?。?/p>

好，我們繼續(xù)?，F(xiàn)在，我的獲取friend list的請(qǐng)求，已經(jīng)在被某個(gè)slave節(jié)點(diǎn)中的負(fù)責(zé)這一功能的service進(jìn)程處理，它將根據(jù)一定規(guī)則，給出兩種可能的處理方式：

1、 我這個(gè)用戶非常活躍，經(jīng)常登陸網(wǎng)站（一定的規(guī)則，認(rèn)為緩存未到過期時(shí)間），且我這個(gè)slave節(jié)點(diǎn)自上次“重建緩存”（即重新從數(shù)據(jù)庫中讀取數(shù)據(jù)，建立緩存，后面會(huì)談）后，沒有發(fā)生過down機(jī)重啟行為（又一定的規(guī)則），我也沒有收到過master節(jié)點(diǎn)發(fā)送過來要求更新緩存（即從數(shù)據(jù)庫中比較數(shù)據(jù)并更新）的Notification（通知），或是在一定條件下我這個(gè)slave節(jié)點(diǎn)對(duì)它掌握的緩存數(shù)據(jù)版本（版本管理系統(tǒng)原理，思考一下svn的工作原理）和數(shù)據(jù)庫進(jìn)行了一次比較（注意，比較數(shù)據(jù)版本可認(rèn)為只是一個(gè)int值，且是原子操作，這和比較整條數(shù)據(jù)是否一致在性能上有天壤之別）發(fā)現(xiàn)是最新的數(shù)據(jù)版本，那么，我這個(gè)slave節(jié)點(diǎn)將直接返回緩存數(shù)據(jù)，而沒有任何數(shù)據(jù)庫讀操作，也就是說，我這一次獲取friend list的請(qǐng)求，得到的是緩存數(shù)據(jù)，當(dāng)然，這個(gè)緩存數(shù)據(jù)肯定是最新的、正確的、和數(shù)據(jù)庫中的持久化數(shù)據(jù)是一致的，后面會(huì)提到怎樣來盡量保證這一點(diǎn)；

2、第1點(diǎn)中的“一定規(guī)則”不滿足時(shí)，即我這個(gè)slave節(jié)點(diǎn)的緩存和數(shù)據(jù)庫中的數(shù)據(jù)可能存在不一致的沒有其它辦法，我必須從數(shù)據(jù)庫中讀取數(shù)據(jù)，更新緩存，然后再返回。但同時(shí)注意，slave節(jié)點(diǎn)中的service服務(wù)進(jìn)程，將認(rèn)為此用戶現(xiàn)在活躍，可能還會(huì)請(qǐng)求一些相關(guān)、類似的數(shù)據(jù)（如馬上可能進(jìn)行添加好友、刪除好友等操作），所以去數(shù)據(jù)庫讀取數(shù)據(jù)的時(shí)候，將不會(huì)只讀friend list，可能與用戶有關(guān)的其它一部分?jǐn)?shù)據(jù)，會(huì)被同時(shí)讀取并更新緩存，如果負(fù)責(zé)這一部分?jǐn)?shù)據(jù)的緩存服務(wù)并不是當(dāng)前的service進(jìn)程，或在其它slave節(jié)點(diǎn)，或同時(shí)還有幾份service進(jìn)程在工作，那么slave節(jié)點(diǎn)將提交“更新緩存”請(qǐng)求給master節(jié)點(diǎn)，通過master節(jié)點(diǎn)發(fā)出Notification給相關(guān)slave節(jié)點(diǎn)的相關(guān)service進(jìn)程，從而，盡可能使每一次讀取數(shù)據(jù)庫的作用最大化，而如果稍后用戶果然進(jìn)行了我們猜測(cè)的行為（可認(rèn)為cache命中），結(jié)果將同第1點(diǎn)，直接通過緩存返回?cái)?shù)據(jù)而且保證了數(shù)據(jù)的正確和一致性。

好了，剛剛提到的都是“讀操作”，相比“寫操作”， 其數(shù)據(jù)一致性更容易保證，之后我們將講述“寫操作”的工作原理?，F(xiàn)在，讓我們先跳過這一部分，繼續(xù)看架構(gòu)圖。slave節(jié)點(diǎn)之后，就是實(shí)際的數(shù)據(jù)存儲(chǔ)了，使用了MySQL、Redis，MySQL主從之間的協(xié)同是DBA的工作，不在此篇討論，Redis主要存儲(chǔ)K-V鍵值對(duì)數(shù)據(jù)，比如用戶id和用戶昵稱，是最常用的K-V對(duì)之一，通過Redis進(jìn)行存儲(chǔ)，再結(jié)合上述的工作過程，可保證這個(gè)系統(tǒng)的高性能。而架構(gòu)圖最右下角的Hadoop與MongoDB，是可選的MySQL替代方案，其實(shí)，正是未來的主要發(fā)展方向。如果slave節(jié)點(diǎn)中的service服務(wù)進(jìn)程與Hadoop良好結(jié)合，系統(tǒng)的性能將更上一層樓。順便說一句，master、slave節(jié)點(diǎn)都是由C++開發(fā)的。Why C++？可參考酷殼上的一篇文章《C++ Performance per $》。

好了，上篇就講到這里，余下的問題，我們?cè)谙缕M(jìn)行討論，謝謝大家。