試想一下,乙個巨大的訂單量給你。要從中獲取到某個訂單,要如何操作呢?
首先便是分庫分表,我們可以把乙個大的資料集劃分為小的資料集,這樣根據不同訂單的資訊,可以從不同資料庫不同表中獲取。避免向單個資料庫或單張表的請求量過大,容易崩潰。
那麼分庫分表的依據是什麼呢?
首先容易想到的就是從時間上來分。我們可以按照年月來分。比如說按年分庫,按月分表。由於訂單會帶有時間資訊,這樣我們根據時間資訊,就可以馬上知道這個訂單在哪個庫和哪張表了。
但是想想這樣有什麼不好的呢?
首先就是效能上。容易想到,乙個系統關於訂單的操作肯定是時間越新的需求性越高,而且增長的訂單一般都是加入到確定的一張表上。這樣很容易帶來效能問題,可想而之,第乙個月的第一天和最後一天的查詢效能必然差異巨大(在訂單量多的情況下)。
第二個就是擴充套件性的問題。由於按照年月固定的分庫分表的方式,導致其無法平行擴容。資料沒有做到冷熱分離,系統對熱資料的需求相對集中,而這部分資料庫的壓力較大,剩下部分的資料庫壓力較小。
所以按照年月分表的方式,對於需求量大的資料儲存來說不太合適。
針對以上問題,我們容易想到我們需要一種方式負載均衡,它需要對所有的資料庫的需求從理論上來說應該是相同的。
我們可以按照什麼來分表呢?
首先可以按照天來分表,相比於年月,以天來分顯然更方便。一般來說,30天前的資料訪問量會很小,而且一般訂單的狀態不會做修改。我們可以使用主從同步,熱資料在主資料庫,冷資料在從資料庫(主要提供查詢)。另外我們也需要選取訂單號的某些固定部分來作為分庫分表的依據。
另外,擴容問題。
想想我們對乙個訂單操作的時候,首先需要判斷它屬於哪張表的。這一部分的邏輯一般寫在邏輯層,那麼在它擴容的時候需要改變邏輯層的**,一般也需要做資料的遷移。
那有沒有辦法不做資料遷移呢?
我們可以在訂單那邊加乙個分組標識,將某個訂單固定對映到某個分組上。分組就是某資料庫集群,這樣我們新增儲存時,只需要對新的訂單做操作就可以了,將新的訂單增加到對映到新儲存的方式。
這樣就不用做資料遷移了。
另外考慮,如果某組資料集合出現故障了怎麼處理?
資料庫出了故障,新的訂單無法儲存。它就需要返回向邏輯層返回乙個錯誤,並告訴它需要儲存到其他資料庫,接下來新的業務請求就不使用那組db了,訂單號是邏輯層生成的,此時它就生成另一組可以儲存db的訂單。此時,需要注意dao訪問db的超時需要小於前端服務掉dao的超時,可以降低訂單號生成的成本,比如說直接快取一部分訂單號。
另外還有主備切換的問題。。。
C 三層ATM 9 轉賬功能設計
轉賬功能 1.dal cardinfo增加exists方法 查詢某個卡號是否存在 是否存在該記錄 public bool exists string cardid stringbuilder strsql new stringbuilder return dbhelpersql.exists str...
資料訪問層的設計(一) 功能與介面定義
資料訪問層的設計我研究了很長時間,關於介面的定義,好幾次都推翻重來。園子看到過很多easyui mvc ef的文章,在早期,我的設計也類似。但是後來為了增強它,想加點功能通用的功能進去,就耗費了非常多的時間。這是乙個怎麼樣的dal?也許你已經見過許多實用ef的架構了,它是一套基於領域模型架構中的da...
資料訪問層的設計(一) 功能與介面定義
資料訪問層的設計我研究了很長時間,關於介面的定義,好幾次都推翻重來。園子看到過很多easyui mvc ef的文章,在早期,我的設計也類似。但是後來為了增強它,想加點功能通用的功能進去,就耗費了非常多的時間。這是乙個怎麼樣的dal?也許你已經見過許多實用ef的架構了,它是一套基於領域模型架構中的da...