整个就是个队列+消费队列的流程。

给个思路系列：

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.【不阻塞】：不可能完全不阻塞，只能做到阻塞时间尽量短而无法引起感知。这需要使用任务切分与分时处理两种机制。甚至还可以引入基于机器学习的性能曲线预估，以及实时负载均衡两种高级处理办法。