[環境]
有多臺高性能數據庫服務器組成一箇中央服務器集羣,提供核心共享數據庫,可以認爲中央服務器是絕對安全的.另外有若干臺數據庫服務器供業務訪問.
[業務流程介紹]
辦理某業務時需要對信用額度進行檢測和操作.各種業務對額度的訪問頻繁.大致流程如下:
業務服務器:提交單據時,判斷信用額度減凍結額度是否大於0,大於0則增加凍結額度,信用額度餘額不變,業務繼續.小於0則禁止提交,中止操作.
中央服務器:單據確認成功時,判斷信用額度餘額是否足夠,足夠則取消提交時的額度凍結,即凍結額度減少,同時也扣除信用額度.額度不足則禁止確認,中止操作.
[目的]
現在做一個設計,保證對這些額度數據的高可用性和高性能訪問,當然也要保證數據的準確性.
方案A:
設計一個表,存在於中央服務器,有凍結額度和信用額度餘額字段(當然還有其他基本信息).業務服務器對額度的操作都在這個集羣上完成.數據流程同上文中介紹.
當一臺業務服務器掛掉時,立刻切換到其他業務服務器操作.依然保持對額度信息的訪問.
方案B:
分別設計一張信用額度表和一張凍結額度表.
信用額度餘額表存在於中央服務器.凍結額度表存在於業務服務器.
爲防止業務服務器掛掉而無法訪問凍結額度.再增加一組業務服務器的備份服務器,用事務同步將所有業務服務器中的凍結額度實時備份至備份服務器.當業務服務器掛掉時,立即切換至其他業務服務器,並訪問備用服務器的凍結額度信息.
關於備用服務器的另一個變招是,將所有業務服務器的凍結額度數據與備用服務器做合併同步,這樣能減少問題的複雜度,但可能造成數據的延遲.
數據流程:
發生業務提交單據時,分別讀取業務服務器上凍結額度與中央服務器信用額度,判斷可用餘額是否足夠,若餘額足夠,則增加業務服務器上的凍結額度,若不夠,則禁止操作.
當確認單據時,讀取中央服務器的信用額度,若足夠,則扣除額度,並且訪問業務服務器,取消單據的凍結額度.若額度不足,則禁止操作.
文字比較多,簡潔表達一下就是,方案A將凍結額度和信用額度存儲在中央服務器,對凍結額度的更改和對信用額度的更改都在中央服務器上進行,實現簡單,缺點是對凍結額度和信用額度的更改都在中央服務器,增加中央服務器壓力.
而方案B是將凍結額度與信用額度分開存儲.對凍結額度的更改只在業務服務器上進行,保證了凍結額度的高效訪問,分解了了對額度的訪問,也一定程度減少中央服務器壓力.缺點是實現複雜,可能會有延遲和不可靠性,跨服務器操作有損性能.而且需要增加另一個備用服務器作實時同步.
提問:
1:到底哪種方案更合理呢?
2:是否有更優方案?
3:猜猜哪種方案是我的,哪種方案是領導的?
補充一些數據:
目前這個額度的數據大約有2000行.每個店一行記錄.但是隨着業務擴展會有所增長,若干年後算1萬吧.
現在的業務規模是算平均每天每店一單(不要笑,事實上還沒有),隨着業務發展,若干年後平均每天每店算10單吧.
不同方案讀寫數據庫次數分析:
方案A:
1.提交時,業務服務器跨服務器讀取1次中央服務器,取得凍結額度和信用額度,判斷額度是否足夠.
2.提交時,業務服務器向中央服務器跨服務器寫入凍結額度1次.
3.確認時,中央服務器本地讀取信用額度1次判斷
4.再跨服務器寫入凍結額度1次,和更新本地信用額度1次.
總計跨服務器寫入2次,跨服務器讀取1次,本地寫入1次.本地讀取1次,一共5次.
業務服務器發生故障時,中央服務器無需任何改動.業務服務器只需切換服務器即可.
方案B:
當凍結額度存儲在業務服務器上,而信用額度存儲在業務服務器上時,業務流程如下:
1.提交時,業務服務器本地讀取凍結額度1次,跨服務器讀取信用額度1次.以判斷額度.
2.提交時,業務服務器本地寫入凍結額度1次.以更新額度.
3.確認時,中央服務器本地讀取信用額度1次,跨服務器讀取凍結額度1次.
4.確認時,中央服務器本地寫入信用額度1次,跨服務器寫入凍結額度1次.
這裏總計跨服務器寫入1次,本地寫入2次,跨服務器讀取2次,本地讀取2次,共計7次.
業務服務器發生故障時,業務立刻切換到其他服務器,同時從備用服務器取回數據,修改主服務器回寫數據的接口,不再寫回故障機器,轉至新機器.
-------------------------------------------------------------------------------------------------------------------------------------------
補我發給領導的郵件:
X總:
我認爲凍結額度還是應該放在中央服務器.原因如下:
對信用額度模塊的設計目的是保證信用額度數據的高可用性(即數據的持續訪問,不因任何一個節點故障而導致無法訪問),高性能訪問以及準確性.
一:高可用性:
在我們的系統環境中,首先應當認爲中央服務器(組)是可用性最高的,必須保證在任何情況下中央服務器(組)是正常可用的,一旦出現故障,不僅是信用額度模塊,所有業務都將不能辦理.
中央服務器組絕對的高可用性是信用額度信息必須放在中央服務器的第一個原因,這樣才能保證額度信息的高可用性.
所以不需要假設中央服務器當機的情況.不存在,也絕不容許存在.即便存在,那信用額度數據無法訪問,整個信用額度模塊照樣無法運行.
若凍結額度存儲在業務服務器,則無法保證業務服務器的可用性,當業務服務器故障時可能造成凍結額度的丟失.當然,可以增加備用服務器,實時備份所有業務服務器上的凍結額度.
但是,當業務服務器故障時,業務切換到其他業務服務器,此時業務服務器需訪問備份服務器取得額度數據,這就帶來了6個問題:
1.各業務服務器如何向備用服務器實時合併同步凍結額度?
2.中央服務器向業務服務器回寫凍結額度數據如何現實?
3.若因爲業務服務器故障而造成備用服務器數據同步不完全怎麼辦?
4.當業務服務器發生故障,中央服務器因爲無法將凍結額度回寫業務服務器,造成中央服務器事務鎖定,甚至造成中央服務器整個過程無法執行怎麼辦?(當存儲過程中一個鏈接服務器失效時,整個存儲過程將無法編譯和執行)
5.業務服務器怎樣快速轉向備用服務器讀取數據?
6.假設解決了第2點的問題,當業務服務器故障時,中央服務器確認單據時如何回寫凍結額度數據?一部分向業務服務器寫,一部分向備用服務器寫?
此時因爲業務服務器故障,業務切換,多個區域會共用一臺業務服務器,該業務服務器原來只訪問自己的凍結額度,中央服務器也只能寫回該區域的凍結額度數據,現在如何保證多個區域在同一臺業務服務器上操作,而凍結額度一臺在業務服務器,一臺在備用服務器時,凍結額度的回寫和訪問?
二:高性能:
當額度數據存儲在中央服務器時,業務流程如下:
1.提交時,業務服務器跨服務器讀取1次中央服務器,取得凍結額度和信用額度,判斷額度是否足夠.
2.提交時,業務服務器向中央服務器跨服務器寫入凍結額度1次.
3.確認時,中央服務器本地讀取信用額度1次判斷
4.再跨服務器寫入凍結額度1次,和更新本地信用額度1次.
總計跨服務器寫入2次,跨服務器讀取1次,本地寫入1次.本地讀取1次,一共5次 業務服務器發生故障時,中央服務器無需任何改動.業務服務器只需切換服務器即可.
當凍結額度存儲在業務服務器上,而信用額度存儲在業務服務器上時,業務流程如下:
1.提交時,本地讀取凍結額度1次,跨服務器讀取信用額度1次.以判斷額度.
2.提交時,本地寫入凍結額度1次.以更新額度.
3.確認時,本地讀取信用額度1次,跨服務器讀取凍結額度1次.
4.確認時,本地寫入信用額度1次,跨服務器寫入凍結額度1次.
這裏總計跨服務器寫入1次,本地寫入2次,跨服務器讀取2次,本地讀取2次,共計7次.
不難算出凍結額度放在業務服務器時,對中央服務器的操作不但沒有減少,反而增加,而且也增加了本地操作.
不僅如此,還增加了跨服務器的操作.跨服務器分佈式事務所造成的性能損失更多.
三:準確性:
信用額度存儲在中央服務器,對信用額度的操作都在同一臺服務器上進行,本地事務可靠性高.可以更好地保證在沒有程序漏洞的情況下數據的完整性,一致性和持久性.
當信用額度保存在中央服務器而凍結額度保存在業務服務器時,若業務服務器發生故障,需要轉向備用服務器訪問,如第一段時所述,該如何對業務服務器凍結額度進行操作?操作的不可預見性和複雜性及易造成數據的錯誤.
尤其如和一段中所述,大大增加了實現的複雜度和不穩定性,對凍結額度的存儲將很不可靠,而且很可能因爲中央服務器依賴業務服務器凍結額度,當業務服務器故障時(可能可以在短時間內轉移)牽連中央服務器運行.
綜上所述,我認爲應該將信用額度存儲在中央服務器.
而且同上所述,對號碼所處理同樣有這些問題,號碼也不應存儲在業務服務器.
改善方案:
既然可備用服務器來備份號碼和信用額度,既然要減少對中央服務器的壓力,爲何不直接將信用額度和號碼存儲在專用的服務器(組),這樣垂直地分割數據既減少了中央服務器的壓力,也保證了號碼和信用額度的安全,這比存儲在業務服務器好得多.
------------------------------------------------------------------------------------------------------------------------------------
最終結果:領導選擇自己的方案,B方案.