整個就是個隊列+消費隊列的流程。

給個思路系列：

1. 使用monitor指令監聽redis事件，或升級redis版本(>=2.8)，監聽redis改動事件。

2. 多進程/執行緒/協程處理事件(例如放入緩衝區)

3. 緩衝區資料批次插入資料庫。 (mysql似乎最多一次插入5000條，不確定，可能是9999或4999，但是有上限)，依靠SQL資料庫事務功能，失敗即回溯。

侃大山系列：

4.這麼大的資料可以考慮列資料庫，hbase之類。

不負責任系列：

5.似乎有人說mongodb資料量大會就有問題，包括國外國內，以及身邊的人測試過之後的結論

用的是什麼資料庫，MySQL和SQL Server單機版效能差很多。 SQL Server / Oracle /DB2的效能是一個等級的，開源的MySQL效能不是很好，考慮集群，postgresql要好點
這麼大的資料量要想遷入到資料庫裡，要考慮
1） 合適的索引，能大大提高寫入效能。
2） 資料庫如果沒有設計主從，那就考慮上RAID或SSD，性能跟普通的機械硬碟差的不是一點半點。
3） 採用不同的資料庫引擎，以MySQL為例，InnoDB和MyISAM還是有效能差異。
4） 不要每筆記錄都commit，集中commit效能會好10倍以上。
5） 讀寫分離，否則你會發現寫入資料阻塞了資料的讀取。

如果每天的資料量都這麼大的話，那SQL就不適合了，考慮上Hadoop + HBase吧。
其實你採用什麼資料庫更多的取決於你的資料格式，有些資料庫對特定格式的資料是比較友善的，例如HDF5對二進位和空間資料就更友善一點

這麼大的資料量用mongodb會快一點

mysql 沒怎麼用過，不過SQL Server 有批次匯入功能一秒輕鬆過萬。
我想Mysql也有批次插入的功能吧，插入過後，後製就要考慮分庫分錶 主從這類的了。

每天插1億條資料到mysql。 。 。分析查詢都是個問題。 。不過應該只是歷史數據吧

1.【完整】：使用校驗機制。

2.【高效率】：使用批次讀取、大量寫入的方式或專用介面。

3.【不阻塞】：不可能完全不阻塞，只能做到阻塞時間盡量短而無法引起感知。這需要使用任務切分與分時處理兩種機制。甚至還可以引入基於機器學習的效能曲線預估，以及即時負載平衡兩種高階處理辦法。