12月19日很榮幸的參加了CU舉辦的PHP交流會,可能準(zhǔn)備的時間比較倉促我寫的《完全用nosql輕松打造千萬級
數(shù)據(jù)量的微博
系統(tǒng)》
ppt,大家可能不能很好的理解。我現(xiàn)在整理一下重新分享給大家,有什么問題,可以加我的QQ或者發(fā)mail跟我討論.
其實微博是一個結(jié)構(gòu)相對簡單,但數(shù)據(jù)量卻是很龐大的一種產(chǎn)品.標(biāo)題所說的是千萬級數(shù)據(jù)量也并不是一千萬條微博信息而已,而是千萬級訂閱關(guān)系之間發(fā)布。在看我這篇文章之前，大多數(shù)人都看過sina的楊衛(wèi)華大牛的微博
開發(fā)大會上的演講.我這也不當(dāng)復(fù)讀機(jī)了,挑重點跟大家說一下。
大家都知道微博的難點在于明星會員問題,什么是明星會員問題了,就是劉德華來咱這開了微博,他有幾百萬的粉絲訂閱者，他發(fā)一條微博信息,那得一下子把微博信息發(fā)布到幾百萬的粉絲里去，如果黎明、郭富城等四大天王都來咱來開微博，那咱小站不是死翹翹了.所以這時消息隊列上場了。在我的
架構(gòu)里有一個異步publish集群,publish的任務(wù)都去zeromq隊列讀取隊列.zeromq是目前已知開源的消息傳遞最快的一個。具體關(guān)于zeromq可以自己
google。zeromq有一個問題是不能持久化數(shù)據(jù),這個自己做持久化存儲.回過剛才那個話題,把明星會員的粉絲按照"活躍度"進(jìn)行分級。"活躍度"是根據(jù)登陸頻度,時間,發(fā)布微博等因素大致分為鐵桿粉絲、愛理不理、半死不活三大類分到不同的發(fā)布集群中去. 鐵桿粉絲類型的異步發(fā)布集群，發(fā)布速度肯定是最快的.微博的信息是用handler
socket保存到
mysql。這個信息ID,是用rdtsc+2位隨機(jī)整數(shù)拼接而成的 64位整數(shù)唯一ID，防止出現(xiàn)自增ID出現(xiàn)的多
服務(wù)器 id一致性的問題.在publish的時候，集群只是把微博信息的ID發(fā)送給redis的訂閱者。所以這個數(shù)據(jù)是很快的。而且訂閱者的list里只保存的是ID.在
內(nèi)存的占用率上也不是很高.
下面我給大家看一下我的mysql和redis數(shù)據(jù)結(jié)構(gòu)
在我的結(jié)構(gòu)中還有一個重要角色就是"Key GPS Server"(簡稱:KGS)簡單來說,這個是分布式數(shù)據(jù)存儲的中心索引
服務(wù)器.一切數(shù)據(jù)的存儲和獲取,都通過KGS來定位.KGS支持多個服務(wù)器,多個機(jī)房多重備份存儲。KGS是以Tokyo Cabinet的hash db為存儲的socket
server。記錄key跟服務(wù)器之間的對應(yīng)關(guān)系.KGS的任務(wù)就是告知key該存儲在哪幾臺服務(wù)器上,或者告知該key存儲在哪幾臺服務(wù)器上，并不做其他的服務(wù).這樣大大的減輕KGS的壓力.
再說一下Redis集群,redis是以純內(nèi)存形式模式運行,關(guān)閉了熱備的功能(redis的熱備并不是那么好). 自己寫了個backendserver.在每臺運行redis的機(jī)子上都運行著backend socket 進(jìn)程, backend進(jìn)程也是以tc的hashdb為存儲。備份著當(dāng)前服務(wù)器的redis數(shù)據(jù)。當(dāng)redis重啟的時候，從本機(jī)的bakcend db 加載所有數(shù)據(jù).Redis的集群是以用戶水平切分法來分布的
現(xiàn)在該輪到mysql里, 在這個架構(gòu)中,基本消除了這邊緩存 那邊緩存的問題。因為在這個集群中的每個服務(wù)都是高速運行的.唯一的一處的cache就是在
php端的eAccelerator localcache. eAccelerator是基于共享內(nèi)存的,所有速度比基于socket類型的cache快多了. eAccelerator緩存了用戶top N條的微博信息還有從KGS查詢的結(jié)果。看到這里有人問了，你把用戶信息和微博信息都放在mysql里,怎么能不用cache了.嘿嘿，因為我用了handler socket。HS是小日本寫的一款mysql插件.HS避開了MySQL通訊協(xié)議,直接讀取MySQL引擎。在多核、大內(nèi)存、InnoDB引擎環(huán)境,性能直超memcached.HS能以Key-Value方式直接讀寫mysql引擎
總結(jié)
Google首席科學(xué)家講過一句話，就是一個大的復(fù)雜的系統(tǒng)，應(yīng)該要分解成很多小的服務(wù).我的這個架構(gòu)也是由一個個小的集群來共同處理大數(shù)據(jù)量發(fā)布數(shù)據(jù)。有的人為什么不用mongodb了,因為mongodb是一款大眾性的分布式nosqldb,我們有自己的key分布策略,不太適合用mongodb. 不理解redis的存儲關(guān)系的同學(xué)，可以先參考一下 Retwis,Retwis是用純redis實現(xiàn)的簡單微博.
具體的架構(gòu)圖、流程圖、ppt
文件。請下載附件來閱讀.
http://code.google.com/p/php-tok ...&q=#makechanges我的QQ: 531020471 mail: lijinxing#gmail.com
我的 blog:
http://www.cellphp.com/article-r ...s-tokyocabinet.html
