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