生产消费者模型的应用--大数据量处理

   生产消费者模型我们都挺熟悉的，用程序实现来说就是有个数据区，一个线程放数据、一个读数据。

   现在有个需求，读取数据库记录进行加工并显示，如果数据量比较大，如1000W，读取数据、加工到显示整个过程用时几秒，而项目要求页面等待时间小于2S，由于页面显示数据不会一次性显示那么多，因此如果加工好一页数据显示就ok了，可以将读取数据库加工记录放入缓冲区，页面显示时读取缓冲区。。。

   如j2ee web页面显示数据库记录(假如，虽然并不现实).

   action或servlet在获得resultSet后启动线程处理resultSet放入EhCache缓存，线程启动即返回页面，页面通过Ajax访问后台，后台读取EhCache并返回json供页面显示。

   此应用模型目前我在思考，没实现及应用，可行否正在确定。如果看此文的同学有神马建议可以说说。。

 

直接分页查询不能满足2s的要求？缓存1000W条数据？数据量的大小（平均每条记录即使只有100Byte，1000W也有1G的数据量）？添加、删除数据？
感觉还是分页现实点。

海量数据的运算显示，最好是不要在如此多的数据中做运算，比如限制时间等。如果非要在这么大的数据量中做计算，最好是提前算好数据，查询时候直接在运算好的结果中进行查询。如果非得实施运算，最好在数据库端运算，而不是都加载到虚拟机中算好了再返回指定页数记录。

1：如果是延迟查询的话，后台定时跑计算程序生成结果供前台直接查询。
2：如果是实时查询的话，对于企业应用类似报表类型的数据暂时还没想到很好的方法。

这种设计是为处理报表需求的，运算指的是小计，按照某列的值进行分组求和、平均值等。为了打印报表，小计行的部分也要算到结果集的行数中，所以结果集查询分页就无法实现跳转到某一页，因为有了小计就不好计算该页对应的resultSet的位置。而且分页查询的话某列的汇总可能涉及到前几页或后几页数据就不好处理了。并且这需求不好直接在数据库中计算。

队列不好用么？

如果数据量太大，岂不容易导致内存溢出，所以选择能存储到硬盘的ehcache，限定内存数据量。

1千万数据，从数据库查询出来都不只2秒了，只有预先计算，搞后台任务定时计算并缓存，查询的时候直接取缓存。实时性差了点，取决于计算的间隔和耗时，看你们的需求了。

还有个思路，就是一直维护一个计算结果，数据变更的时候同时变更计算结果，降低单次更新的性能。

web页面是给人看的，1000W条数据，你就算分页了，就算缓存了，就算你半秒钟就显示了，有谁去看这么多数据呢？
这是应用逻辑的问题，而不是技术问题。