Java 大数据量处理问题

11-02-24 liujian1979
我先描述下我的需求吧:

1.每秒有200-300条数据从短信网关上来。

2.每条短信在处理逻辑中需要二次确认,所以这些短信就要被当做原始记录(对象)保持起来

3.二次确认可能需要很长时间,比如30分钟,超过30分钟就被删除掉。

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

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

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

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

请各位出出主意,谢谢!

         

1
atealxt
2011-02-24 22:21
个人觉得“把有限的数据保存在内存中,超过的部分持久化”这种方式不靠谱,不如在其他方面想办法优化。

业务中间的验证可以使用缓存,如果需要记录短信的话,至少也要写1-2遍数据库吧?

这个并发量我感觉还好,数据库是能够支持的。

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

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

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

猜你喜欢