一. 背景
阿裡雲mns消息服務的規範中，每條message都有個預設的visibilitytimeout，worker在接收到消息後，timeout就開始計時了。
如果worker在timeout時間内沒能處理完message，那麼消息就有可能被其他worker接收到并處理。
timeout計時的好處是：消息處理完之後需要顯式地deletemessage，那麼如果worker程序crash等情況發生，這條message還有機會被其他worker處理。
一些使用者會将隊列的預設visibilitytimeout設定得比較長，以確定消息在被worker處理完之前不會逾時釋放。
二. 問題
但是，在一些應用場景中，我們假設：
隊列的visibilitytimeout是6個小時。
a worker接收到了message m1，但是worker在處理完消息之後，程序發生了crash或者機器發生了重新開機。
那麼m1這條消息至少在6個小時之後才會被某個worker接收到并處理。而自己寫代碼處理failover的情況的話，程式又會變得比較複雜。
三. 目标
在一些即時性要求比較高，并且又希望盡快響應每一條消息的場景下，我們會希望：
1. 隊列的visibilitytimeout比較短。比如是5分鐘，這樣的話，在發生了程序crash之後，最多5分鐘，之前未處理完的消息就會被某個worker接收到并處理。
2. worker處理消息的過程中，耗時很有可能超過5分鐘，那麼消息在被處理的過程中，不能逾時。
四. 方案
對于這樣的場景，我們提供一個bestpractice的c# demo：（請見附件）
具體的做法是，在worker處理消息的過程中，為消息定期檢查是否需要做changevisibility，worker處理完之後依然是主動deletemessage。
如果有任何問題，歡迎大家在論壇發帖，或者直接加入我們的官方mns技術支援旺旺群 （群号51222373）。
下面是對于程式的幾點說明:
1. 運作前需要 填寫 accessid, accesskey, endpoint
2. 變量說明：
messageminimallife是消息注冊時必須有的最少的life長度。需要這個的原因是，比如消息register的時候已經隻剩下0.1秒的逾時時間了，那麼注冊進來也來不及changevisibility延長生命。是以， messageminimallife是為了確定message能活到被changevisibility，使用者可以自己根據業務壓力來設定。
timerinterval是manager内部的timer的interval。隻需要確定在message到達 messageminimallife之前，timer會被啟動就足夠了。時間可以設定得比較短（檢查得就比較頻繁）。
queuemessagevisibilitytimeout是sample裡message的預設逾時時間，是queue的屬性。sample裡每次changevisibility的時候，會把消息的visibilitytimeout設定為queuemessagevisibilitytimeout， 是以它的值需要大于 timerinterval+ messageminimallife，以確定消息不會逾時。
messagetimeout是message在manager裡面的逾時時間，比如某個worker卡住了，消息在5個小時之後依然沒有處理完畢（假設5個小時遠遠超出消息的正常處理時間），那麼manager就不會再為message做changevisibility了，會放任message的visibility逾時。
3. 流程說明：
worker在receivemessage之後，會先做registermessage，然後處理message，最後再調用manager的deletemessage。
manager在消息第一次注冊進來之後，調用threadpool排程一個changevisibilitytask檢查是否需要changevisibility，并且把message加到内部的messages清單中
manager内部的timer，會定時調用parallel啟動 changevisibilitytask檢查messages清單裡的所有message
"manager.changemessagevisibility (changevisibilitytask)"相關的具體事情，在流程圖裡有顯示。流程圖如下
changemessagevisibilitysample.zip
[ 此帖被消息小二在2015-11-23 18:04重新編輯 ]