其實任何簡單的問題，只要規模大了都會成爲一個問題，就如中國人口多，很多小問題都會變成大問題一樣。但處理這種海量數據的方法無非就是分治和”人海”戰術。使用人海戰術的前提是問題的劃分能夠支持這種人海戰術，其手段無非是切割（縱向，橫向）和負載均衡。縱向分隔主要是按業務（功能）來分，也就是所謂面向服務架構，橫向分隔方式比較多，主要依賴於所處理的對象屬性，比如時間屬性或者特定業務數據屬性劃分（比如鐵路客票的車次（每個車次的操作基本上是獨立的））；負載均衡則可以是鏡像（部署）分佈（同樣的功能部署幾份）和計算分佈（一個問題分幾個子問題在不同的機器上運行，然後合併結果）。當然，這些手段是可以綜合利用的，最終可以做成多流水線分佈式計算模式。另一方面，在海里數據面前，通用的數據處理方式會很困難，高效的方法基本都是有業務針對性和數據針對性的。
1）海量數據處理的基本思想：分治（這種思想在日常生活中無處不在，螞蟻都知道，一次運不完，分多次運）
2）海量數據處理的基本手段：切割和負載均衡（切割是降低規模，負載均衡是人海戰術，人多力量大，同樣，機器多也計算能力強）
3）海量數據處理的可靠性保障：多存幾份（再好的機器也會壞，雞蛋不要放在一個籃子裏）
4）海量數據處理的最高境界：多流水線並行作業（很多工廠都這樣幹，用在計算機也沒問題）
5）海量數據處理的最好方法：沒有最好，只有適合（什麼都想做好，基本等於什麼都做不好）
....
至於高併發處理，最好的解決辦法是針對特定的需求採用特定的方法，基本的方法包括加鎖，排隊等等。另外一個關鍵就是要儘量簡化事務和減少事務。
有這種意識，只要去想，總能解決，沒必要把這些技術搞得很神，從技術上來講，海量數據處理所涉及的思想和算法都不是很難。
PS：這些天很多人都在鄙視鐵路網上售票系統，也有很多人在爲其出主意，我覺得沒必要，真的，這些思想和技術不是很難的，至少我都能想到，做網上售票的這般兄弟姐妹也一定可以想到，至於爲什麼是這個結果，他們也只是“被”沒技術。鐵路是講政治的地方，何苦皇帝不急太監急呢？
數據劃分補充：如果按時間劃分，2種情況，分數據庫（早期很多企業級級業務系統，特別是財務系統都是這樣做），分表（這種一般只針對特定業務表來進行）。按時間劃分的時候需要注意單筆業務跨時間段得問題（很多軟件都是在通過關帳開賬把這種數據轉到新的時間段裏）。
2012-1-11：補充數據劃分，按特定屬性劃分，用得最多的是按數據歸屬來劃分，比如原來的帳套，現在雲計算下的多租賃用戶ID（企業用戶ID)，這種方式可以在三種級別上（表級，數據庫（Oracle分用戶）級，物理級（多數據庫實例））實現，注意點緩存的話，利用負載均衡，可以無限擴展。這種基於現有數據庫的模式，可靠性保證只能用數據庫本身來實現，雖然用軟件也可以實現同一份數據多地方存儲，但比較複雜。另外，利用數據庫的鏈接也可以實現縱向分庫存放，而且對應用透明，但這種方式維護起來比較麻煩，很多時候也沒有必要。(Oralce和SQLServer都可以，而且不同庫之間還可以Join,看起來很方便，但不建議，業務緊密聯繫的還是要放在一起，不同庫之間還是不要採用鏈接上Join，直接在內存中參照還快些)
上面都是說，等過兩天有時間，我把我做的架構demo放出來，當然正式版是不能放的（也還沒有），那也是公司的版權。
補充兩個圖：
只需要通過配置文件在數據訪問調度層和數據庫訪問層做好動態處理，就可以實現數據中心內部分數據庫存放和跨數據中心進行數據訪問的功能。