原帖內容進行了整理,請訪問:http://blog.csdn.net/dragonimp/article/details/7184319
以下內容為原貼本來的內容,僅留存,不開評論。要評論請閱讀原帖整理的內容後再發表看法。
原文標題:鐵道部網路購票網站存在的一個大問題----一個大大的事務!!!
說網站的問題,老早就想說了,元旦前第一次網購買票的時候就想說了,今天上csdn來就寫出來分享一下,不過沒準已有人發表了。當時看到鎖定30分鐘提示的時候,彷彿就看到一個讓我覺得可以讓系統必定垮掉的問題----一個業務層級的超級長的事務!!當時看到網站的做法是下訂單就把票先鎖定,然後再付款,超過30分鐘不付款再把座位返回,愚蠢的是,為了減少購票不成功導致退票的問題,鐵道部把解鎖時間由原來的30分鐘改為45分鐘,目前很多人是第一次網購,對網銀支付還不熟悉的情況下,這就導致更多的人更長地處於等待狀態,不斷重新整理,需要更多的系統處理。還造成另一個跟嚴重的問題,就是有大量的票被網站鎖定,火車站都買不了,我的這第一次也是目前唯一的一次網購經曆就是去售票點買不了,去火車站買,被告知票都被網路鎖定了,只能去網站買,於是立刻用手機當網路馬上撥號,花了半小時才買到。但是,這鎖定的做法對去火車站的極為不公平!電腦可以重新重新整理,火車站可不能讓你一直佔用隊列重複重新整理啊,就算你願意重新來,那也得回到隊尾重新排啊!
建議去掉鎖定機制,改為付款成功才出售座位,與售票點同樣的地位就可以了。想到的一種簡單方法就是可以讓大家先沖值到網站,如果沖完發現沒票,則允許轉出,如有票,則直接用網站餘額購票,就不需要先鎖定操作,由於少了鎖定時間,很明確當時是否有票,不會存在一會票被鎖定,等待逾時再放票出來這樣重複的事情。這樣的話,自然就減少大量pv,而且客戶體驗會好不知道多少倍。
現在的問題是,好像沒看到過銀行提供聯機轉回的功能,轉回去都是批量的,但如果用批量的,必然造成普通百姓不理解,但我想這還是值得,以鐵道部的風格,不需要大家的理解,也不需要解釋,說15天退就是15天,更何況如果批量,可能也就一兩天就退回了。所以以更多的退款換來更好的客戶體驗和更小的系統壓力完全值得!而如果不廢除這種機制,再加硬體,再並發,演算法再最佳化也是白費勁。
----------------------------------------------------------------------------
2012.1.8 補充總結一下,具體就是把訂單鎖定機製取消,流程就是:
1、下單選車次,給出需要交費的金額,轉入繳費介面進行沖值,但此時不鎖定任何座位。2、使用者繳費完成,再去確認訂單,扣沖值的錢同時把座位分配給他。(量大的話可以批量,按繳費時間先後看看都有哪些客戶成交)3、對於繳費完,但由於時間比較晚的,買不到票的情況,允許他把沖值的錢做轉出請求。(你們可以晚上批量轉出給銀行,第二天就能回到客戶銀行卡上了) 這樣好處很明顯,不再需要鎖定,付款和退款是一個模組,而且可以提前完成,壓力就分散掉了。而分配座位是一個模組,可以短時間而且可以批量完成。流程清晰,系統壓力小,客戶體驗好。
這麼簡單的商務程序不最佳化,搞什麼海量啊分布式啊,什麼高並發,什麼資料庫啊軟體啊,都是浮雲。別被這些自己都沒買過票的,慣性思維的所謂技術大牛們給騙了。
-----------------------------------------------------------------------------
2012.1.8 晚 ,再給大家補充兩種圖吧,形象一點,不過我不是鐵道部的,所以圖只用於表示我的意思,不一定完全準確。從圖上也可以看到其實修改的東西不多,改的很容易但我想效果是看得見的。
現有購票流程圖:因為先鎖定,所以大家都要等著是否還有沒支付成功的退回來的,剩下一點點就跟秒殺似的,搞死你系統。而且一旦鎖定,連火車站都沒得買了,因為售票視窗可不能一直重新整理,他必須處理其他人的買票要求,這就導致在票沒有完全賣完的情況下,可是在火車站就是買不到票了。
我建議的流程圖,可以看到去掉了現有流程中的鎖定操作,就不會出現票被網上鎖定(實際又沒賣出去)。買的時候有就有,沒有就沒有,大家就不會狂刷網站。支付的時候還可以慢慢來,一點都不急,這樣你就可以選擇任何空閑時間段來先進行下單支付(當然要提前幾日的,不然票沒有了就沒了)。而且在出票階段,可以用批量,還可以選擇各種優先策略,比如車站優先多少,之類的,以起到公平的作用,因為這個時候就是純出票,處理邏輯很簡單,業務就可以更靈活,效能就可以更好。
---------------------
一些問題的解釋:
1、關於事務/鎖。我承認這個標題那是標題黨的做風,但意思只是業務級的"事務"。但從來沒有說他們實現用真的資料庫事務或鎖去鎖這個,我想天下沒有一個SB會這樣做。俺也是寫程式的,不會SB到認為鐵道部用資料庫鎖去鎖定這條記錄或者整個過程是一個資料庫事務,就是想要做成資料庫的事務,還真不知道這麼多頁面跨下來怎麼實現呢,你們誰見過或實現過?
2、儲值的問題。這隻是一個概念思路。你可以說是對這個訂單進行支付,而不是提前儲值。只是在流程上換個位置而已。原來是"出票-支付-不成功退票",現在是"支付-出票-不成功退錢"。注意,現在的鎖定你可以看成是出票,因為佔據了額度了,效果一樣,只不過等會可以退票。
3、這樣做法是不得已,避免不必要的壓力。因為如果每人只來一次的話,就沒有必要在這邊刷,系統壓力小。現有做法肯定是“以客戶為中心”來設計的,但導致了其他的邏輯問題和不必要的並發需求。有的人說如果有多少選擇,會付了很多錢也買不到票,這個問題提得好啊。但你系統可以把這個單據標誌為退款,同時這個錢退到網站“賬戶”,還可以直接用來定其他的單子,不需要再次支付啊,當然如果定上,這個錢就不用退了。辦法總是有的,不要急於否定。
4、總的思想就是把不必要的訪問都減少到最低,分散系統壓力。昨天還沒人關注,今天至少有人關注了,但不管是贊同還是批評,希望i大家都認真看好內容和我要表達的意思,然後再做評論。