前些日子，以前組裡的同事參加乙個
poc測試，測試中有乙個異常測試用例，就是在測試程式執行的時候，將流程
kill
掉來模仿系統宕機的情況，然後將流程重新啟動，最後檢查是否有資料丟失。這個測試用例出現了問題，最後檢查資料，總共有幾十萬條資料，大約丟失了十幾條。同事將他們的做流程發給我，讓我幫忙看一下，流程大致如下：
該bw
流程從jms
的queue
上接收訊息，將訊息進行處理後傳送到另乙個
queue
中。流程中的
jms queue receiver
的acknowledge mode
是auto
。從這個流程中，不難判斷出，出現資料丟失的原因是當
kill掉bw
流程的程序的時候，流程已經從
jms伺服器上取到訊息，但是整個流程還沒有執行結束。因為
jms queue receiver
使用了auto acknowledge
方式，在
receiver
接收到jms
訊息的時候就會將訊息從
jms server
中confirm
掉。如果這時流程被
kill
掉，jms
已經被confirm
掉，但是資料還沒有處理完，這條資料就丟失了。
要解決這個問題，就要保證流程在執行完成之前，不要將訊息資料從
jms伺服器上
confirm
掉，這樣在流程重新啟動的時候，就可以重新處理這個資料了。流程修改如下：
在這個流程中
jms queue receiver
使用clientacknowledge mode
，並且在新增了
confirm activity
。這樣只有當流程執行到
confirm
的時候才會將訊息從
jms server
上confirm
掉。如果流程在執行的過程中中斷，沒有
confirm
的訊息還在
jms伺服器上，流程下次重新啟動的時候，還會再次處理這個資料。
但是這樣還是會有問題，流程中有乙個
jms queue sender
，需要將處理後的資料傳送到另乙個
queue
上去。如果按照上面圖中的流程進行設定，
jms queue sender
可能會被重複呼叫，比如了流程中斷的時候，正好是在
sender
之後，confirm
之前，這樣資料是不會丟失了，但是最後的結果可能是資料多了，因為有資料被
queue sender
重**送了。流程還需要再改進一下。
在這個流程中，將
confirm
提到了jms queue sender
前面，並且在
confirm
和queuesender
之間新增了
checkpoint
。checkpoint
可以儲存當前流程的資料和狀態，通過這些資料和狀態，可以對執行失敗的流程進行恢復。恢復操作是從流程中斷前的最後乙個
checkpoint
開始執行的。我們看一下這個流程，如果流程是在
confirm
之前中斷的，那流程在下次啟動的時候就會重新處理這個訊息，因為沒有執行到
sender
，所以就不會有重複訊息。如果流程是在
checkpoint
之後中斷的，那麼在下次啟動的時候，就會從
checkpoint
開始執行將訊息通過
sender
傳送出去，也保證了資料不會丟失。當然了，這個流程也不完美，如果中斷發生在
confirm
和checkpoint
之間，那這個資料可能就丟失了。也許你會說這樣不就和前面那個流程一樣了？上乙個流程在
queue sender
和confirm
之間中斷的話，會出現重複資料；這個流程在
confirm
和checkpoint
之間中斷會丟失資料，而且從流程上看，發生這種情況的概率是差不多的，貌似沒有什麼改進。其實在我們測試的過程中，發現
jms queue sender
的耗時比其他的
activity
多幾倍甚至多乙個數量級，所以這個流程出問題的可能性比前面乙個流程要小很多，所以目前這個流程比前乙個要可靠很多。即便是真的發生了資料丟失，那幾十萬條資料丟失一兩條，這樣的
poc結果使用者也是可以接受的，而且這個流程也有效能的保證。
如果是使用者的生產環境，我們要保證業務的萬無一失那怎麼辦呢。最保險的辦法就是使用
transaction
了。我們修改流程如下：
將confirm
和jms queue sender
放到乙個事務中，只有兩個都成功才會起將訊息從
jms server
上confirm
掉並把處理後的訊息傳送出去。這樣不論流程在何時中斷，都不會出現資料的丟失和重複。但是使用
transaction
的時候效能通常會比不使用
transaction
差一些。這個需要根據客戶的實際業務場景進行使用。
這裡也只是個簡單的例子，真正的客戶業務環境要複雜的多，需要靈活的使用和搭配這些確保交易完整性的技術，確保業務系統的可靠性。
補充說明：
非常感謝各位朋友的關注，對於
junjiez1984和lin49940所提的問題我這裡做一下解釋，在這個poc裡面，我們採用transaction是tibco提供的分布式事務外掛程式xa transaction manager，並不是bw裡面預設自帶的jms transaction，jms transaction確實達不到我們上面的要求。xa transaction manager需要單獨購買並安裝，目前最新版本為1.0.2，配合bw進行使用，其支援的事務如下：
活動型別
是否支援
支援條件
jdbc activities 是
使用xa連線方式
jms activities 是
使用xa連線方式
activeenterprise adapter activities 是
使用jms通訊方式；對應的
jms使用
xa連線方式
tibco iprocess businessworks connector activities 是
使用xa連線方式
(xa connection type)
ejb activities 否
另外對於訊息沒有confirm而產生的多個job問題，因為這個流程是當時的乙個poc流程我們只是簡單的處理中斷問題，所以沒有care這種多餘job，在實際的實施過程中，我個人更傾向於confirm掉所有的訊息，將出錯的訊息記錄入日誌，進行重做來保證資料的完整性。本篇文章只是用於介紹tibco所支援幾種能夠確保事務完整的技術手段，希望能夠起到拋磚引玉的作用。
計算廣告系列篇 3 交易
當才華還撐不起你的野心時，請默默前行。2015年9月，美國工程院院士 前雅虎副總裁andreibroder首次提出了計算廣告 computational advertising 的概念，他認為計算廣告是一門由資訊科學 統計學 電腦科學以及微觀經濟學等學科交叉融合的新興分支學科。的確，計算廣告無論是從...
高手訓練 數字DP系列（暫完）
也就是不停講題寫題，沒講什麼實質性數字 dp 甚至只有後面三題有點點味道。前面就是用到了數字的相關知識而已。題目大意 多組資料，每組幾個操作 opt 與n個數，opt 可能是 and xor or 求任意兩數 opt 運算後的最大值。solution 顯然我們得分操作進行。xor 當 opt xor...
WCF EF實戰系列一
記得有很久沒有研究過新的技術了，反正上次買了本 wcf服務程式設計的書，我記得只看了幾頁後就再也沒有動過。可能是年紀大了，沒精力再去研究一些新的技術了。再說在解決分布式的問題時，還有一套 remoting 的方案可以使用。因此也一直沒有公升級 vs2008 對wcf 的相關知識也只是在網上難得看一下...