被神化的海量資料處理和高並發處理

其實任何簡單的問題，只要規模大了都會成為一個問題，就如中國人口多，很多小問題都會變成大問題一樣。但處理這種海量資料的方法無非就是分治和”人海”戰術。使用人海戰術的前提是問題的劃分能夠支援這種人海戰術，其手段無非是切割（縱向，橫向）和負載平衡。縱向分隔主要是按業務（功能）來分，也就是所謂面向服務架構，橫向分隔方式比較多，主要依賴於所處理的對象屬性，比如時間屬性或者特定業務資料屬性劃分（比如鐵路客票的車次（每個車次的操作基本上是獨立的））；負載平衡則可以是鏡像（部署）分布（同樣的功能部署幾份）和計算分布（一個問題分幾個子問題在不同的機器上運行，然後合并結果）。當然，這些手段是可以綜合利用的，最終可以做成多流水線分散式運算模式。另一方面，在海裡資料面前，通用的資料處理方式會很困難，高效的方法基本都是有業務針對性和資料針對性的。

1）海量資料處理的基本思想：分治（這種思想在日常生活中無處不在，螞蟻都知道，一次運不完，分多次運）
2）海量資料處理的基本手段：切割和負載平衡（切割是降低規模，負載平衡是人海戰術，人多力量大，同樣，機器多也計算能力強）
3）海量資料處理的可靠性保障：多存幾份（再好的機器也會壞，雞蛋不要放在一個籃子裡）
4）海量資料處理的最高境界：多流水線並行作業（很多工廠都這樣幹，用在電腦也沒問題）
5）海量資料處理的最好方法：沒有最好，只有適合（什麼都想做好，基本等於什麼都做不好）

....

至於高並發處理，最好的解決辦法是針對特定的需求採用特定的方法，基本的方法包括加鎖，排隊等等。另外一個關鍵就是要盡量簡化事務和減少事務。

 有這種意識，只要去想，總能解決，沒必要把這些技術搞得很神，從技術上來講，海量資料處理所涉及的思想和演算法都不是很難。

 

PS：這些天很多人都在鄙視鐵路網上售票系統，也有很多人在為其出主意，我覺得沒必要，真的，這些思想和技術不是很難的，至少我都能想到，做網上售票的這般兄弟姐妹也一定可以想到，至於為什麼是這個結果，他們也只是“被”沒技術。鐵路是講政治的地方，何苦皇帝不急太監急呢？

 

資料劃分補充：如果按時間劃分，2種情況，分資料庫（早期很多企業級級業務系統，特別是財務系統都是這樣做），分表（這種一般只針對特定業務表來進行）。按時間劃分的時候需要注意單筆業務跨時間段得問題（很多軟體都是在通過關帳開賬把這種資料轉到新的時間段裡）。

2012-1-11：補充資料劃分，按特定屬性劃分，用得最多的是按資料歸屬來劃分，比如原來的帳套，現在雲端運算下的多租賃使用者ID（企業使用者ID)，這種方式可以在三種層級上（表級，資料庫（Oracle分使用者）級，物理級（多資料庫執行個體））實現，注意點緩衝的話，利用負載平衡，可以無限擴充。這種基於現有資料庫的模式，可靠性保證只能用資料庫本身來實現，雖然用軟體也可以實現同一份資料多地方儲存，但比較複雜。另外，利用資料庫的連結也可以實現縱向分庫存放，而且對應用透明，但這種方式維護起來比較麻煩，很多時候也沒有必要。(Oralce和SQLServer都可以，而且不同庫之間還可以Join,看起來很方便，但不建議，業務緊密聯絡的還是要放在一起，不同庫之間還是不要採用連結上Join，直接在記憶體中參照還快些)

 

上面都是說，等過兩天有時間，我把我做的架構demo放出來，當然正式版是不能放的（也還沒有），那也是公司的著作權。

補充兩個圖：

 

只需要通過設定檔在資料訪問調度層和資料庫訪問層做好動態處理，就可以實現資料中心內部分資料庫存放和跨資料中心進行資料訪問的功能。