實任何簡單的問題，只要規模大了都會成為乙個問題，就如中國人口多，很多小問題都會變成大問題一樣。但處理這種海量資料的方法無非就是分治和」人海」戰術。使用人海戰術的前提是問題的劃分能夠支援這種人海戰術，其手段無非是切割（縱向，橫向）和負載均衡。縱向分隔主要是按業務（功能）來分，也就是所謂面向服務架構，橫向分隔方式比較多，主要依賴於所處理的物件屬性，比如時間屬性或者特定業務資料屬性劃分（比如鐵路客票的車次（每個車次的操作基本上是獨立的））；負載均衡則可以是映象（部署）分布（同樣的功能部署幾份）和計算分布（乙個問題分幾個子問題在不同的機器上執行，然後合併結果）。當然，這些手段是可以綜合利用的，最終可以做成多流水線分布式計算模式。另一方面，在海浬資料面前，通用的資料處理方式會很困難，高效的方法基本都是有業務針對性和資料針對性的。
1）海量資料處理的基本思想：分治（這種思想在日常生活中無處不在，螞蟻都知道，一次運不完，分多次運）
2）海量資料處理的基本手段：切割和負載均衡（切割是降低規模，負載均衡是人海戰術，人多力量大，同樣，機器多也計算能力強）
3）海量資料處理的可靠性保障：多存幾份（再好的機器也會壞，雞蛋不要放在乙個籃子裡）
4）海量資料處理的最高境界：多流水線並行作業（很多任務廠都這樣幹，用在計算機也沒問題）
5）海量資料處理的最好方法：沒有最好，只有適合（什麼都想做好，基本等於什麼都做不好）
至於高併發處理，最好的解決辦法是針對特定的需求採用特定的方法，基本的方法包括加鎖，排隊等等。另外乙個關鍵就是要盡量簡化事務和減少事務。
有這種意識，只要去想，總能解決，沒必要把這些技術搞得很神，從技術上來講，海量資料處理所涉及的思想和演算法都不是很難。
ps：這些天很多人都在鄙視鐵路網上售票系統，也有很多人在為其出主意，我覺得沒必要，真的，這些思想和技術不是很難的，至少我都能想到，做網上售票的這般兄弟姐妹也一定可以想到，至於為什麼是這個結果，他們也只是「被」沒技術。鐵路是講政治的地方，何苦皇帝不急太監急呢？
資料劃分補充：如果按時間劃分，2種情況，分資料庫（早期很多企業級級業務系統，特別是財務系統都是這樣做），分表（這種一般只針對特定業務表來進行）。按時間劃分的時候需要注意單筆業務跨時間段得問題（很多軟體都是在通過關帳開賬把這種資料轉到新的時間段裡）。
2012-1-11：補充資料劃分，按特定屬性劃分，用得最多的是按資料歸屬來劃分，比如原來的帳套，現在雲計算下的多租賃使用者id（企業使用者id)，這種方式可以在三種級別上（表級，資料庫（oracle分使用者）級，物理級（多資料庫例項））實現，注意點快取的話，利用負載均衡，可以無限擴充套件。這種基於現有資料庫的模式，可靠性保證只能用資料庫本身來實現，雖然用軟體也可以實現同乙份資料多地方儲存，但比較複雜。另外，利用資料庫的鏈結也可以實現縱向分庫存放，而且對應用透明，但這種方式維護起來比較麻煩，很多時候也沒有必要。(oralce和sqlserver都可以，而且不同庫之間還可以join,看起來很方便，但不建議，業務緊密聯絡的還是要放在一起，不同庫之間還是不要採用鏈結上join，直接在記憶體中參照還快些)
上面都是說，等過兩天有時間，我把我做的架構demo放出來，當然正式版是不能放的（也還沒有），那也是公司的版權。
補充兩個圖：
只需要通過配置檔案在資料訪問排程層和資料庫訪問層做好動態處理，就可以實現資料中心內部分資料庫存放和跨資料中心進行資料訪問的功能。
《海量資料處理常用思路和方法》
1.bloom filter 對於原理來說很簡單，位陣列 k個獨立hash函式。將hash函式對應的值的位陣列置1，查詢時如果發現所有hash函式對應位都是1說明存在，很明顯這 個過程並不保證查詢的結果是100 正確的。同時也不支援刪除乙個已經插入的關鍵字，因為該關鍵字對應的位會牽動到其他的關鍵字。...
海量資料和高併發的解決方案
快取 a 程式主要使用map，尤其是concurrenthashmap b 常用的快取框架有ehcache,memcache和redis 頁面靜態化 a 頁面靜態化是將程式最後生成的頁面儲存起來 b 常用freemarker和velocity根據模板生成靜態頁面 c 另外也可以使用快取伺服器在應用伺...
Bitmap和2 Bitmap海量資料處理問題
內容會持續更新，有錯誤的地方歡迎指正，謝謝 要解決上面的問題，都需可以用bitmap或2 bitmap。bitmap也就是位圖 引出bitmap 舉乙個小例子，有乙個無序整形陣列，也就占用記憶體3 4 12位元組，這很正常，但如果有1億個這樣的數呢？1億 4 1024 1024 1024 0.372...