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