Java 大数据量处理问题

我先描述下我的需求吧：
1.每秒有200-300条数据从短信网关上来。
2.每条短信在处理逻辑中需要二次确认，所以这些短信就要被当做原始记录（对象）保持起来
3.二次确认可能需要很长时间，比如30分钟，超过30分钟就被删除掉。

从上面需求看，以30分钟为界限就需要存储：30*60*300=54万的数据量如果以60分钟为界线就是100多万存储量

那么请哪位大哥们看一下下面哪种方法可行？或者有更好的方法帮我想想。

1.通过LRU缓存迁出算法，把有限的数据保存在内存中，比如10万，超过的部分持久化到数据库中。这样做好处是实现方式简单，但是这样做增加了数据库的负担，因为高峰期本来数据库负荷就很高，所以不希望再增加数据库负担。

2.通过LRU缓存迁出算法，把有限的数据保存在内存中，比如10万，超过的部分持久化到本地磁盘上。这样做可以不增加数据库负担，但持久到磁盘以文件方式存储，这样做对于高速查询来说比较吃力，因为只有通过遍历方式查询，不知有更好的查询方式没有？

请各位出出主意，谢谢！

个人觉得“把有限的数据保存在内存中，超过的部分持久化”这种方式不靠谱，不如在其他方面想办法优化。

业务中间的验证可以使用缓存，如果需要记录短信的话，至少也要写1-2遍数据库吧？
这个并发量我感觉还好，数据库是能够支持的。

另外可以考虑使用jms等消息队列。

如果采用第一种方式，超过部分存入数据库，在数据库负荷很重的情况下是不是不能采用此中方式？用JMS方式是否满足需求需要自己亲自验证一下。非常感谢2楼

java处理的是对象，数据库处理的是数据。想要用好缓存，得以“一切活动在内存”的思维来指导。在来，考虑数据库并发问题，是架构处理和系统配置的问题，并非业务功能着重考虑的。“二次确认可能需要很长时间，比如30分钟，超过30分钟就被删除掉。”是系统需求的功能需求，你不能把cache的超时，用在这个地方，否则你对cache就会错意了。cache只是把你常常需要用到的东西放到内存中而已，而不是帮你解决业务功能问题。你应该放到cache中后，在系统中自己编写一个有效时间注册器，然后让注册器remove掉。