【Csdn.net 7月26日 獨家報道】繼成功舉辦首期TUP活動后，日前在北京麗亭華苑酒店鴻運二廳，由CSDN和《程序員》雜志聯(lián)合策劃組織的TUP第二次活動如期而至，本次活動以Web 2.0技術(shù)為主題，聚焦當下火熱的社交網(wǎng)、微博架構(gòu)與實時搜索領(lǐng)域。就相關(guān)領(lǐng)域及產(chǎn)品研發(fā)背后的技術(shù)、產(chǎn)品設(shè)計及用戶體驗話題為與會者提供全開放式的交流平臺。即使是付費沙龍，參會報名人數(shù)仍在不斷上升，本次活動有超過300人來到現(xiàn)場。
人人網(wǎng)技術(shù)經(jīng)理張鐵安
以下是人人網(wǎng)技術(shù)經(jīng)理張鐵安的演講內(nèi)容：
張鐵安：我今天跟大家分享這個內(nèi)容是人人網(wǎng)系統(tǒng)架構(gòu)，里面我們會講到跟新鮮事相關(guān)的一些技術(shù)和開源一些項目，希望對大家今后工作有一些幫助。首先我要講我們新鮮事系統(tǒng)在SNS的主要功能。我要在人人網(wǎng)發(fā)一個日志，可以很及時高效迅速的在我朋友圈、粉絲圈子里面可以看到，我朋友可以很快回復(fù)跟我進行一個很快的交互。我必須保證系統(tǒng)高效運轉(zhuǎn)，同時要穩(wěn)定。對于我們這樣一個SNS網(wǎng)站來說，包括SNS還有微博這樣一些系統(tǒng)，很重要一點是當發(fā)生特殊事件時會有一個爆發(fā)效應(yīng)。前兩天世界杯，我不是一個足球迷，那天晚上我就睡了。兩點我手機不停的響，我說怎么回事，我以為同事更新服務(wù)，想了想可能今天晚上是什么比賽比較火，第二天早上說是德國隊進球了。系統(tǒng)遇到這種事情會有一個脈沖式的爆發(fā)，去年春節(jié)晚會趙本山小品剛開始，整個系統(tǒng)會非常爆炸式的報警，所以對于我們系統(tǒng)來說我們需要解決很多的突發(fā)事件給我們帶來的壓力，保證我們系統(tǒng)有足夠的穩(wěn)定性。
另外要說我們這個系統(tǒng)里面所有數(shù)據(jù)有很大一部分來自網(wǎng)站各個業(yè)務(wù)，還有一些來自于其他的門戶網(wǎng)站，其他一些跟我們有合作關(guān)系的網(wǎng)站，開放平臺支持很多第三方應(yīng)用或者鏈接他們產(chǎn)生實踐的時候，可以把數(shù)據(jù)發(fā)給我們FEED的系統(tǒng)。我們這個INPUT內(nèi)容會非常復(fù)雜，我們要有很好的處理不同數(shù)據(jù)的能力。我們需要一個很好的數(shù)據(jù)規(guī)范，保證我們系統(tǒng)能夠接受不同類型的數(shù)據(jù)。另外一個是我們輸出包括幾個方面，一個是登陸人人首頁個人主頁列表，同時還有一個PC客戶端叫人人桌面還有手機客戶端等等。但是對于各個不同需要展示業(yè)務(wù)要求不一樣。手機展示要求我不是所有事都想要，我只想要其他一部分，會有一些選擇的需求。從各個方面我們現(xiàn)在這個系統(tǒng)設(shè)計復(fù)雜度是很高的，跟各個業(yè)務(wù)連接也是非常復(fù)雜，最終導(dǎo)致這個系統(tǒng)有一個很高的復(fù)雜度。
下面我想說一下我們這個系統(tǒng)面臨一些挑戰(zhàn)。對于人人網(wǎng)這樣一個網(wǎng)站來說，活躍用戶是非常多的，一天可能有幾千萬用戶。我們計算一下，當然這個數(shù)據(jù)可能不是一個真實的數(shù)據(jù)，我們認為每秒會產(chǎn)生一千條Feed、一千個客戶會產(chǎn)生一些內(nèi)容，到系統(tǒng)里面我們要處理原始數(shù)據(jù)可能是幾十億的規(guī)模。再說一下Feed的特點，當我改一個狀態(tài)我好友所有收到這些信息就是一個擴散問題，我們需要把這個數(shù)據(jù)給這些所有想要收到數(shù)據(jù)的人看到，所以這個Feed擴散范圍很大。如果我有100個好友我要擴散到100人，如果我是一個明星就更多人會看到。
新鮮事物有這么一個特點，我發(fā)了一篇日志就兩個朋友看了覺得很有意思就把這個日志分享了，如果另外一個人是那兩個人的朋友，他的頁面上有兩個一樣內(nèi)容分享，這樣可能會有問題。我們會采取一種策略，把兩個相關(guān)的新鮮事合并，或者做一些替換，排序，合并這些是比較復(fù)雜。另外就是用戶請求量對人人網(wǎng)最大的請求量就是登陸的請求量。最后一點我剛才已經(jīng)講過各個業(yè)務(wù)需求要求對新鮮事做不同的篩選。
然后講一下關(guān)于系統(tǒng)設(shè)計當中的兩個問題，推的模式和拉的模式。兩個模式區(qū)別在于什么地方？推的模式意思就是說當一個事件產(chǎn)生的時候，我把這個事件產(chǎn)生時間點做N次拷貝發(fā)給他想要的人。拉是另外一種方法，當一個用戶登陸頁面的時候，首頁要顯示所有好友關(guān)注人的新鮮事。這個時候用拉的模式實現(xiàn)。就是說我登陸了，我查我的所有跟我有關(guān)系的列表，拿到這些列表根據(jù)這些人對應(yīng)新鮮事列表里面取所有的新鮮事再做排序，歸并的策略。推可能是非常快的操作，推過去以后，那邊立馬有了。我們登陸列表是現(xiàn)成，取的時候會非常快。但是有一個問題，比如說我有幾個億用戶，但是活躍用戶只有幾千萬，剩下幾個億的用戶他們可能是半年來一次，或者說一個月兩周過來一次。這些數(shù)據(jù)給他以后他可能根本沒有機會看到，這樣就浪費了很多資源。拉模式不會有這個問題，但是會有另外一個問題。你請求量很大，當用戶登陸必須很快返回數(shù)據(jù)的時候，運算量是非常大的。綜合所有考慮，因為我們要做的是一個要求實時度很高的系統(tǒng)，我們還是選擇推的模式，但是在用推的時候有些地方是可以做一些權(quán)衡的，把不必要系統(tǒng)開銷可以去掉。
這是我們現(xiàn)在Feed這個系統(tǒng)的各個層面。第一是新鮮事分發(fā)，就是說我發(fā)了一個東西以后，要把這個事情告訴所有跟我有關(guān)系的人，這個事就是頁dispatch完成的。后面有newsFeed索引的服務(wù)，跟我們新鮮事有關(guān)的東西，包括用戶的反饋，還有我們一些排序方法，跟好友關(guān)系，整個在SNS當中的朋友圈子有關(guān)系的一些東西，比如說哪些好友跟你關(guān)系很親密，你跟你老婆關(guān)系可能很親密跟他悄悄話我們都知道，還有一些你經(jīng)常一起玩的朋友，你們這樣一些人的關(guān)系可能會相對比較緊密一些。我們在考慮新鮮事排序權(quán)重時我們會考慮把你老婆心情放在排序最上面，要第一時間響應(yīng)領(lǐng)導(dǎo)的指示。
這個是跟我們新鮮事排序相關(guān)，包括Feed排序一些算法，還有跟社會化網(wǎng)絡(luò)相關(guān)的。我們正在做的基于新鮮事內(nèi)容的一些興趣把內(nèi)容分類，有點像百度百科，我們知道哪些用戶對音樂感興趣，哪些用戶對科技或者對政治感興趣等等。這些我們會通過一些系統(tǒng)計算，最后反映在新鮮事排序里面。下面是MIINFeed就是自己發(fā)的新鮮事的列表，另外還有一個是新鮮事本身內(nèi)容，我發(fā)了一個日志新鮮事，能夠看到就是這個摘要幾十個字簡短的摘要。下面說的是我們新鮮事對于索引數(shù)據(jù)量是非常大的，我們會講一下，索引數(shù)據(jù)對我們來說有什么意義。當我們用戶取新鮮事需要查他的索引，以后再去取內(nèi)容，這個東西內(nèi)存CACHE丟失這個用戶頁面上什么都沒有了。所以我們要做持久化。INdexdb數(shù)據(jù)會有一個列表，寫到硬盤里面，最后是我們渲染引擎，我們有很多的輸入和很多輸出，不同輸出要求不一樣，比如說我們給手機輸出格式和客戶端格式是完全不一樣。所以這兩個東西都是由一個系統(tǒng)完成。
這個是我們看到新鮮事的簡單結(jié)構(gòu)圖。里面內(nèi)容不是我們現(xiàn)在線上系統(tǒng)的整個東西，可能只是其中一部分，我是把最重要的東西拿出來。一個笑臉就是一個人在上面很開心，他發(fā)了一個日志通過我們網(wǎng)站日志相關(guān)的負責日志模塊系統(tǒng)把這個日志內(nèi)容發(fā)新鮮事系統(tǒng)里面，首先拿到就是Dis 把這個數(shù)據(jù)進行一些處理，把這個內(nèi)容最終分發(fā)到三個不同的地方，第一就是newsFeed，比如說我發(fā)miniFeed有需要，第三是要把這個新鮮事產(chǎn)生本身內(nèi)容要cache起來，會發(fā)給我們一個集群。下面會了解我們持久化這一塊，MINIFeed量很小，我們做一個數(shù)據(jù)表就可以存下來。我們閃存100份，ID結(jié)尾為1放一起，這樣一種散表的策略分散在機器上分擔壓力。我們再說一下當一個用戶登陸人人網(wǎng)要取新鮮事的邏輯。如果是一個網(wǎng)站用戶登陸以后設(shè)備要訪問一個服務(wù)器，會并節(jié)一些新鮮事的內(nèi)容，我們并沒有用傳統(tǒng)意義上的服務(wù)器，特點就是說能夠支持很高的用戶的并發(fā)量，同時速度會非常快。我們整個網(wǎng)站新鮮事的WEB服務(wù)器只有四臺，會提供一個對外的PUSH的東西，也會提供一個拉模式，網(wǎng)站取數(shù)據(jù)就是拉的模式。這個地方做的工作其實就是用來對新鮮事的數(shù)據(jù)和模板進行匹配，然后合并產(chǎn)生成TML，把數(shù)據(jù)和模板匹配在一起形成一個模塊。
后面是一些技術(shù)細節(jié)的東西。第一是分發(fā)系統(tǒng)；第二是cache；第三是持久化存儲有渲染等等。
整個系統(tǒng)我們現(xiàn)在設(shè)計到Opnesource相關(guān)的，第一是ICE我們整個人人團隊里面引擎這一塊使用量最大的一個通訊框架，為我們提供了一個很好的cache集群，為我們很好的進行數(shù)據(jù)交互網(wǎng)絡(luò)通信方面的一些東西。其實我們很多系統(tǒng)是基于這個開發(fā)的，第三是memcache，所有SNS的公司如果沒用這個就不算2.0，我們也用用。我們在下層應(yīng)用層之間有一層代理，有點像代理服務(wù)器的感覺，實現(xiàn)了一些負載均衡策略等等。下面googleprotobuf對象的序列化及反序列化，這個東西其實可以說是非常好的，包括谷歌內(nèi)部都是使用這樣一個東西，我覺得非常好。下面二進制數(shù)據(jù)壓縮，還有多索引結(jié)構(gòu)，海量存儲引擎大體就是這些東西。
下面是Feed的分發(fā)系統(tǒng)。用戶發(fā)送一個新鮮事的時候傳給我們系統(tǒng)數(shù)據(jù)包括新鮮事數(shù)據(jù)內(nèi)容，還有一些合并策略一些權(quán)重數(shù)據(jù)。一個對象是很大的，加起來可能有幾K或者幾百個字節(jié)大小不等。首先要做的事情是要把這個數(shù)據(jù)拆一下，拆成公共用于數(shù)據(jù)再展示使用的一些文本數(shù)據(jù)，另外還有一個就是用來做排序。怎么定位Feed這樣一個索引結(jié)構(gòu)？索引結(jié)構(gòu)我們系統(tǒng)內(nèi)部INDEX架構(gòu)大概一個尺寸只有32個字節(jié)，CONTENT就很大了，這兩個數(shù)據(jù)會分別發(fā)到不同的地方，索引數(shù)據(jù)一個跟NEWSFeed另外一個給MINIFeed。我們發(fā)一條新鮮事，比如說有一個100個好友發(fā)一個日志用推模式，發(fā)一條新鮮事，我要索引結(jié)構(gòu)告訴我在我好友列表里要追加這樣一個新鮮事的索引，要知道我好友有哪些該把這個內(nèi)容發(fā)給誰，這個操作是什么量級？一秒鐘要有一千次。我查列表有一千次，有100個好友就是100。我是一個名人，有上百萬粉絲這個是吃不消的。我們第一次查列表可以到數(shù)據(jù)庫取，第二次就要到內(nèi)存，不能到數(shù)據(jù)庫上面查。最早的系統(tǒng)，大概一年多以前沒有內(nèi)存cache，說你這個東西搞得我們天天數(shù)據(jù)庫是紅的，我們做了以后就很好了，機器基本上沒有什么負載。第三異步線程池，有的時候會有一些脈沖爆發(fā)，我們要做一些控制。當我一秒鐘有一萬次請求，有一個脈沖一下來了一萬個請求，一次給我，我可以做一個細水長流慢慢消化掉。對用戶來說朋友看到你的改的狀態(tài)是在幾秒鐘以后，不算特別遲。但是你倆又沒有在一臺電腦面前，所以他感覺不到，稍微把脈沖數(shù)據(jù)做一個平滑的曲線。對于系統(tǒng)的負載能力有一個很好的提升，在分發(fā)里面對線程池數(shù)量是一個很重要的東西。
做講一個Feedcache的內(nèi)存優(yōu)化，講設(shè)計模式的時候，叫Flygeight。當時在書里面一個例子，說我們在WPS做文本編輯，每一個文字有各種屬性，字體大小等等，但是一篇文章同一個字出現(xiàn)N次。我們把大的數(shù)據(jù)描述數(shù)據(jù)對象在全局只有一份，我們需要使用這個字的時候，對應(yīng)那個位置存一個字根，對象在一個系統(tǒng)里面重復(fù)出現(xiàn)概率很大。這樣的操作對我們的幫助是很大的。我們曾經(jīng)試圖用這個做，但是發(fā)現(xiàn)在性能方面有一些問題。
我們把新鮮事內(nèi)容分成兩種，一種是數(shù)據(jù)內(nèi)容，另外一種是索引數(shù)據(jù)。索引數(shù)據(jù)相對來說比較小，我們在另外一個cache存儲這樣一個索引，其實從宏觀上也滿足flyweight理念。我們索引要發(fā)給100或者500人，他們拿到只是一個索引對象，真正指向內(nèi)容都是同一件事。對于每一個索引cache內(nèi)部我們也利用了同樣的思路，因為比如說我們散服務(wù)，我們把前站用戶放在十臺機器上面，也就是說我如果有100個好友，每臺機器上面平均算每一個服務(wù)上面有十個人的對于同一個新鮮事索引可能在每個服務(wù)里面出現(xiàn)十次，做這樣一個東西我們認為一個索引結(jié)構(gòu)32字節(jié)，用最小東西指向32字節(jié)又可以節(jié)約一些內(nèi)存開銷。
然后我們INDEX五要支持不同業(yè)務(wù)對不同的選擇條件。有同學(xué)問內(nèi)存怎么建一個索引。類似一個人存數(shù)據(jù)庫數(shù)據(jù)庫支持什么，叫一個多索引，一個數(shù)據(jù)庫表里面可以建N個不同的索引，甚至有聯(lián)合索引，但是我們很少在內(nèi)存里面能夠?qū)崿F(xiàn)這樣一個結(jié)構(gòu)。如果我們自己實現(xiàn)可能很復(fù)雜，對于新鮮事我要按照不同緯度建立索引怎么辦？其實提供了一個數(shù)據(jù)結(jié)構(gòu)，我們可以對不同的緯度做同一個索引，對對象里面同一個內(nèi)容做更新，字節(jié)也會自動跟著做變動。看到下面云里面放了四個對象，形狀不一樣，第一是按照形狀對四個對象做一個排序，第三是大小，對同一個是四個不同對象，這樣類似對象能夠支持不同的索引，我們使用它可以很方便實現(xiàn)多索引的結(jié)構(gòu)。
關(guān)于內(nèi)存的壓縮存儲，可以很明顯節(jié)約內(nèi)存。右邊圖是quicklz對比圖，這個壓縮和解壓縮速度都是非常好，使用過程中我們就使用了一種方式就是把對象進行序列化，再做壓縮，在我們系統(tǒng)能夠節(jié)約30%-35%的內(nèi)存。
然后講一下我們?yōu)槭裁匆胢emcache。第一我們要支持高并發(fā)，一個用戶頁面顯示30條新鮮事，我要進行30次，把30次我想要的對象取出來再發(fā)給前端做顯示。對于人人網(wǎng)這么大一個應(yīng)用可能每秒PV就好幾萬，我們需要這個東西搞定內(nèi)存的cache。還有一個就是我們數(shù)據(jù)量大，大家也知道現(xiàn)在服務(wù)器的內(nèi)存也是越來越大，原先剛到公司我們用的是16G的內(nèi)存覺得已經(jīng)比我們PC機大很多，再過一年，變成32、36，現(xiàn)在服務(wù)器搞到72G。我們要做內(nèi)存的cache，對數(shù)據(jù)查詢要求，隨著內(nèi)存里面cache內(nèi)容不斷增加，我們要保證查詢性能不斷增強。我們保證相對在我們數(shù)據(jù)量不斷增加時查詢性能有些下降但是不能特別大。另外一個，當我們cache不可能放在一臺機器上面，當一些服務(wù)器被重啟，我們需要cache量更大，要加一些機器進來。我們要保證整個cache能夠有擴容性，同時可以很方便摘掉一些機器， 我們需要所有cache互相之間有一些冗余。最后我希望我們cache策略、機器足夠多，我們現(xiàn)在有十幾，二十幾cache服務(wù)器，當我們做到上百臺，幾百臺機器的cache時，我們需要保證對于所有的cache服務(wù)器管理更加的方便，不是說要重新部署一次。我們是跟FACEBOOK學(xué)的，想做這樣一個東西，我講一下自己開發(fā)的東西只是MEMcache的PROXY，做這個開源項目有兩個，但是這兩個項目我們調(diào)研了一下不是特別理想，另外有一個動力讓我們自己做這個東西的原因是因為我之前是做客戶端服務(wù)器，對這種通訊等等東西還是比較有信心，另外一個就是說mbmcache協(xié)議是很簡單的，所以我覺得這個東西我們有把握做好，我們就做了一下，結(jié)果做成了。
基本的一個功能是什么，就是說在這個層面上我們把所有的cache的管理都放在上面，包括策略也放在上面，我們有一個cacheLOADER。我們新鮮事操作都是PV6，到數(shù)據(jù)庫里面查也是ID等于什么，這樣的話我做一個cacheloader可以很好跟memcache做配合，比如說我不做新鮮事，我要加?xùn)|西的時候只需要在cacheloaler做一個配制。這樣的話避免了開發(fā)人員重復(fù)開發(fā)一些用于加載的服務(wù)。另外一個就是為什么要有關(guān)cacheporxy，因為如果沒有這些，我們跟所有散服務(wù)必須放在客戶端上面，這個事情會給開發(fā)使用這個集群的人帶來很多不方便，隨著我們客戶端不斷增加，如果其他的業(yè)務(wù)不斷增加，使用這個集群的人越來越多，會帶來相同困擾，有這么一層我們就可以保證這個問題。
下面一個進索引持久化系統(tǒng)。為什么要做這個東西，是因為我們在一年以前，還沒有這個東西的時候，當時經(jīng)常會有一些問題。新鮮事有一些大改動，要把我們索引cache重啟，但是我這些cache在數(shù)據(jù)庫里面是沒有辦法存的，因為這個量很大，我們剛才說每天如果我們產(chǎn)生的總的新鮮事量是千級萬級以上的量，平均每個人有100個好友，其實總的一天產(chǎn)生新鮮事索引在幾十億規(guī)模。我們想把這些索引都存下來大概需要多少臺機器？可能需要上百臺機器。所以如果一秒鐘處理十幾萬，或者幾十萬至少也要100臺以上的機器，我們必須解決這個問題。另外我們不解決這個問題怎么做，內(nèi)存索引cache沒有的情況之下，我們需要把原先所有用戶產(chǎn)生的這些新鮮事的過程從頭到尾再放一次。
剛才說傳說中的解決方案，MYSPL是不欣，APENSOURCE還是不夠快，第三就是說GFS可能解決這個問題。但是我們這個系統(tǒng)買不到。我們做這個的時候，我們做了一些調(diào)研，這個里面包括新浪支持，還有百度支持的。大致上我們需要在每秒鐘解決十萬次。第三就是我們所有的每天產(chǎn)生的索引數(shù)據(jù)總量每天100G以上，解決的思路是什么？第一就是普通機器我們隨即讀寫訪問就是IOPS也就能道800+的量。既然硬盤只能這樣，我們怎么解決？據(jù)盤讀取數(shù)據(jù)是一塊一塊讀，我們索引很小，一個索引大小改動，我們會浪費很多寫的資源，我們必須要把隨即大量隨即寫變成一種順序?qū)懳募覀兙鸵堰@種所有的隨機的東西變成一種順序的問題，如果能夠變成順序的東西，我們用普通的機器可以搞定這個問題。
另外一個就是說如果我們要做這個事情的話，要做一些比如說IO五方面的東西，在使用的時候用了異步IO馬行，直接操作硬盤，使用的時候我們也跟英特爾做調(diào)研，選擇他們SSD提高硬盤寫的性能和讀的性能。
我們必須要把所有寫合并，把大量隨機變成順序?qū)懖僮鳎热恍枰龊喜ⅲ隙ㄎ覀冃枰劝阉械碾S機索引的寫操作放在內(nèi)存當中做一些滯后，整合以后再做寫讀。我們會把所有的寫讀操作通過LOG文件，把LOG記錄下來，機器宕機我們可以通過回放把這些數(shù)據(jù)讀出來，我們使用TT保存索引，為什么很快？因為他所有數(shù)據(jù)跑一遍都在內(nèi)存里面，所以跟內(nèi)存操作是一樣。我們使用TT做了一個東西，TT支持存儲方式比較簡單，作數(shù)據(jù)節(jié)點上面IO模型我們選擇異步IO。為什么用direct為IO屏蔽OS五的cache策略，最后使用SSD解決大量的并發(fā)讀取。
這個是整個系統(tǒng)節(jié)點，nidexNode責任存儲userid到最信一塊data，block的位置信息，我們把5億用戶的用戶ID到索引塊信息都放在內(nèi)存，也用不到10G，用TT保證系統(tǒng)里面所有文件至少全部在內(nèi)存里面放下。我們用32G機器放這個文件。另外TT實現(xiàn)的時候用的是共享內(nèi)存實現(xiàn)方式。只要機器不死，節(jié)點服務(wù)被我殺掉，操作系統(tǒng)還在，內(nèi)存還在，系統(tǒng)會把數(shù)據(jù)刷回硬盤。下面是DATAFILE，這就是DATAFILE的結(jié)構(gòu)，左邊是FILE1，右邊是FILE2。
最后講一下模板渲染。說到數(shù)據(jù)格式的一致性，我們現(xiàn)在新鮮事數(shù)據(jù)格式是用Feed的輸入很多來自各個不同業(yè)務(wù)，必須保證數(shù)據(jù)格式的一字形，輸出時，通過渲染引擎將數(shù)據(jù)變化為不同的VIEW，提供給各業(yè)務(wù)。技術(shù)方案Ctemplate提供高效的模板選擇能力，還有谷歌的方式。
我今天講了很多，大家想要有深入的了解歡迎大家加入我們的團隊，謝謝。
提問：剛才PPT很快過了，一些常見數(shù)據(jù)庫，mebcacheDB為什么不要了？
張鐵安：我們對這個東西了解不夠多，我們寫了數(shù)據(jù)200多個動不了，我們也不知道是什么問題。我們覺得不是特別可靠，因為這個東西上了以后必須保證不出問題，出了問題必須要知道怎么解決。
提問：你說光良有幾百萬粉絲，我們選擇推模式，我們要把幾百萬粉絲里面每一個粉絲把信息推送到他們上面去，快速獲得這些粉絲信息，粉絲信息是放在內(nèi)存里面。所以我想了解，如果是我這幾百個放在內(nèi)存是一個方式，但是幾百個粉絲是怎么組織的？
張鐵安：就是一個列表，我們發(fā)送會有一個表達式，我們放的時候不是說把所有放在里面，我們其實只做了一個幾萬的隊列。為什么這么做？有這么幾個目的，我們只對好友新鮮事，對于粉絲有幾百萬，這個列表實時有人加進來，這種情況下沒有辦法做一個像好友準確策略。我們做一個隊列，不要太長，我做一個幾萬，用戶登陸行為是這樣，上人人網(wǎng)以后在這個網(wǎng)站玩就是幾十分鐘就會關(guān)掉，關(guān)掉以后cache就沒有多大意義，所以逐出數(shù)據(jù)比較多。
提問：你說現(xiàn)在我把用戶放到內(nèi)存里面，查詢索引是通過ID查。我們數(shù)據(jù)庫里面是通過ID把這個ID和索引放到cache里面。
張鐵安：我們兩個內(nèi)存cache是用ICE做的。
提問：就是說這里面有一個像硬查詢，很多里面都是ID，把這個硬查詢也拆借出來。
張鐵安：我們memcache機器再多也不可能把所有新鮮事放到里面，我們現(xiàn)在要取一千個列表，會有不到一千個列表MIS有一個長尾效應(yīng)，大部分熱點數(shù)據(jù)要進行cache，對時間特別長的以前數(shù)據(jù)是不需要cache的。