Posted on 2011-01-19 14:57
點點滴滴 閱讀(987)
評論(0) 編輯 收藏 引用 所屬分類:
10 服務器
既然說到了消息隊列，那我們繼續來稍微多聊一點吧。
我們所能想到的最簡單的消息隊列可能就是使用stl的list來實現了，即消息隊列內部維護一個list和一個互斥鎖，putMessage時將message加入到隊列尾，getMessage時從隊列頭取一個message返回，同時在getMessage和putMessage之前都要求先獲取鎖資源。
實現雖然簡單，但功能是絕對滿足需求的，只是性能上可能稍稍有些不盡如人意。其最大的問題在頻繁的鎖競爭上。
對于如何減少鎖競爭次數的優化方案，Ghost Cheng提出了一種。提供一個隊列容器，里面有多個隊列，每個隊列都可固定存放一定數量的消息。網絡IO線程要給邏輯線程投遞消息時，會從隊列容器中取一個空隊列來使用，直到將該隊列填滿后再放回容器中換另一個空隊列。而邏輯線程取消息時是從隊列容器中取一個有消息的隊列來讀取，處理完后清空隊列再放回到容器中。
這樣便使得只有在對隊列容器進行操作時才需要加鎖，而IO線程和邏輯線程在操作自己當前使用的隊列時都不需要加鎖，所以鎖競爭的機會大大減少了。
這里為每個隊列設了個最大消息數，看來好像是打算只有當IO線程寫滿隊列時才會將其放回到容器中換另一個隊列。那這樣有時也會出現IO線程未寫滿一個隊列，而邏輯線程又沒有數據可處理的情況，特別是當數據量很少時可能會很容易出現。Ghost Cheng在他的描述中沒有講到如何解決這種問題，但我們可以先來看看另一個方案。
這個方案與上一個方案基本類似，只是不再提供隊列容器，因為在這個方案中只使用了兩個隊列，arthur在他的一封郵件中描述了這個方案的實現及部分代碼。兩個隊列，一個給邏輯線程讀，一個給IO線程用來寫，當邏輯線程讀完隊列后會將自己的隊列與IO線程的隊列相調換。所以，這種方案下加鎖的次數會比較多一些，IO線程每次寫隊列時都要加鎖，邏輯線程在調換隊列時也需要加鎖，但邏輯線程在讀隊列時是不需要加鎖的。
雖然看起來鎖的調用次數是比前一種方案要多很多，但實際上大部分鎖調用都是不會引起阻塞的，只有在邏輯線程調換隊列的那一瞬間可能會使得某個線程阻塞一下。另外對于鎖調用過程本身來說，其開銷是完全可以忽略的，我們所不能忍受的僅僅是因為鎖調用而引起的阻塞而已。
兩種方案都是很優秀的優化方案，但也都是有其適用范圍的。Ghost Cheng的方案因為提供了多個隊列，可以使得多個IO線程可以總工程師的，互不干擾的使用自己的隊列，只是還有一個遺留問題我們還不了解其解決方法。arthur的方案很好的解決了上一個方案遺留的問題，但因為只有一個寫隊列，所以當想要提供多個IO線程時，線程間互斥地寫入數據可能會增大競爭的機會，當然，如果只有一個IO線程那將是非常完美的。
理解：
1).提供一個隊列容器，里面有多個隊列，每個隊列都可固定存放一定數量的消息。網絡IO線程要給邏輯線程投遞消息時，會從隊列容器中取一個空隊列來使用，直到將該隊列填滿后再放回容器中換另一個空隊列。而邏輯線程取消息時是從隊列容器中取一個有消息的隊列來讀取，處理完后清空隊列再放回到容器中。
2).交換隊列，一個給邏輯線程讀，一個給IO線程用來寫，當邏輯線程讀完隊列后會將自己的隊列與IO線程的隊列相調換