Terry.Li-彬
          
				
          虛其心，可解天下之問；專其心，可治天下之學(xué)；靜其心，可悟天下之理；恒其心，可成天下之業(yè)。
          
			          		
		
          
	
          

          

          
	
          
		
          
			
 
BlogJava ::
首頁 ::
新隨筆 ::
聯(lián)系 ::
聚合
 ::
管理 ::


			
			
				

          
	
          
		
          
			
			
			
				 
				143 
				隨筆 ::
				344 文章
				::
				130 評論
				::
				0 Trackbacks
			
		
          
	
          

          

			          		
		
          
	
          

          


          


          
	
					

          
	
	
	
          
		
		
				要是不清楚什么是feed，google之。?

          Feed是sns類應(yīng)用的核心和最復(fù)雜的部分，就是sina微博中看到的“我關(guān)注的人”的消息。像人人網(wǎng)中的“新鮮事”等等，都是一個東西。你想啊，你關(guān)注了幾千人，又被幾千人關(guān)注，你發(fā)了一個消息，另外幾千人怎么看到哪？拿數(shù)據(jù)庫做join和in操作肯定立刻掛。而且像sina weibo，數(shù)據(jù)和訪問量龐大，怎么實現(xiàn)哪？這其實就是傳說中的推和拉的選擇，人人網(wǎng)寫過一篇文章：http://news.csdn.net/a/20100726/277273.html，簡單來說以推為主體。我猜測可能在某些情況下會使用拉，例如這個賬號很久不登錄，太不活躍，給他推東西純屬浪費。嗯。。。，這方面也歡迎一起來猜猜。?

          基于這些，我猜測的第1版架構(gòu)圖（我們現(xiàn)在就是這樣做的，規(guī)模比較小，還看不出問題）：?

          ?

          整個架構(gòu)基于memcached + mysql，圖中分了ABC三個區(qū)域。所有的消息存儲在mysql中，無論推送給多少人，只存儲一份。另外有一個索引表，用來記錄推送關(guān)系，推送給1000個人，就增加1000條記錄，也就是圖中的A。當(dāng)發(fā)生查詢時，從索引表中根據(jù)用戶編號進(jìn)行一次簡單查詢（基于用戶編號為索引和條件的select），拿到索引結(jié)果后，進(jìn)入B，從memcached中讀取實際信息。如果不存在或者不全，進(jìn)入C，根據(jù)索引信息讀取網(wǎng)友實際發(fā)表或者轉(zhuǎn)載的內(nèi)容，用模板生成消息并存儲到memcached中，然后返回來。?

          在整個過程中，B是memcached集群，性能應(yīng)該問題不大。C是cache后面的東西，其中的數(shù)據(jù)庫查詢也是基于索引表中給的對象主鍵，分表條件等進(jìn)行的分庫分表基于主鍵的查詢，性能問題應(yīng)該也不大。關(guān)鍵是A區(qū)。我們現(xiàn)在的方案是用guzz框架把索引表分到單獨的一組數(shù)據(jù)庫中，然后根據(jù)用戶id進(jìn)行切表，每個人保留最多200條最新消息的索引。總的來說，每張表的大小還在控制內(nèi)。對于像#話題#等也是一樣的，建立索引表分發(fā)。無論怎樣，實際的消息只有一份。?

          我猜測，sina微博第一版系統(tǒng)應(yīng)該就是這樣。架構(gòu)簡單實用。?

          但隨著規(guī)模的擴(kuò)大，A區(qū)索引表肯定會逐步出現(xiàn)大量性能問題。要升級到第二，第三版。這兩個之間或許是一步到位的。?

          第二第三版架構(gòu)猜測：?

          A區(qū)的性能問題不是mysql能夠解決的，但幸好A區(qū)的數(shù)據(jù)結(jié)構(gòu)非常簡單。就是以 用戶id+某個動態(tài)功能 為key下的一個固定大小的索引集合。最簡單的辦法就是把mysql換成nosql，這個數(shù)據(jù)結(jié)構(gòu)用nosql應(yīng)該非常容易實施。我沒有用過nosql，但通過資料來看，相比mysql肯定是一大性能提升。我們暫且推測其為第二版方案吧。歡迎實際用過nosql的來談?wù)勑胁恍小?span id="wmqeeuq"    class="Apple-converted-space">?

          我們假設(shè)，第二版方案也解決不了問題。A區(qū)的性能問題太大了，怎么辦？如果這樣，我想索引系統(tǒng)只能是自己做了，誰也靠不住。我有個猜測，歡迎討論。看下圖。?

          ?

          這個架構(gòu)是完全為feed定制的，我們?yōu)槊總€ 用戶id+某個動態(tài)功能 分配一個磁盤block。在索引表中，我們知道每條索引記錄的大小是固定的（假設(shè)每條1k大小），而為用戶提供的最多最新動態(tài)數(shù)也是固定的（假設(shè)200條）。那么我們這個block就分配固定的201K，前面的1k是頭信息，后面的200k存儲最多200條的索引記錄。?

          在頭信息中，記錄這個塊操作的系統(tǒng)版本號（升級使用），用戶信息，操作的偏移量，總動態(tài)數(shù)等等。當(dāng)插入一條新索引時，根據(jù)操作偏移量直接定位位置，寫入；如果已經(jīng)寫到第200條，回到第一條覆蓋寫。讀取的時候，根據(jù)偏移量數(shù)據(jù)直接讀。因為記錄大小固定，block維護(hù)簡單，順序讀寫，效率肯定不差。而這些block文件塊，將存儲在一套分布式文件系統(tǒng)中，依靠還算成熟的hadoop技術(shù)，無限擴(kuò)展這個大集群。?

          相比數(shù)據(jù)庫的優(yōu)勢，還省去了清理過期數(shù)據(jù)的問題。?

          這里面沒有討論block塊緩存的問題，這是分布式文件系統(tǒng)的工作。對于不同的動態(tài)，可能block的大小會不一樣，這都是可以的。?

          不知道猜的對不對。          
		

	
          
	
	
          
		posted on 2011-03-09 21:45 禮物 閱讀(971) 評論(0)  編輯  收藏  
	
          

          







          
	    
    




          





          


          

	
          
		
          
				
		
	
		
          
		
		
          只有注冊用戶登錄后才能發(fā)表評論。
          
		
          
			
		
          
			
		
          
		
		
          
		
		          		
		
          
		
          			
		
		
		
		
          
		
          
		
		
          
		
          
			網(wǎng)站導(dǎo)航:
		
		
          
		
          
			
		
          	
		
          
			 
		
          
		
          
			
		
          
		
          
			
				
		
          		
	
          	

          



          

				

          




    







          
        
	




主站蜘蛛池模板：
昌黎县|
临洮县|
遂昌县|
纳雍县|
富顺县|
营口市|
蒙阴县|
博罗县|
光山县|
石林|
东莞市|
大竹县|
隆昌县|
府谷县|
合江县|
玉林市|
青铜峡市|
霸州市|
甘谷县|
玉龙|
临高县|
滕州市|
济源市|
农安县|
和硕县|
贺州市|
历史|
潮安县|
扎鲁特旗|
柳江县|
友谊县|
邵阳县|
永年县|
万载县|
班戈县|
合水县|
东乌珠穆沁旗|
竹北市|
游戏|
霍林郭勒市|
玉林市|