如果大家关注SOA的事务一致性的处理，那么不妨看看我们是怎么解决的
生活随笔
收集整理的這篇文章主要介紹了
如果大家关注SOA的事务一致性的处理，那么不妨看看我们是怎么解决的
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
作者:? efscao? ?? 時間:? 2012-2-5 17:58 ? ?? 標題:? 如果大家關注SOA的事務一致性的處理，那么不妨看看我們是怎么解決的
SOA的理念日漸深入人心，銀行業務系統也必將轉向SOA，這意味著今后絕大多數應用都要成為服務的集成者——這就帶來一個非常關鍵的問題：如何解決集成服務應用普遍存在的一致性問題？當前金融行業正在運用的集成服務應用平臺和框架都只能通過一種自動撤消機制（即所謂沖正，效果類似數據庫的回滾）來解決這個問題，但在許多業務場景中，自動撤消機制并不適用。
完善的服務層應用平臺應該不僅僅提供“自動撤消處理”機制，還提供“手動繼續嘗試處理或撤消處理”機制來解決這個問題。后者和下載文件時我們常用的“斷點續傳”的效果非常相似，能夠幫助業務人員在第一時間內用極為簡單的操作修正一致性問題，同時，由于是在業務人員的監控下采取修正動作，馬上可以看到修正結果，因此，不會有“自動撤消處理”可能產生的資金風險，能夠有效地提升業務辦理效率和服務質量，并降低操作風險和系統的數據差錯率。需要特別指出的是，這并不需要開發人員做出特別的、額外的設計。
作者:? gavenwei? ?? 時間:? 2012-2-5 19:48
沒看明白，是說將當前的撤銷和沖正 和在一起嗎？
作者:? efscao? ?? 時間:? 2012-2-5 20:01
意思是：所有的服務接口，不但應該提供一個統一的沖正接口（當然，這個沖正也可以在服務系統內部觸發，而不是依靠調用這個接口），還應該提供繼續嘗試處理和撤銷處理接口，前者可以完成先前沒有完成的工作，后者可以抹除先前已經部分完成的工作。當然，服務接口的應答中還應該包含一個參數，表明當前這次服務調用是否出了一致性問題，如果出了一致性問題，服務的消費者（例如，前臺系統）就可以調用繼續嘗試處理和撤銷處理接口來解決問題
作者:? efscao? ?? 時間:? 2012-2-5 20:05
完善的服務系統，除了提供一般的服務接口，還要提供一些一致性處理接口，這些處理接口僅包括一個統一的沖正接口是不夠的，還應該包括統一的繼續嘗試處理接口和（部分）撤銷處理接口
作者:? pacman2000? ?? 時間:? 2012-2-5 22:15
還是要人工處理，并沒有從根本上消除不一致的問題啊。而且，即使有人工處理，每日的對賬還是必不可少的。因為人工也可能有疏漏。
作者:? efscao? ?? 時間:? 2012-2-5 22:37
錯了，這個人工處理是不同于現在的人工處理的，它是"傻瓜"式的，只需點擊“繼續嘗試處理”或者“撤銷”這兩個按鈕之一，直到全部成功或全部撤銷
作者:? efscao? ?? 時間:? 2012-2-5 22:41
當然，有了這些接口不等于對賬就不要做了。但要知道，有了這些接口，不上的帳將大大減少，并且這些錯賬的處理也可以用這些接口支持，從而大大減少錯賬處理的人工工作量
作者:? kinghq? ?? 時間:? 2012-2-6 08:26
你這不是要煩死用戶么？現由數據庫來保證的話，不會煩用戶，最不濟，用戶還有撒氣的地。
作者:? efscao? ?? 時間:? 2012-2-6 09:08
當你在一個SOA架構中，要集成多個WebService時，你怎么能夠奢望數據都在一個數據庫中？不在一個數據庫中，你就不能依賴數據庫事務機制來保證一致性。并且，實際運行起來需要用戶用這種“傻瓜”方式處理一致性問題的相對來說，比例還是很少的，通常不到1%，談不上“煩死”。相反，現在的許多系統，如果對賬后錯賬較多，處理錯賬的人經常“煩死”
作者:? taelons? ?? 時間:? 2012-2-6 09:38
聽起來象分布式事務處理的機制，我想到的是spring+atomikos
作者:? nannan5000? ?? 時間:? 2012-2-6 09:39
沒看懂lz 想要實現什么
作者:? 家住海淀? ?? 時間:? 2012-2-6 09:41
手動繼續嘗試處理或撤消處理
還是需要手工核查？這個工作量吃得消嗎？縱然分類，是不是沒有問題的也得看一遍？
如果規則清晰，自動化并非不可能
作者:? efscao? ?? 時間:? 2012-2-6 10:13
我們的模型和事務模型還是有較大不同的。事務模型的目標是確保當某個步驟失敗時，所有變動恢復原樣。我們的模型有一半類似這個機制，但另一半則相反，盡管某個時刻某個步驟沒有成功，但我們還是試圖讓業務最終能夠做成功，這是事務模型辦不到的。實際業務環境中，后者可能更有效，你想，一個操作員費了很大勁，輸入了很多數據，然后點了確定按鈕，但你的程序處理過程中某一步有問題過不去，你就因此全部回滾，并告訴操作員交易失敗，操作員一定很不爽。前臺應用做的不好話，操作員還得再輸一遍數據，那他恐怕就會有點煩了。
作者:? 家住海淀? ?? 時間:? 2012-2-6 10:26
efscao 發表于 2012-2-6 10:13?
我們的模型和事務模型還是有較大不同的。事務模型的目標是確保當某個步驟失敗時，所有變動恢復原樣。我們的 ...
我只關心最終需要手工處理的交易量在全部交易量中的比例是多少？
作者:? efscao? ?? 時間:? 2012-2-6 10:34
家住海淀 發表于 2012-2-6 09:41?
手動繼續嘗試處理或撤消處理
還是需要手工核查？這個工作量吃得消嗎？縱然分類，是不是沒有問題的也得看 ...
呵呵，是我沒講清楚，但這畢竟是一個大家以前從未設想過的新模型，解釋和理解都要費點勁
再抄點東西給大家分享一下，歡迎拍磚啊
Service Center的一致性保障機制
Service Center為集成型服務應用提供了完備的一致性保障機制，這一重要特征使其非常適合被用作新產品服務和大前置等集成服務類應用系統的應用平臺。Service Center的一致性保障機制分為“自動撤消處理”和“手動繼續嘗試處理或撤消處理”兩種模式（簡稱自動處理模式和手動處理模式）。所謂自動處理模式——也是當前金融行業已經運用的一些集成服務應用平臺和框架所普遍采用的模式——就是在集成型服務應用的處理過程中，如果有一個步驟沒有成功，則向訪問者返回失敗，并由應用框架自動發起先前已經被該應用成功調用的服務的撤消處理。
需要注意的是，自動處理模式難以應對某些一致性問題。設想這樣一個場景：客戶帶著現金來銀行購買基金，柜臺系統訪問的代銷基金集成服務應用一般要先調用本行帳務系統的服務以登記現金的收取，成功后調用基金公司的購買基金服務，再成功后向柜臺系統返回“交易成功”，由柜員收訖現金。如果規定時間內沒有收到基金公司應答（一個結果不確定的步驟），我們能夠使用自動處理模式解決問題么？如果我們把這種未收到應答的情形當作失敗步驟并啟動自動撤消處理，結果很可能就是客戶既買到了基金，同時柜員又告知客戶交易失敗，向客戶退還了現金！當然，有些銀行采取這樣的做法：即便未收到基金公司的應答，也當做成功步驟繼續處理。這就可能造成基金沒有買到而客戶現金卻被收取，客戶必然要投訴，而問題解決起來可能相當繁瑣（在試圖解決問題的時候基金價格很可能已經發生變動，或者已經銷售完）。
有些開發人員發現了這種問題，他們一般采用以下兩種方式來處理：
1、? ? ? ? 分解處理方式。在上述情形發生時，向柜臺系統返回“沒有收到基金公司應答”，根據操作說明，柜員需要立即查詢基金公司的處理結果，如果成功，則收訖現金，如果不成功，則進行一致性處理——撤消本行帳務系統的現金收取登記，或者單獨調用基金公司的購買基金服務。
2、? ? ? ? 整體處理方式。在上述情形發生時，向柜臺系統返回“沒有收到基金公司應答，請選擇繼續嘗試處理或撤消處理”，柜員在終端上只能選擇“繼續”或“撤銷”。一旦選定，柜臺系統會調用一個專門處理這種情形的一致性處理服務。如果柜員選擇了繼續嘗試處理，該服務會先查詢基金公司的處理結果，成功則返回“交易成功”，柜員收訖現金，失敗則返回“交易失敗”，并啟動自動撤消處理以撤消本行帳務系統的現金收取登記，柜員退還現金；如果柜員選擇了撤消處理，該服務會先查詢基金公司的處理結果，成功則先調用基金公司的撤消購買基金服務，然后再調用本行帳務系統的撤消現金收取登記服務，最后返回“交易已經撤消”，柜員退還現金。
（抱歉，不知道怎么發圖）
圖2.1 用整體處理方式處理一致性問題的服務應用
顯然，從業務角度看整體處理方式要優于分解處理方式——對于柜員而言，操作壓力大大降低，不容易出錯；對于銀行而言，不需要向柜員開放“撤消本行帳務系統的現金收取登記”和“單獨調用基金公司的購買基金服務”等功能，更好地控制了操作風險。
但是整體處理方式需要開發人員針對具體應用進行極其細致而繁瑣的一致性處理設計（圖2.1仍然有許多情況沒有考慮到），稍有不慎，則會導致難以想象的后果，因此，目前金融行業采用整體處理方式來應對這種情形的應用比例還相當低。
所謂手動處理模式，就是由Service Center的服務應用框架代替應用，提供統一的一致性處理服務，用一種標準化的、邏輯極其嚴密的整體處理方式來解決所有自動處理模式無法處理的一致性問題，從而大大降低開發人員的負擔。
作者:? 家住海淀? ?? 時間:? 2012-2-6 10:50
一致性問題只是一個數據完整性問題
還要關注的就是對海量并發處理的響應
作者:? efscao? ?? 時間:? 2012-2-6 10:53
家住海淀 發表于 2012-2-6 10:50?
一致性問題只是一個數據完整性問題
還要關注的就是對海量并發處理的響應
非常正確！
我再抄一些東西大家分享：
Service Center的服務重入機制
? ? ? ? 由于經常需要訪問遠程服務系統（尤其是合作企業的服務系統），許多集成型服務應用完成整個處理過程往往需要較長時間。如果處理線程/進程以堵塞方式——每發出一個服務請求后線程/進程就處于堵塞狀態，直到收到服務應答才繼續執行下一個指令——執行集成服務處理流程的話，將會導致大量服務系統資源（內存和處理線程/進程）的浪費，造成堵塞，數據差錯急劇增多，甚至宕機。
? ? ? ? 以前面提到的代銷基金為例。市場好的時候，基金銷售量會直線上升，基金公司的服務系統可能由于壓力增大而反應緩慢，很快就會導致銀行端代銷基金集成服務處理線程/進程大量堵塞。通常，服務系統常備的處理線程/進程總數都在20到50之間（過多則操作系統調度效率會大大下降），在所有處理線程/進程都處于堵塞狀態時，就會產生大量排隊等候處理的服務請求，服務系統響應能力和可靠性迅速下降，直至宕機。當然，有些服務系統在緊急時刻會創建更多的線程/進程，但與大量排隊等候處理的服務請求比較起來，仍然是杯水車薪。
有些銀行采用部署更多的服務系統節點的方法來應對，這不但要大大增加部署成本，而且還不能根本地解決堵塞問題，只不過是延緩了宕機時刻的到來。
還有一些銀行采用流量控制的方法來應對，即在調用處理時間可能較長的服務前，檢查該服務當前的調用流量，超過一定的閾值則放棄調用，作為“調用流量已滿，暫停該類服務”錯誤來處理。這種方案一定程度上能夠保證服務系統不至于宕機，但顯然會招致柜員和客戶的不滿——為什么系統總是暫停服務？
目前，最根本的解決方法就是徹底改變這類服務應用的編程模型，把一個服務處理過程拆解為多個，無論是為客戶端系統提供服務，還是調用其它服務系統提供的處理時間可能較長的服務，都采用異步工作模式——即服務應用的異步編程模型。
仍以代銷基金為例。在柜員收取客戶現金并通過柜臺系統發出代銷基金服務請求后，服務應用先調用本行帳務系統的服務以登記現金的收取，成功后向基金公司發出購買基金服務請求，請求發出后服務應用休眠——保存當時的重要狀態，釋放處理線程/進程。在稍后一個時刻，銀行收到了基金公司的應答，再喚醒該服務應用——分配處理線程，獲取休眠時的狀態。如果購買基金交易失敗，則啟動自動撤銷處理，生成“交易失敗”服務應答，結束服務處理過程，柜臺系統受到服務應答后，在終端上顯式“交易失敗”，柜員退還現金；如果購買基金交易成功，則生成“交易成功”服務應答，結束服務處理過程，柜臺系統受到應答后，在終端上顯示“交易成功”，柜員收訖現金。
圖2.2按異步編程模型重構的服務應用
服務應用的異步編程模型對開發人員的要求極高。開發人員必須極為小心慎重地針對具體應用制訂相應的服務處理過程分拆方案，分拆后如何保障集成服務的一致性則更是一些令人頭痛的問題，因此，目前金融行業采用異步編程模型來開發的服務應用極為稀少，在國內，基本上僅限于銀聯和各大銀行的交換系統。
Service Center提供了一種被稱為服務重入的機制來解決堵塞問題。這種機制不要求開發人員改變他們習慣的編程模型，仍然只需要用一個流程來描述集成服務的完整處理過程。運行時刻，這個流程在執行到某些耗時較長的處理步驟時，在處理步驟啟動后可以執行Service Center的服務應用框架提供的“休眠”方法，由服務應用框架完成應用休眠工作。在這些處理步驟完成時可以執行服務應用框架提供的“喚醒”方法，由服務應用框架喚醒應用，并讓它從剛才調用“休眠”方法的語句處繼續向下執行，直到完成整個流程。
服務重入機制使得基于Service Center構建的產品服務具有極高的吞吐能力，能夠應對過去難以承受的突發的業務高峰，而這一切的獲得并不需要開發人員做出許多改變和適應。
作者:? 南東北西? ?? 時間:? 2012-2-6 11:25
efscao 發表于 2012-2-6 10:53?
非常正確！
我再抄一些東西大家分享：
歸根結底還是分布式事務處理。
只不過是將分布式事務處理應用到金融業中。
個人的判斷：
1. 如果是實時交易，要保證多系統間的事務處理，而不是傳統的沖正方式，效果未必優于后者。
主要是保證事務處理會影響程序效率，而后者簡單明了，當然沖正給柜員帶來了麻煩，但系統做得好的話，柜員完全可以不必重新輸入數據。
有可能某些特殊業務，實現多系統間的事務處理有必要性和優越性。
2. 如果是批處理，通常是自動化的。
實現多系統間的事務處理當然是必要的。
作者:? 南東北西? ?? 時間:? 2012-2-6 11:26
efscao 發表于 2012-2-6 10:53?
非常正確！
我再抄一些東西大家分享：
歸根結底還是分布式事務處理。
只不過是將分布式事務處理應用到金融業中。
個人的判斷：
1. 如果是實時交易，要保證多系統間的事務處理，而不是傳統的沖正方式，效果未必優于后者。
主要是保證事務處理會影響程序效率，而后者簡單明了，當然沖正給柜員帶來了麻煩，但系統做得好的話，柜員完全可以不必重新輸入數據。
有可能某些特殊業務，實現多系統間的事務處理有必要性和優越性。
2. 如果是批處理，通常是自動化的。
實現多系統間的事務處理當然是必要的。
作者:? taelons? ?? 時間:? 2012-2-6 11:27
姑且不論這個代銷基金的例子并不合適（代銷基金根本不是LZ所說的流程）。
LZ所說的就是分布式事務處理的機制，分布式事務處理并不是“不成功則全部失敗”，完全可以實現掛起、回退或繼續
作者:? 家住海淀? ?? 時間:? 2012-2-6 11:30
taelons 發表于 2012-2-6 11:27?
姑且不論這個代銷基金的例子并不合適（代銷基金根本不是LZ所說的流程）。
LZ所說的就是分布式事務處理的機 ...
全部的撤銷和回退是一種相對理想的情況
對于部分成功和部分失敗的情況，整個響應時間就有問題了，可能已經超過了超時處理的設定閾值
作者:? efscao? ?? 時間:? 2012-2-6 11:43
taelons 發表于 2012-2-6 11:27?
姑且不論這個代銷基金的例子并不合適（代銷基金根本不是LZ所說的流程）。
LZ所說的就是分布式事務處理的機 ...
1、真沒想到分布式事務處理機制還有這么強大的特性，是我孤陋寡聞了？假如在集成服務的處理過程中，你調用的一個WebService修改了一個文件中的數據，而后其他地方發生了問題，那么你認為分布式事務處理機制也能很好地對付這個問題么？
2、說到代銷基金的處理流程，我只能說01年我在X行帶領的項目組做代銷基金時就是這樣的流程，09年我做整個行的架構梳理和管控時，項目組提交上來的設計文檔也是這樣的流程，X行的代銷基金業務量在行業內不是第1也是第2.你也許可以說我以偏概全，但不能武斷地說“根本不是我所說的流程”
作者:? efscao? ?? 時間:? 2012-2-6 11:55
南東北西 發表于 2012-2-6 11:25?
歸根結底還是分布式事務處理。
只不過是將分布式事務處理應用到金融業中。
一個需要在出現一致性問題之后再調用一個一致性處理接口的模型，難道還是（分布式）事務模型？
作者:? efscao? ?? 時間:? 2012-2-6 11:59
如果你調用了合作伙伴的WebService，你能把他們家的數據庫也納入你的分布式事務機制中么？
作者:? 南東北西? ?? 時間:? 2012-2-6 12:44
efscao 發表于 2012-2-6 11:59?
如果你調用了合作伙伴的WebService，你能把他們家的數據庫也納入你的分布式事務機制中么？
雖然不同，核心還是分布式事務處理的理念，只是具體應用的適應性實現罷了。
作者:? taelons? ?? 時間:? 2012-2-6 12:55
efscao 發表于 2012-2-6 11:43?
1、真沒想到分布式事務處理機制還有這么強大的特性，是我孤陋寡聞了？假如在集成服務的處理過程中，你調用 ...
１、建議LZ了解一下分布式事務處理的概念，還有jta、jdo、atomikos、spring之類的規范和開源，商業的更不用說了
２、第一次聽說銀行代銷基金還要調用基金公司的服務并等待應答。基金交易并不是適時的，成功不成功，晚上統一對賬就知道了
作者:? efscao? ?? 時間:? 2012-2-6 13:07
taelons 發表于 2012-2-6 12:55?
１、建議LZ了解一下分布式事務處理的概念，還有jta、jdo、atomikos、spring之類的規范和開源，商業的更不 ...
1、呵呵，我倒是認為分布式事務處理本身和SOA理念就是違背的。未來你訪問你的合作伙伴時，你唯一的手段就是調用它的WebService ，而不是直接操作它的數據庫（現在也不可能），把它家的數據庫納入你的分布式事務處理產品（不管用的是開源的，還是商業的）管控下
2、買基金的應用，你可以做成不實時的，但一些價格實時浮動的投資產品，你還能這么做么？
作者:? efscao? ?? 時間:? 2012-2-6 13:33
如果多家銀行都代銷一家基金，你不調用一下基金公司的接口，怎么知道基金有沒有賣完啊？先查詢一下？不擔心查詢完后余量又變了？你不擔心收了客戶的錢，第2天又告訴他沒買到，客戶有意見？當然了，我們現在很多銀行都是這么對待客戶的，他們不怕客戶有意見
作者:? pacman2000? ?? 時間:? 2012-2-6 13:42
efscao 發表于 2012-2-6 09:08?
當你在一個SOA架構中，要集成多個WebService時，你怎么能夠奢望數據都在一個數據庫中？不在一個數據庫中，你 ...
這是問題的所在，對于銀行這種一致性要求非常高的應用狀況，過多得拆分零碎的小系統，真的適合嗎？如果能把聯機事務處理涉及的數據庫設成同一個，不是更好？
作者:? pacman2000? ?? 時間:? 2012-2-6 13:45
efscao 發表于 2012-2-6 10:13?
我們的模型和事務模型還是有較大不同的。事務模型的目標是確保當某個步驟失敗時，所有變動恢復原樣。我們的 ...
異步的情景，比如集中處理中心，現在已經用工作流的方式弄了。同步的情況，前臺都有超時設置，這時候人工干預，對超時控制影響很大啊。
作者:? efscao? ?? 時間:? 2012-2-6 13:49
pacman2000 發表于 2012-2-6 13:42?
這是問題的所在，對于銀行這種一致性要求非常高的應用狀況，過多得拆分零碎的小系統，真的適合嗎？如果能 ...
如果是工農中建交，這么做是最好的，但是不是所有銀行都能像這幾家銀行依靠自己的開發力量搞定所有應用的，所以...
作者:? efscao? ?? 時間:? 2012-2-6 13:51
再者，即便你能搞定自己的全部應用，你還得和其他企業合作，對接，這類應用數量會越來越多。仍然不可避免的要面對一致性問題
作者:? efscao? ?? 時間:? 2012-2-6 13:54
pacman2000 發表于 2012-2-6 13:45?
異步的情景，比如集中處理中心，現在已經用工作流的方式弄了。同步的情況，前臺都有超時設置，這時候人工 ...
我想，現在還沒有哪家銀行的銀聯卡前置系統（要訪問人行交換系統）是用工作流做的吧
作者:? efscao? ?? 時間:? 2012-2-6 14:04
efscao 發表于 2012-2-6 13:54?
我想，現在還沒有哪家銀行的銀聯卡前置系統（要訪問人行交換系統）是用工作流做的吧
對于集中處理中心這種后臺的、根本不需要講究操作體驗的地方，我覺得連工作流都不需要。只需業務員采集、整理信息，系統批量處理即可
作者:? efscao? ?? 時間:? 2012-2-6 14:05
pacman2000 發表于 2012-2-6 13:45?
異步的情景，比如集中處理中心，現在已經用工作流的方式弄了。同步的情況，前臺都有超時設置，這時候人工 ...
對于集中處理中心這種后臺的、根本不需要講究操作體驗的地方，我覺得連工作流都不需要。只需業務員采集、整理信息，系統批量處理即可
作者:? pacman2000? ?? 時間:? 2012-2-6 14:08
efscao 發表于 2012-2-6 13:54?
我想，現在還沒有哪家銀行的銀聯卡前置系統（要訪問人行交換系統）是用工作流做的吧
銀聯接口的訪問是同步的，也就是一個交易提交以后，要等待返回的。所以你看ATM上都有超時時間顯示的啊。
這時候有人工處理參與，也不知道到底ATM界面超時了沒有，很可能把事情搞得更復雜了。
作者:? pacman2000? ?? 時間:? 2012-2-6 14:10
efscao 發表于 2012-2-6 13:51?
再者，即便你能搞定自己的全部應用，你還得和其他企業合作，對接，這類應用數量會越來越多。仍然不可避免的 ...
是的，對外接口毫無疑問必然是有一致性問題。這時候就要依據資金安全原則理清交易步驟，以及靠事后對賬來處理差錯。所以行內系統能簡單點就簡單點吧。
作者:? taelons? ?? 時間:? 2012-2-6 14:16
１、你對分布式事務的理解仍局限于數據庫事務的范疇。在商業的RAD6能很容易的實現WebServices事務
２、不是“可以”，而是“必須”
作者:? efscao? ?? 時間:? 2012-2-6 14:18
pacman2000 發表于 2012-2-6 14:08?
銀聯接口的訪問是同步的，也就是一個交易提交以后，要等待返回的。所以你看ATM上都有超時時間顯示的啊。
...
1、銀聯給大家的接口并非同步的，前置給ATM的接口才是同步的
2、各家銀行目前的前置都是同步實現的，所以如果我們觀察前置的進程，會發現總是有很多處于等候狀況，如果這些前置是基于CICS等中間件開發的話，那么我們就要擔心應用服務器資源消耗的問題的，我們不得不加上流量限制，駁回很多終端的請求，所以，我們經常會看到系統忙、暫停服務，而異步模型可以讓你不設流量限制
3、異步模型和我們先前說的一致性處理是兩回事，不要糾纏在一起，當然，如果沒有很好的平臺幫你應對，你可能真的就不得不把這些問題糾纏在一起考慮了
4、前端超時自有前端超時的一套處理機制，（一般是查詢先前未知的處理結果，但像ATM這樣的自助終端則基本上用沖正應對），和我們先前所提到的模型最好也不要糾纏在一起
作者:? pacman2000? ?? 時間:? 2012-2-6 14:25
efscao 發表于 2012-2-6 14:18?
1、銀聯給大家的接口并非同步的，前置給ATM的接口才是同步的
2、各家銀行目前的前置都是同步實現的，所以 ...
這樣吧，就拿這個ATM跨行取款交易的例子，來看看你的模型是如何處理的？
作者:? efscao? ?? 時間:? 2012-2-6 14:28
pacman2000 發表于 2012-2-6 14:10?
是的，對外接口毫無疑問必然是有一致性問題。這時候就要依據資金安全原則理清交易步驟，以及靠事后對賬來 ...
行內系統能簡單就簡單，這個說法完全同意，但很多銀行不得不外購應用系統，還真簡單不起來
作者:? efscao? ?? 時間:? 2012-2-6 14:36
taelons 發表于 2012-2-6 14:16?
１、你對分布式事務的理解仍局限于數據庫事務的范疇。在商業的RAD6能很容易的實現WebServices事務
２、不是 ...
1、如果你一定認為基于兩階段提交的（分布式）事務模型確實能普遍應對各種一致性問題，我也沒什么可說的，不過到目前為止，銀行系統似乎還沒有一個運用兩階段提交機制的，我記得2000年我們對幾個商業軟件做過兩階段提交機制的測試，并最終放棄。希望你能多創造一些案例，供我們大家參考
2、如果多家銀行都代銷一家基金，你不調用一下基金公司的接口，怎么知道基金有沒有賣完？先查詢一下？不擔心查詢完后余量又變了？你不擔心收了客戶的錢，第2天又告訴他沒買到，客戶有意見？當然了，我們現在很多銀行都是這么對待客戶的，他們不怕客戶有意見——這是我對買基金應用中“必須”不調用基金公司接口的回答
作者:? efscao? ?? 時間:? 2012-2-6 14:46
pacman2000 發表于 2012-2-6 14:25?
這樣吧，就拿這個ATM跨行取款交易的例子，來看看你的模型是如何處理的？
這就是一個簡單的、典型的異步模式的服務應用：
ATM發出取現請求后，服務應用判斷出為他行卡，則向銀聯發出取現報文，發出后服務應用休眠——保存當時的重要狀態，釋放處理線程/進程。在稍后一個時刻，銀行收到了銀聯的應答，再喚醒該服務應用——分配處理線程，獲取休眠時的狀態。如果銀聯的應答是失敗，則生成“交易失敗”服務應答給ATM；如果銀聯的應答是成功，則調用主機賬務系統取現交易，成功后生成“交易成功”服務應答給ATM。
當然，向銀聯發出取現報文的同時會安裝一個計時器，一旦超過時間，就自動喚醒該服務應用，此時，服務應用將認為銀聯應答不明確，并因此生成“交易失敗”服務應答給ATM，同時啟動自動沖正機制，防止一致性問題。
關鍵不在于寫這樣的異步服務，而是要提供一個平臺，允許大家用同步模型來編寫出可以按異步模式工作的服務應用
作者:? taelons? ?? 時間:? 2012-2-6 14:52
１、那為什么放棄呢？為什么一定要webservices？LZ在回避自己的理解錯誤
２、我做基金這行這么多年，第一次聽說這種基金
作者:? efscao? ?? 時間:? 2012-2-6 14:58
taelons 發表于 2012-2-6 14:52?
１、那為什么放棄呢？為什么一定要webservices？LZ在回避自己的理解錯誤
２、我做基金這行這么多年，第一次 ...
呵呵，也許基金這個名字改成其他投資產品比較合適
作者:? efscao? ?? 時間:? 2012-2-6 14:59
taelons 發表于 2012-2-6 14:52?
１、那為什么放棄呢？為什么一定要webservices？LZ在回避自己的理解錯誤
２、我做基金這行這么多年，第一次 ...
為什么一定要webservices？呵呵，這個也要回答么？
作者:? efscao? ?? 時間:? 2012-2-6 15:09
efscao 發表于 2012-2-6 14:58?
呵呵，也許基金這個名字改成其他投資產品比較合適
剛核實了一下，用基金做例子確實不對啊，向taelons致歉。
記憶有誤，應改成價格實時浮動的投資產品
作者:? pacman2000? ?? 時間:? 2012-2-6 16:01
efscao 發表于 2012-2-6 14:59?
為什么一定要webservices？呵呵，這個也要回答么？
銀行的OLTP本來就不是web，沒必要什么都扯上webservice。而且SOA的S也只是service，可沒說是webservice哦。
作者:? efscao? ?? 時間:? 2012-2-6 16:18
pacman2000 發表于 2012-2-6 16:01?
銀行的OLTP本來就不是web，沒必要什么都扯上webservice。而且SOA的S也只是service，可沒說是webservice哦 ...
這個基本同意。我們的OLTP不一定都非得搞成WebService不可，但我們集成其他應用，以及其他合作伙伴的功能，今后大都會采用webService標準。退后一步，哪怕他們不是提供WebService，至少有一點是肯定的，他們會提供某種形式的service供我們集成，而不是讓我們直接訪問他們的數據庫。這就必然帶來一致性問題。實際上，我們的模型是針對各種服務集成時出現的一致性問題，而不僅僅是webservice
作者:? pacman2000? ?? 時間:? 2012-2-6 17:06
本帖最后由 pacman2000 于 2012-2-6 17:11 編輯?
efscao 發表于 2012-2-6 14:46?
這就是一個簡單的、典型的異步模式的服務應用：
ATM發出取現請求后，服務應用判斷出為他行卡，則向銀聯發 ...
嗯？這里沒看到你說的異常人工處理啊。
同步方式調用異步訪問，這個在現有的綜合前置，ESB等等系統里也有類似實現的。而且對于解決一致性問題來說，這個不是重點，異常處理才是重點。
比如說，銀聯提交成功以后，提交核心交易失敗了。這時候的處理過程怎么樣呢？假如沖正也失敗了又怎么處理？
作者:? efscao? ?? 時間:? 2012-2-6 17:24
pacman2000 發表于 2012-2-6 17:06?
嗯？這里沒看到你說的異常人工處理啊。
同步方式調用異步訪問，這個在現有的綜合前置，ESB等等系統里也 ...
？我記得我們談到ATM是因為我們在討論異步模型用在哪里（集中處理中心->銀聯前置->ATM前置），而不是一致性處理模型用在哪里。
要討論一致性處理模型，還是看這個案例（taelons說的對，原先用基金不合適，我改成價格實時浮動的投資產品了）：
Service Center的一致性保障機制
Service Center為集成型服務應用提供了完備的一致性保障機制，這一重要特征使其非常適合被用作新產品服務和大前置等集成服務類應用系統的應用平臺。Service Center的一致性保障機制分為“自動撤消處理”和“手動繼續嘗試處理或撤消處理”兩種模式（簡稱自動處理模式和手動處理模式）。所謂自動處理模式——也是當前金融行業已經運用的一些集成服務應用平臺和框架所普遍采用的模式——就是在集成型服務應用的處理過程中，如果有一個步驟沒有成功，則向訪問者返回失敗，并由應用框架自動發起先前已經被該應用成功調用的服務的撤消處理。
需要注意的是，自動處理模式難以應對某些一致性問題。設想這樣一個場景：客戶帶著現金來銀行購買某種投資產品，柜臺系統訪問的代銷投資產品集成服務應用一般要先調用本行帳務系統的服務以登記現金的收取，成功后調用發行投資產品的公司的購買產品服務，再成功后向柜臺系統返回“交易成功”，由柜員收訖現金。如果規定時間內沒有收到公司的應答（一個結果不確定的步驟），我們能夠使用自動處理模式解決問題么？如果我們把這種未收到應答的情形當作失敗步驟并啟動自動撤消處理，結果很可能就是客戶既買到了產品，同時柜員又告知客戶交易失敗，向客戶退還了現金！當然，有些銀行采取這樣的做法：即便未收到公司的應答，也當做成功步驟繼續處理。這就可能造成產品沒有買到而客戶現金卻被收取，客戶必然要投訴，而問題解決起來可能相當繁瑣（在試圖解決問題的時候產品價格很可能已經發生變動，或者已經銷售完）。
有些開發人員發現了這種問題，他們一般采用以下兩種方式來處理：
1、? ? ? ? 分解處理方式。在上述情形發生時，向柜臺系統返回“沒有收到...應答”，根據操作說明，柜員需要立即查詢公司的處理結果，如果成功，則收訖現金，如果不成功，則進行一致性處理——撤消本行帳務系統的現金收取登記，或者單獨調用公司的購買產品服務。
2、? ? ? ? 整體處理方式。在上述情形發生時，向柜臺系統返回“沒有收到...公司應答，請選擇繼續嘗試處理或撤消處理”，柜員在終端上只能選擇“繼續”或“撤銷”。一旦選定，柜臺系統會調用一個專門處理這種情形的一致性處理服務。如果柜員選擇了繼續嘗試處理，該服務會先查詢公司的處理結果，成功則返回“交易成功”，柜員收訖現金，失敗則返回“交易失敗”，并啟動自動撤消處理以撤消本行帳務系統的現金收取登記，柜員退還現金；如果柜員選擇了撤消處理，該服務會先查詢公司的處理結果，成功則先調用公司的撤消購買產品服務，然后再調用本行帳務系統的撤消現金收取登記服務，最后返回“交易已經撤消”，柜員退還現金。
圖2.1 用整體處理方式處理一致性問題的服務應用
顯然，從業務角度看整體處理方式要優于分解處理方式——對于柜員而言，操作壓力大大降低，不容易出錯；對于銀行而言，不需要向柜員開放“撤消本行帳務系統的現金收取登記”和“單獨調用公司的購買產品服務”等功能，更好地控制了操作風險。
但是整體處理方式需要開發人員針對具體應用進行極其細致而繁瑣的一致性處理設計（圖2.1仍然有許多情況沒有考慮到），稍有不慎，則會導致難以想象的后果，因此，目前金融行業采用整體處理方式來應對這種情形的應用比例還相當低。
所謂手動處理模式，就是由Service Center的服務應用框架代替應用，提供統一的一致性處理服務，用一種標準化的、邏輯極其嚴密的整體處理方式來解決所有自動處理模式無法處理的一致性問題，從而大大降低開發人員的負擔。
作者:? efscao? ?? 時間:? 2012-2-6 17:38
在ATM、自助終端等自助設備上通常不會應用這個手動處理一致性問題的模型，因為不存在運作這種模型的必需條件：業務人員。所以，我們通常也不會在這些終端上看到類似的代銷投資產品的服務
作者:? efscao? ?? 時間:? 2012-2-6 17:43
說到銀聯卡，其實在柜臺上辦理的他行卡存款到是和我列舉的代銷投資產品非常相似，可以應用這個手動處理一致性的模型
作者:? efscao? ?? 時間:? 2012-2-6 17:57
現在柜面上的他行卡取款則通常都和ATM調用的他行卡取款是一個接口，自然一致性處理機制也一樣，采用的自動撤銷（即沖正）機制，但也可以改成手動的一致性處理機制——如果特別強調客戶的感受的話，不過這樣自然業務操作員的體驗要稍差一點，這就看業務設計部門是怎么權衡的了。以銀聯卡這么簡單的業務而言，似乎倒也沒有改的必要。但如果柜員幫助企業用戶做多個賬戶間的轉賬操作，而這些賬戶可能包含外行的，那么，應用這個手動的一致性處理機制可能就是必要的了
作者:? jenifer23710092? ?? 時間:? 2012-2-24 19:41
efscao 發表于 2012-2-6 17:24?
？我記得我們談到ATM是因為我們在討論異步模型用在哪里（集中處理中心->銀聯前置->ATM前置），而不是一致 ...
是否可以采用消息處理機制？某只交易并行調用若干服務，每個服務都會根據一定的規范返回消息，若該交易，允許不是所有服務都成功，才成功，那么可以根據最后每支服務返回的消息結果，決定全部撤銷還是部分撤銷。
這些不同服務返回的消息通過MQ存儲。
作者:? efsca? ?? 時間:? 2012-2-24 20:50
通常不會有并行調用的，一般集成服務時都是串行地調用后面的服務
你提到的處理模式其實就是現在許多前置和中間業務平臺廣泛采用的自動撤銷處理模式
作者:? CountOnMyself? ?? 時間:? 2012-2-25 14:27
efscao 發表于 2012-2-6 17:24?
？我記得我們談到ATM是因為我們在討論異步模型用在哪里（集中處理中心->銀聯前置->ATM前置），而不是一致 ...
你說的這種模式，本質上就是分布式事務的兩階段提交模式，這種技術２０年前就出現了，在ＴＵＸＥＤＯ、ＣＩＣＳ、ＴＯＮＧＥＡＳＹ等交易中間件上都有很好的支持。
但為什么除了一開始在大行的小分行上有所應用，到后來得改為超時反交易或補交易的處理機制？為什么有簡單可實現的技術不用而要通過開發出多一倍的超時處理交易來完成？ 這說明了這種2PC的模式，在真正大規模并發的關鍵型銀行交易系統中是弊多利少，嚴重時甚至出現死鎖關鍵資源而導致全行無法營業的情況。
不要再閉門造車想當然的研發什么產品了，多經歷一些大型系統的建造，積累更多的經驗再去思考大型銀行系統技術平臺真正的需要吧！
不要再隨便胡吹領先世界５－１０年這樣的瘋言瘋語了，永遠沒人把它當真。
作者:? efsca? ?? 時間:? 2012-2-26 18:50
CountOnMyself 發表于 2012-2-25 14:27?
你說的這種模式，本質上就是分布式事務的兩階段提交模式，這種技術２０年前就出現了，在ＴＵＸＥＤＯ、Ｃ ...
1、你真的仔細看完了我們所提的手動處理模式了么？你真的看懂了么？？
2、要論大型系統的建造，我到真是造過不少，我們建造的前置系統在一家省分行的日均交易量都超千萬，怎么說我們是閉門造車呢？這個模式實際上是在總結我們01年上線的前置系統幾年來運行出現的問題并研究各種解決之后的一些成果。
3、我們可從沒說過領先世界5-10這樣的“瘋言瘋語”，不知你從哪兒看到的啊
作者:? efsca? ?? 時間:? 2012-2-26 18:58
efsca 發表于 2012-2-26 18:50?
1、你真的仔細看完了我們所提的手動處理模式了么？你真的看懂了么？？
2、要論大型系統的建造，我到真是 ...
呵呵，不過我們倒是的確說過我們至少要領先一家國內的“號稱世界領先”的平臺軟件開發商好幾年的話，這個恐怕不足以讓你得出我們領先世界5-10年這樣的推論吧
作者:? efsca? ?? 時間:? 2012-2-26 18:58
CountOnMyself 發表于 2012-2-25 14:27?
你說的這種模式，本質上就是分布式事務的兩階段提交模式，這種技術２０年前就出現了，在ＴＵＸＥＤＯ、Ｃ ...
呵呵，不過我們倒是的確說過我們至少要領先一家國內的“號稱世界領先”的平臺軟件開發商好幾年的話，這個恐怕不足以讓你得出我們領先世界5-10年這樣的推論吧
作者:? efsca? ?? 時間:? 2012-2-26 19:23
還不了解我們的，可以看看的我們產品介紹，歡迎大家交流和拍磚：
http://www.eframesoft.com/infos.php?type=1
http://www.eframesoft.com/infos.php?type=2
http://www.eframesoft.com/infos.php?type=3
作者:? efsca? ?? 時間:? 2012-2-26 19:35
版主，網站是不是出問題了
作者:? jenifer23710092? ?? 時間:? 2012-2-26 20:30
efscao 發表于 2012-2-6 17:24?
？我記得我們談到ATM是因為我們在討論異步模型用在哪里（集中處理中心->銀聯前置->ATM前置），而不是一致 ...
圖2.1 用整體處理方式處理一致性問題的服務應用
顯然，從業務角度看整體處理方式要優于分解處理方式——對于柜員而言，操作壓力大大降低，不容易出錯；對于銀行而言，不需要向柜員開放“撤消本行帳務系統的現金收取登記”和“單獨調用公司的購買產品服務”等功能，更好地控制了操作風險。
但是整體處理方式需要開發人員針對具體應用進行極其細致而繁瑣的一致性處理設計（圖2.1仍然有許多情況沒有考慮到），稍有不慎，則會導致難以想象的后果，因此，目前金融行業采用整體處理方式來應對這種情形的應用比例還相當低。
所謂手動處理模式，就是由Service Center的服務應用框架代替應用，提供統一的一致性處理服務，用一種標準化的、邏輯極其嚴密的整體處理方式來解決所有自動處理模式無法處理的一致性問題，從而大大降低開發人員的負擔。
=================
是否這塊可以用一種可配置的策略代替，比如你提到的流程，先怎么后怎么，增加服務治理、管理平臺，基于策略的方式，某一類服務可以根據某一類的策略 保持一致性。例如，購買他行基金這種服務的撤銷策略是，先查詢是否成功，在進行下一步處理。
作者:? efsca? ?? 時間:? 2012-2-26 20:40
jenifer23710092 發表于 2012-2-26 20:30?
圖2.1 用整體處理方式處理一致性問題的服務應用
顯然，從業務角度看整體處理方式要優于分解處理方式 ...
確實，不同的服務集成時會有不同的策略，這種控制可以采用配置方式。但這并非一種替代關系。多種模式，相當于處理一致性問題多種手段，是必須都擁有的，具體調用時采用哪種手段消除一致性問題，可以考慮以配置的方式進行控制
作者:? CountOnMyself? ?? 時間:? 2012-2-27 11:47
efsca 發表于 2012-2-26 18:50?
1、你真的仔細看完了我們所提的手動處理模式了么？你真的看懂了么？？
2、要論大型系統的建造，我到真是 ...
不是人家看不懂你們，是你們自已沒弄懂罷了。
自動和手動的主要差別在哪里，你自已根本沒搞清楚。
說什么銀聯卡交易可以手動，你弄清楚銀聯通訊協議要求了嗎？時間窗口是協議規定的，不是任何一方可以隨意手動調整的。
所謂整體處理方式，說明白了不外乎兩個方案：一是全局事務（ＸＡ協議），但我前面說過了，這玩意用不成；二是多個自動反交易的流程化，這種方式已是現實模式，很多廠商的前置系統只要有流程引擎，有自動重發器的，都可以輕易實現，但反交易的開發量是一點少不了，沒有你說的那么神秘。
國內廠商前置系統有精深積累的其實不少，你說得領先國內Ｎ年，有了解過國內所有產品了嗎？又看過了多少銀行正在使用的系統呢？
作者:? cavern1026? ?? 時間:? 2012-2-27 13:42
看的比較暈！都是OLTP業務，還要把處理線程休眠，這樣我使簡單問題復雜話了！
會引出其他附帶問題，比如重賬等等！
作者:? efsca? ?? 時間:? 2012-2-27 18:45
CountOnMyself 發表于 2012-2-27 11:47?
不是人家看不懂你們，是你們自已沒弄懂罷了。
自動和手動的主要差別在哪里，你自已根本沒搞清楚。
說什 ...
我看有些人邏輯漏洞確實多，這要是數學專業的，考試恐怕是很難及格的。
我說領先國內某家“號稱世界領先”的開發商N年，就可以推出我的意思是領先國內N年么？？也許不只是數學不行，我看語文也沒過關。
我看，邏輯有這樣漏洞的人，就不必來研究這種一致性問題了
作者:? efsca? ?? 時間:? 2012-2-27 18:53
cavern1026 發表于 2012-2-27 13:42?
看的比較暈！都是OLTP業務，還要把處理線程休眠，這樣我使簡單問題復雜話了！
會引出其他附帶問題，比如重 ...
確實，一般程序員是很難都理解這些模式的，讓他們按照這種模式解決問題，也的確會像你所說那樣，引出許多其他問題。那么我們怎么解決這個矛盾呢？那只能是由一些思維極為嚴謹的開發人員在應用框架中提供一種統一的解決機制，這樣就不需要所有應用開發人員再考慮這個問題了。能夠開發這種應用框架的技術人員在整個銀行IT從業人員中比例恐怕不會超過1/1000。
作者:? efsca? ?? 時間:? 2012-2-27 19:11
CountOnMyself 發表于 2012-2-27 11:47?
不是人家看不懂你們，是你們自已沒弄懂罷了。
自動和手動的主要差別在哪里，你自已根本沒搞清楚。
說什 ...
說什么銀聯卡交易可以手動，你弄清楚銀聯通訊協議要求了嗎？時間窗口是協議規定的，不是任何一方可以隨意手動調整的。
——你說的是超時吧，這和手動處理有什么關系啊。比如說跨行存款超時了，那么按照手動處理模式的設計，我們在柜面上可以選擇“繼續嘗試”，服務系統會有一個新的交易來處理你“繼續嘗試”的請求，它會先查詢先前那筆超時的跨行存款成沒成，成就可沿著跨行存款成功的分支繼續處理下去，不成就再調用一次。先前的超時在這里有什么障礙啊。
你說有自動重發都可以輕易實現——自動重發什么呀？沖正吧。好好想想吧，僅從操作者的界面來看，就是完全不同的，這和我說的手動處理模式能是一回事么
作者:? CountOnMyself? ?? 時間:? 2012-2-28 14:42
efsca 發表于 2012-2-27 19:11?
說什么銀聯卡交易可以手動，你弄清楚銀聯通訊協議要求了嗎？時間窗口是協議規定的，不是任何一方可以隨意 ...
——你說的是超時吧，這和手動處理有什么關系啊。比如說跨行存款超時了，那么按照手動處理模式的設計，我們在柜面上可以選擇“繼續嘗試”，服務系統會有一個新的交易來處理你“繼續嘗試”的請求，它會先查詢先前那筆超時的跨行存款成沒成
請問：銀聯協議有超時結果查詢的報文嗎？ 你真了解了銀聯交易協議嗎？
再問：協議要求是超時就無條件認為失敗，受理方要主動發起沖正以保證交易結果一致性。用你的平臺手動模式，又查不了結果，怎么辦啊？
三問：象這種交易協議與你平臺的手動模式不匹配的情況，要求人家改協議？
作者:? CountOnMyself? ?? 時間:? 2012-2-28 14:49
本帖最后由 CountOnMyself 于 2012-2-28 14:52 編輯?
efsca 發表于 2012-2-27 18:45?
我看有些人邏輯漏洞確實多，這要是數學專業的，考試恐怕是很難及格的。
我說領先國內某家“號稱世界領先 ...
別人邏輯再怎么有問題，至少還知道眾多的交易協議中，超時處理有三種模式：超時沖正（還原）、超時確認（重傳）和超時查詢。而你的邏輯，只知道一種模式，還以為全世界的超時處理模式都可以統一在貴家平臺的“超時查詢”模式的大旗下。問題是，目前行業標準協議中，超時查詢是用得最少的，其它兩種大量存在。按你的邏輯，是不是要讓貴公司先把眾多協議先統一掉，所以大家都不用再研究什么事務一致性，剩下你一個人研究好了？
這種果然是沒有漏洞的邏輯啊，我又見到高人了！
作者:? efsca? ?? 時間:? 2012-2-28 15:18
CountOnMyself 發表于 2012-2-28 14:49?
別人邏輯再怎么有問題，至少還知道眾多的交易協議中，超時處理有三種模式：超時沖正（還原）、超時確認（ ...
這個思維真是太有跳躍性了。
你怎么就斷定我“只知道一種模式”啊？？我們又什么時候說過要“統一在超時查詢模式下”啊？？
你仔細看過我們講的自動模式了么？那個自動模式主要就是依賴超時沖正，這你沒看出來么？！
別急著反擊，先仔細看看別人說了什么，再好好想想自己該怎么發言。
作者:? efsca? ?? 時間:? 2012-2-28 15:33
CountOnMyself 發表于 2012-2-28 14:42?
——你說的是超時吧，這和手動處理有什么關系啊。比如說跨行存款超時了，那么按照手動處理模式的設計，我 ...
1、我們這里需要超時后能夠查詢結果的功能，相應的報文就必須叫“超時結果查詢”么？這是什么邏輯啊。
請你好好看看銀聯的“存款確認”接口，那個接口就是存款交易超時后用于查詢先前存款操作結果的
2、銀聯協議要求“超時就無條件認為失敗”？誰跟你講的啊，取現、消費類交易是這樣，存款類的呢？？
有些人可能做過一些應用，就立即認為自己是這個領域的專家了，這種專家還是少出點為妙！
作者:? CountOnMyself? ?? 時間:? 2012-2-28 15:39
本帖最后由 CountOnMyself 于 2012-2-28 15:43 編輯?
efsca 發表于 2012-2-28 15:18?
這個思維真是太有跳躍性了。
你怎么就斷定我“只知道一種模式”啊？？我們又什么時候說過要“統一在超時 ...
原來你是知道的啊？ 既然知道了，那你還是回答一下，你所提倡的手動模式，如何解決銀聯超時交易的問題吧？?
首先告訴一點你沒弄懂的事實： 銀聯協議是沒有超時結果查詢報文的，你好好考慮如何回答吧。
再告訴你一些你可能仍然沒弄懂的事實： 銀行交易的事務一致性問題，并不是僅僅系統請求端和系統服務端兩方關系，而是涉及受理方機構、發送方機構、交換中心、接收方機構等多方參與者，而每一方都涉及到終端、前置、核心等多套系統。這種交易的一致性，說白了就是N方*N個系統的一致性問題。
真能存在一個平臺或者一個簡單模式就能實現這種復雜場景的多方一致性問題嗎？ 你們真的都認真考慮過了，而且認為有說服力？事實上，交易系統的復雜性和多樣性，絕對超出你們想象范圍之外，沒有任何一個平臺或者一種簡單模式可以輕易解決，是必須集中交易協議設計者、業務模型設計者、系統設計和實施者等多方的智慧才能完善解決的問題！
作者:? CountOnMyself? ?? 時間:? 2012-2-28 15:39
本帖最后由 CountOnMyself 于 2012-2-28 15:43 編輯?
efsca 發表于 2012-2-28 15:18?
這個思維真是太有跳躍性了。
你怎么就斷定我“只知道一種模式”啊？？我們又什么時候說過要“統一在超時 ...
原來你是知道的啊？ 既然知道了，那你還是回答一下，你所提倡的手動模式，如何解決銀聯超時交易的問題吧？?
首先告訴一點你沒弄懂的事實： 銀聯協議是沒有超時結果查詢報文的，你好好考慮如何回答吧。
再告訴你一些你可能仍然沒弄懂的事實： 銀行交易的事務一致性問題，并不是僅僅系統請求端和系統服務端兩方關系，而是涉及受理方機構、發送方機構、交換中心、接收方機構等多方參與者，而每一方都涉及到終端、前置、核心等多套系統。這種交易的一致性，說白了就是N方*N個系統的一致性問題。
真能存在一個平臺或者一個簡單模式就能實現這種復雜場景的多方一致性問題嗎？ 你們真的都認真考慮過了，而且認為有說服力？事實上，交易系統的復雜性和多樣性，絕對超出你們想象范圍之外，沒有任何一個平臺或者一種簡單模式可以輕易解決，是必須集中交易協議設計者、業務模型設計者、系統設計和實施者等多方的智慧才能完善解決的問題！
作者:? efsca? ?? 時間:? 2012-2-28 15:45
CountOnMyself 發表于 2012-2-28 15:39?
原來你是知道的啊？ 既然知道了，那你還是回答一下，你所提倡的手動模式，如何解決銀聯超時交易的問題吧？ ...
“銀行交易的事務一致性問題，并不是僅僅系統請求端和系統服務端兩方關系，而是涉及受理方機構、交換中心、接收方機構等多方參與者，而每一方都涉及到終端、前置、核心等多套系統。這種交易的一致性，說白了就是N方*N個系統的一致性問題。
真能存在一個平臺或者一個簡單模式就能實現這種復雜場景的多方一致性問題嗎？ 你們真的都認真考慮過了，而且認為有說服力？事實上，交易系統的復雜性和多樣性，絕對超出你們想象范圍之外，沒有任何一個平臺或者一種簡單模式可以輕易解決，是必須集中交易協議設計者、業務模型設計者、系統設計和實施者等多方的智慧才能完善解決的問題！”
呵呵，這段話說了一番大道理，這倒是沒有什么大問題，我們也是這么認為的。所以，需要真正的專家仔細地考慮一致性的各種處理機制，并用以改進各個領域的工作，也包括某些制訂標準的組織的工作————這恰恰就是我們的初衷
作者:? CountOnMyself? ?? 時間:? 2012-2-28 15:52
本帖最后由 CountOnMyself 于 2012-2-28 15:54 編輯?
efsca 發表于 2012-2-27 19:11?
說什么銀聯卡交易可以手動，你弄清楚銀聯通訊協議要求了嗎？時間窗口是協議規定的，不是任何一方可以隨意 ...
－－你說有自動重發都可以輕易實現——自動重發什么呀？沖正吧。
再回復你這個問題，重發什么？ 我還真不會告訴你太多，如果你自已真的懂了，你自已看看各種協議中，有哪些報文是可以存儲轉發的，就知道能重發什么了。如果你只知道“沖正”一種，說明你自詡的“有邏輯”就是在閉門造什么的了，別不讓人家說你。
作者:? efsca? ?? 時間:? 2012-2-28 16:01
CountOnMyself 發表于 2012-2-28 15:52?
－－你說有自動重發都可以輕易實現——自動重發什么呀？沖正吧。
再回復你這個問題，重發什么？ 我還真不 ...
通知類報文大多均可存儲重發，當然不只是沖正。不過你這也太能斷章取義了，你得把整條句子翻出來，好好看看我說那句話的目的——是在你無法弄清自動模式和手動處理模式的區別的前提下，舉出沖正為例！
暈
作者:? CountOnMyself? ?? 時間:? 2012-2-28 16:04
efsca 發表于 2012-2-28 16:01?
通知類報文大多均可存儲重發，當然不只是沖正。不過你這也太能斷章取義了，你得把整條句子翻出來，好好看 ...
通知類報文大多均可存儲重發???
算了，不說你了，你繼續造你的大好平臺吧
作者:? efsca? ?? 時間:? 2012-2-28 16:10
CountOnMyself 發表于 2012-2-28 16:04?
通知類報文大多均可存儲重發???
算了，不說你了，你繼續造你的大好平臺吧
我不知道你對通知類報文是怎么理解的。不過我這里提到的“通知類報文”可決不是什么 某個參與方發個文本通知之類的，而是包括：沖正、存款確認等報文
作者:? efsca? ?? 時間:? 2012-2-28 16:11
CountOnMyself 發表于 2012-2-28 16:04?
通知類報文大多均可存儲重發???
算了，不說你了，你繼續造你的大好平臺吧
這是我們在2000年設計行內交換系統時采用的術語，就不知道你聽過沒有了
作者:? CountOnMyself? ?? 時間:? 2012-2-28 16:17
本帖最后由 CountOnMyself 于 2012-2-28 16:18 編輯?
efsca 發表于 2012-2-28 16:10?
我不知道你對通知類報文是怎么理解的。不過我這里提到的“通知類報文”可決不是什么 某個參與方發個文本通 ...
結算通知算嗎？
清算通知算嗎？
退貨通知算嗎？
授權完成通知算嗎？
日切通知算嗎？
雙轉單交易通知算嗎？
訂購類交易通知算嗎？
匯款通知算嗎？
重發試試看！
作者:? efsca? ?? 時間:? 2012-2-28 16:22
CountOnMyself 發表于 2012-2-28 16:17?
結算通知算嗎？
清算通知算嗎？
退貨通知算嗎？
呵呵，說句實話，有些我還真是不知。05年后我再也未編寫過這類程序。
但當年提出一個“通知類”的概念，不一定就是你現在想象中的通知報文，而是依據交易處理模式來劃分的，請求/響應類的處理模式是整個處理過程完成后才返回應答；通知類報文則是收到后立即返回應答，而后才開始處理。
一個名詞，各有各的理解，正常，而且，我的理解更可能是過時的，但我想我們也不至于糾結在這個分類名詞上吧，有很多前面提到的具體問題，我想你還沒有好好應答吧
作者:? efsca? ?? 時間:? 2012-2-28 16:25
“請求/響應類的處理模式是整個處理過程完成后才返回應答；通知類報文”，再補充一句啊，這是當年的概念，不要再斷章取義了
作者:? CountOnMyself? ?? 時間:? 2012-2-28 16:28
efsca 發表于 2012-2-28 16:22?
呵呵，說句實話，有些我還真是不知。05年后我再也未編寫過這類程序。
但當年提出一個“通知類”的概念， ...
不是我沒應答吧，是你沒聽明白罷了。
倒是你還一直在逃避， 你的手動模式可以解決銀聯超時交易的辦法，在哪呢？
作者:? efsca? ?? 時間:? 2012-2-28 16:29
CountOnMyself 發表于 2012-2-28 16:28?
不是我沒應答吧，是你沒聽明白罷了。
倒是你還一直在逃避， 你的手動模式可以解決銀聯超時交易的辦法，在 ...
好，那就再發一遍：
發表于 2012-2-28 15:33:16 |只看該作者 CountOnMyself 發表于 2012-2-28 14:42?
——你說的是超時吧，這和手動處理有什么關系啊。比如說跨行存款超時了，那么按照手動處理模式的設計，我 ...
1、我們這里需要超時后能夠查詢結果的功能，相應的報文就必須叫“超時結果查詢”么？這是什么邏輯啊。
請你好好看看銀聯的“存款確認”接口，那個接口就是存款交易超時后用于查詢先前存款操作結果的
2、銀聯協議要求“超時就無條件認為失敗”？誰跟你講的啊，取現、消費類交易是這樣，存款類的呢？？
有些人可能做過一些應用，就立即認為自己是這個領域的專家了，這種專家還是少出點為妙！?
作者:? CountOnMyself? ?? 時間:? 2012-2-28 16:31
efsca 發表于 2012-2-28 15:33?
1、我們這里需要超時后能夠查詢結果的功能，相應的報文就必須叫“超時結果查詢”么？這是什么邏輯啊。
請 ...
存款確認是查詢結果的報文？
哈哈！！！?
我服你了！！！
和你討論這么久，才知道我在和一個什么人在討論！
浪費時間了，你繼續吧！
作者:? CountOnMyself? ?? 時間:? 2012-2-28 16:34
本帖最后由 CountOnMyself 于 2012-2-28 16:51 編輯?
efsca 發表于 2012-2-28 15:33?
1、我們這里需要超時后能夠查詢結果的功能，相應的報文就必須叫“超時結果查詢”么？這是什么邏輯啊。
請 ...
“再問：協議要求是超時就無條件認為失敗，受理方要主動發起沖正以保證交易結果一致性。用你的平臺手動模式，又查不了結果，怎么辦啊？”
這才是我的原話，是你說的意思嗎？
我的問題是，協議要求你這樣，你的手動模式如何支持？ 還是讓你回答你的解決辦法，別扯其它。
作者:? CountOnMyself? ?? 時間:? 2012-2-28 16:38
efsca 發表于 2012-2-28 16:29?
好，那就再發一遍：
發表于 2012-2-28 15:33:16 |只看該作者 CountOnMyself 發表于 2012-2-28 14:42??...
你再發100次都沒用。存款確認報文，可不是5年前才出來的報文，象你說的2000年已經開始做，做了5年還沒搞明白這個報文是干什么用的？
如果按你這位“磚家”的邏輯， 是不是還要弄出“取款確認”、“消費確認”、“授權確認”等查詢類報文才能滿足你的超時查詢結果要求嘛？
我還真從來沒把自已當過什么“磚家”， 沒想到這次真真實實找到真正的”磚家“了！
作者:? CountOnMyself? ?? 時間:? 2012-2-28 16:48
本帖最后由 CountOnMyself 于 2012-2-28 16:52 編輯?
efsca 發表于 2012-2-28 16:29?
好，那就再發一遍：
發表于 2012-2-28 15:33:16 |只看該作者 CountOnMyself 發表于 2012-2-28 14:42??...
兄弟，不好意思這次讓你丟人丟大了。
一直都領會不了你的所謂“嚴密邏輯”， 這會才發現原來你們對協議理解的邏輯居然與全世界人是不一樣的。
這里的都是行家，想信沒人不知道存款確認＝存款重發，不過這與你的邏輯可能是格格不入的，你可能永遠也接受不了這種“尊守交易協議”的邏輯。
所以只能說，兄弟，你的邏輯嚴密性，無敵了！
面對你這位“磚家”高人, 我還是退避了吧.
作者:? efsca? ?? 時間:? 2012-2-28 16:57
CountOnMyself 發表于 2012-2-28 16:31?
存款確認是查詢結果的報文？
哈哈！！！?
我服你了！！！
思維慣性真的太蒙蔽人的眼睛了。到底是怎么回事，歡迎每個人都去了解一下跨行存款超時的工作機制：
http://www.docin.com/p-50681555.html
盡管這個跨行存款在業內未能大規模推開，但文檔還是講的很清楚的
作者:? efsca? ?? 時間:? 2012-2-28 16:58
CountOnMyself 發表于 2012-2-28 16:31?
存款確認是查詢結果的報文？
哈哈！！！?
我服你了！！！
請直接翻到101頁
作者:? efsca? ?? 時間:? 2012-2-28 17:01
CountOnMyself 發表于 2012-2-28 16:34?
“再問：協議要求是超時就無條件認為失敗，受理方要主動發起沖正以保證交易結果一致性。用你的平臺手動模 ...
我何時講過手動模式適合處理所有一致性問題？？
作者:? efsca? ?? 時間:? 2012-2-28 17:02
CountOnMyself 發表于 2012-2-28 16:48?
兄弟，不好意思這次讓你丟人丟大了。
一直都領會不了你的所謂“嚴密邏輯”， 這會才發現原來你們對協議理 ...
老弟，我給你再加一個等號：
存款確認＝存款重發=存款查證
以破除你的思維定式
作者:? efsca? ?? 時間:? 2012-2-28 17:05
efsca 發表于 2012-2-28 17:02?
老弟，我給你再加一個等號：
存款確認＝存款重發=存款查證
以破除你的思維定式
這個等式你那一部分還不一定成立呢
存款確認=存款查證！=存款重發
作者:? CountOnMyself? ?? 時間:? 2012-2-28 17:08
本帖最后由 CountOnMyself 于 2012-2-28 17:09 編輯?
efsca 發表于 2012-2-28 16:58?
請直接翻到101頁
101頁只告訴你存款超時要發“存款確認”，沒告訴你這是個查詢報文！文檔不夠使了，不知道該看哪份文檔？
初學者是吧？ 那就虛心點， 我可以告訴你一些信息，你不是很能google嗎？你就好好去搜索一下吧, 我貼點信息給你看看權當掃盲：
《中國銀聯銀行卡聯網聯合技術規范V2.1 第1部分 交易處理說明.pdf》 P13：
--當終端在限定時間內接收不到存款交易請求的應答或檢測到應答報文MAC錯時，必須產生存款確認交易。
--當CUPS未收到發卡方對存款請求的應答時，CUPS向發卡方轉發受理方發來的存款確認通知， 發卡方以存款確認通知做確認記賬處理 。
--當CUPS收到發卡方對存款請求的應答，而受理方未收到CUPS的應答時，受理方轉發終端發來的存款確認通知，CUPS直接給受理方應答，不需要往發卡方轉發。
--當存款確認的發送方收不到應答時，則將存款確認通知存放在存儲轉發隊列中進行存儲轉發。
-- 發卡方一旦成功接收到存款確認通知，應無條件予以承兌。
--存款確認不允許跨越清算日。若受理方不能在CUPS日切前成功處理完存款確認交易，則應在事后進行差錯處理。
--受理方完成存款確認交易后不能進行存款撤銷，對賬不平時通過差錯處理解決。
作者:? CountOnMyself? ?? 時間:? 2012-2-28 17:12
efsca 發表于 2012-2-28 17:05?
這個等式你那一部分還不一定成立呢
存款確認=存款查證！=存款重發
別死撐了，技術人員的絕癥，死不認錯！你愿意繼續丟人，繼續鬧笑話就繼續。
作者:? CountOnMyself? ?? 時間:? 2012-2-28 17:16
本帖最后由 CountOnMyself 于 2012-2-28 17:20 編輯?
efsca 發表于 2012-2-28 17:01?
我何時講過手動模式適合處理所有一致性問題？？
沒人要你解決所有， 是你說的適用于銀聯交易， 所以只要求你用此模式解決銀聯交易！
作者:? efsca? ?? 時間:? 2012-2-28 17:19
CountOnMyself 發表于 2012-2-28 17:08?
101頁只告訴你存款超時要發“存款確認”，沒告訴你這是個查詢報文！文檔不夠使了，不知道該看哪份文檔？
...
存款確認——本質上就是一個重復+查證的交易
即，如果先前沒發生，那么記賬返回結果，但是注意，帳不一定能記成！發卡方有可能帳戶無效
如果先前有發生，則把先前的結果返回
在手動模式中應用這個接口是非常合理的，因為單純的查證接口（如果存在的話）調用后，原交易失敗的話，還要繼續再調用一次存款交易，而這個存款確認接口可以一次性完成，可以說是手動處理模式所需的一個最理想的接口。
作者:? CountOnMyself? ?? 時間:? 2012-2-28 17:19
efsca 發表于 2012-2-28 17:02?
老弟，我給你再加一個等號：
存款確認＝存款重發=存款查證
以破除你的思維定式
是別人的定式，還是你自已的定式？
這個交易與查證有哪怕半毛錢的關系？
有無條件承兌的查詢交易嗎？?
無條件承兌＝查詢？？？
也許你堅持你的邏輯永遠正確，堅持將這種邏輯實現在你的領先XX N 年的平臺上。
不過， 不問市場， 先問問這個壇子里的路人， 敢用嗎？?
總結
以上是生活随笔為你收集整理的如果大家关注SOA的事务一致性的处理，那么不妨看看我们是怎么解决的的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： P1719 最大加权矩形【前缀和】
- 下一篇： 贷款业务内容整理