项目要求大数据量实时转发，应该怎样才能保证转发最快？项目要求：要做一个服务程序，它不断从一条专线取得数据，带宽为700kbit/s（每年都会增大，所以要假设会更大一些）。然后把它分解为一段一段的信息，转发给客户端。每个信息都是二进制数据，平均为1Kbytes。客户端大约有3、5个，可能局域网，可能是互联网。同时该服务程序要保留所有收到的数据，因为每个客户端登录时，都需要把之前所有的信息都传过去。同时该服务程序还要求在重启程序或者服务器后，能够把之前收到的信息都恢复过来，所以要求它在收到信息后，要把信息保存在磁盘上。项目经理反复强调，要做到最快的转发，是该项目的最重要指标。同时出错恢复也是必不可少。服务器的硬件：双CPU + 4G内存，型号不明
软件：mina，用于socket接收信息。
如果用数据库，则使用spring的jdbctemplate，不使用事务我想了以下几个方案，不知道哪个最合适：1.保存在内存中
用一个ArrayList<byte[]>，每次从专线收到信息后，马上放到它里面，然后转发给客户端。同时把它里面的数据写到硬盘上的一个文件中，以供出错恢复。
但是这样的话，我担心内存中放太多的对象，会对JVM的性能产生不利影响。因为到下午的时候，该list中将会有几十万个byte[]，总大小会在500M到1G之间。2.保存在内存数据库
与1基本相似，但是数据是保存在hsql的内存数据库中，同时写到硬盘上以供出错恢复。不知道这样对jvm的影响会不会小一些。3.保存在硬盘数据库
使用postgresql，每次收到数据后，直接写在数据库里。然后通知客户端来读取。这样不需要为出错恢复做额外工作，直接读取数据库即可。但是写到数据库会不会延时较大？4.同时使用硬盘数据库和内存数据库（或ArrayList<byte[]>）
收到信息后，先保存在内存数据库，然后转发。同时再把信息保存在数据库中，内存中只保留最近的若干条信息。时间紧而且测试麻烦，我没有办法一一测试上面这几种想法，不知道大家有没有好的意见或建议？
软件：mina，用于socket接收信息。
如果用数据库，则使用spring的jdbctemplate，不使用事务我想了以下几个方案，不知道哪个最合适：1.保存在内存中
用一个ArrayList<byte[]>，每次从专线收到信息后，马上放到它里面，然后转发给客户端。同时把它里面的数据写到硬盘上的一个文件中，以供出错恢复。
但是这样的话，我担心内存中放太多的对象，会对JVM的性能产生不利影响。因为到下午的时候，该list中将会有几十万个byte[]，总大小会在500M到1G之间。2.保存在内存数据库
与1基本相似，但是数据是保存在hsql的内存数据库中，同时写到硬盘上以供出错恢复。不知道这样对jvm的影响会不会小一些。3.保存在硬盘数据库
使用postgresql，每次收到数据后，直接写在数据库里。然后通知客户端来读取。这样不需要为出错恢复做额外工作，直接读取数据库即可。但是写到数据库会不会延时较大？4.同时使用硬盘数据库和内存数据库（或ArrayList<byte[]>）
收到信息后，先保存在内存数据库，然后转发。同时再把信息保存在数据库中，内存中只保留最近的若干条信息。时间紧而且测试麻烦，我没有办法一一测试上面这几种想法，不知道大家有没有好的意见或建议？
在这里跟楼主分享一下过去做电信业务系统的经验
电信级短信发送相信楼主能想像得到,每个中继站每秒中所得到的信息量都不少于10K.关于数据中继,我们的解决方案是常规查询采用持久层(HIBERNAT).它能高效处理大规模常用数据查询,相信大伙都知道它的工作原理,在这就不班门弄斧.通过事务处理并发执行数据转发&数据持久化.
数据侍侯服务与业务侍侯服务分离,采用SOCKET管通通信,处理需要查询或/出错,数据依然保存在内存,通过数据侍候服务接口提取数据. 这种结构的好处:内存中只保存部分迫切数据,避免了内存中过多的"无效"数据.当所查询的数据在内存不存在时,才起用查询数据库,减少了系统资源的耗费!
MQ没用过，但是现在时间紧，没机会去尝试新技术了。to hello_brick
sql已经是最最简单的了，只有两个：
一个是insert into t1(xx,xx,xx) values(xx,xx,xx)
一个是select from t1 where xx=xxto Jasonsystem :
hibernate我也在考虑，它的缓存功能其实和我4中说的在内存中保存一些数据以供查询是差不多的。不过这个数据量有点大，每秒700多K,想想都头大先谢谢几位