设计思路－－征求－－５００分见人头给分

需求：
　　　（１）1000个地域分散数据采集点．要求不间断的（借助ＧＰＲＳ／ＣＤＭＡ／光钎网络）向数据服务器（公网ＩＰ）写入数据．
　　　（２）数据量每个点每５秒钟５k（９５％的时间是这个数据量）.首次传输的时候数据量是１０Ｋ左右．
　　　（３）另外有不小于１００个用户同时通过ＷＥＢ服务器浏览实时采集的数据．
　　　（４）同时需要将所采集的数据保存．数据量大概是５０Ｍ／天．
重点征求：
　　　（１）采集点和数据服务器之间采用什么方式传输最合适．
　　　（２）因为实时数据使用得非常频繁（插入和检索），请问用什么办法保存实时数据最合适．
　　　（３）考虑到用户通过公网查询数据，如何保证数据得到实时的刷新．将时延控制在５秒以内．
　　　 (4)　数据库设计中需要注意一些什么问题．
请大家指教！谢谢

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

因为考虑到从监测点的数据可能要经过n次路由到数据服务器．所以呢，我是想用isapi，向ＷＥＢ服务器的web服务发出写数据的命令．由ＷＥＢ上面的服务来完成后数据库之间的协同．不知道这种方式合适不．
1。GPRS太慢，CDMA可能还要等等，光纤吧，算法要做好防止出错
2。买个高级点的server和数据库，速度很快的，科学应用一般是oracle吧
3。“将时延控制在５秒以内”如果是指always，那不太可能吧（也没有必要吧），平均的话，还是可以的
4。小心911，注意备份 ^_^
建议使用三台服务器
A：做数据库
B：与数据采集点连接
C：做WEB服务器B和C有公网IP，A不需要，B和C连接AB和C对数据和请求进行确认和简单处理
存取方面的操作就交给A
几点建议，不要见笑哈：
1 应仔细设计架构，需考虑到将来的扩展。
2 根据实际得应用设置合理的实时数据缓存机制，无论是做在内存还是做在单独的数据库里都行，用一个适当的过期机制刷新缓存，并把过期的数据写入数据库。
3 根据我以前做过的类似的系统，有一点也重要：因为是实时监测，时间一长，数据量会很大，同时，监测端正常的时候的数据，时间越久远，其数据的重要性越小，所以设计一个合理数据过滤原则很重要，例如一个月之内，以5秒的间隔保存一组，一个月之前到一年之前，以1分钟的间隔保存一组，以次内推。当然，有异常的时候的数据的密度越大越好。这个又设计到异常判定等。
4 哪种数据数据传输方式都可以，根据你的架构来定。如果服务器压力不大，用TCP长连接也无妨。
5 ISAPI可以的，我见过一个这样的实现。不过我个人以为，那个系统用ISAPI的目的是方便被监测端通过防火墙（这样就不需要额外的代码来通过代理向服务器POST数据了）。带来的不方便是，会收到IIS的影响。一旦IIS崩溃，连数据都采不到。当然还有别的问题。
5k/5s,cdma和gprs就不用考虑了，稳定性差，断线后数据积累太多，追都追不回来。
1.GPRS可能达不到这个速度,GPRS通讯终端向主台通讯完全的接受的话或许还可以
2.UDP震动唤醒方式减少费用
3.使用实时库[内存]同步有点公网很容易掉线可能不适合长不间断时间传输专网网络要好的多
必要的解释：
　　　（２）数据量每个点每５秒钟５k（９５％的时间是这个数据量）.首次传输的时候数据量是１０Ｋ左右．
       （这个地方的数据量可以进一步压缩，只传输变化的数据，而且我们正考虑一套对应码，绝大多数采集点在９５％的时间都控制在２k/5秒．首次传输数据量在５Ｋ左右）．
　　　（３）另外有不小于１００个用户同时通过ＷＥＢ服务器浏览实时采集的数据．
　　　　（１００个用户所浏览的实时数据是指当前最近５秒的数据，这５秒过后的数据意义不是太重大了．做数据分析来所，用户大多数时间是使用最近５天采集的数据．每天按５分钟的时间段按一定算法存储的数据．）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
一些不太成熟的思路，请大家指正：
　　　因为系统一旦组建肯定是多种网络平台的混合（其中包括ＧＰＲＳ／ＣＤＭＡ／光纤）．其中要跨越防火墙，多次路由．为了让采集点的程序尽量标准，通用性强一些，所以考虑使用isapi．使用isapi我不用考虑服务器端数据监听的问题，把大量的工作都抛给了iis．但是这样呢iis的压力就显得特别大，我没有用isapi写过雷同的程序，所以不知道能否经受得住这样的压力．
　　　对于数据保存的问题，我是这样考虑的．将最近５天的数据保存在内存中，建立一个内存数据库，将一些对这５天内数据的频繁操作封装，直接从内存中提取．超过５天的数据进行转存到数据库中，超过三个月的数据存为文本，根据需要进行装载了．
　　　请大家指正！谢谢
一些不太成熟的思路，请大家指正：
　　　因为系统一旦组建肯定是多种网络平台的混合（其中包括ＧＰＲＳ／ＣＤＭＡ／光纤）．其中要跨越防火墙，多次路由．为了让采集点的程序尽量标准，通用性强一些，所以考虑使用isapi．使用isapi我不用考虑服务器端数据监听的问题，把大量的工作都抛给了iis．但是这样呢iis的压力就显得特别大，我没有用isapi写过雷同的程序，所以不知道能否经受得住这样的压力．
//我觉得isapi也只能带来你所说的好处。如果考虑实现几种常用代理，加上你这样的系统应该可以要求被监测端提供合理的网络环境，应该可以解决采集点程序的标准。但是由此带来的在安全性和稳定性方面的不利影响，感觉得不偿失。　　　对于数据保存的问题，我是这样考虑的．将最近５天的数据保存在内存中，建立一个内存数据库，将一些对这５天内数据的频繁操作封装，直接从内存中提取．
//保存在内存中需考虑这个因素，如果实时数据到来的时候，仅仅只写入内存，速度当然提高。但是如果中间服务器崩溃，数据就不可挽回。如果写入内存的同时，又写入数据库，反而划不来。也许用追加方式建一文件或建一临时数据库，实时数据写入内存的同时也写入永久介质，待监测到服务器空闲时再整理到历史数据库。超过５天的数据进行转存到数据库中，超过三个月的数据存为文本，根据需要进行装载了．
//按数据重要度决定数据密度，能大幅减少数据总量。　　　请大家指正！谢谢
我的一点建议：
      （1）传输方式建议用光纤方式，经济合理，根据地理位置实际情况给部分地区采用无线方式。
      （2）看你的数据量50M/天，不是很大，用Oracal浪费，SQL就行了。用一般的浪潮、联想就可以了，联想支持国货也经济可靠，不过最好买中高端服务器。
      （3）你的用户也不是很多，数据刷新使用定时器，每5-10s刷新一次。
      （4）数据库设计？《数据结构》清华版不错，哈哈，设计的时候脑子要清晰最重要。最后就是备份，如果数据特别重要，则建议异地备份。其实就是一个简单的数据查询网站代码，呵呵。看看网上的例子就差不多全通了。
1，如果采集点采集到的数据可以少量丢失，使用UDP传输即可。这需要定时握手。
2，把采集点送来的数据放内存表中缓存，等待一定时间再刷新到数据文件中，避免频繁读写文件。
3，WEB页做个插件显示数据，用查件启动时想服务器注册，然后不断接收服务器发来的UDP数据报，刷新WEB上的显示插件。因为数据只是查看，偶尔丢包不要紧。这需要定时握手。
4，如果采集到的数据不复杂，可以不使用数据库，自己定义数据文件即可，访问也方便。
做过一个类似的系统
GPRS太慢了, 实际中很慢的, 有时候还掉线
CDMA没试过, 应该快些
1.TCP方式比较好
2.数据接收端维护一个采集队列,缓减对数据库的压力
数据库服务器端采用前端数据库和后端大型数据库配合工作，超过X天就归档到后端归档数据库。
3.配置一台统计查询应用服务器,根据需要来决定从前端还是后端提取信息
4.数据库可能不止一个，因此要保持实时性同时要保证数据的一致性
使用TCP/IP，对于套介子只要没有数据立即断开
很好的题目，没做过也想学学习学习，有一些看法：1.  数据在网络上传输，必然会存在短时断网的情况，采集点和数据服务器之间应采用TCP方式传输数据，数据包中应指明数据包的时间（最好是序号，从0点0 分开始计算），同时服务器应对数据包加以确认。在断网期间采集点，负责保存为发出的数据直到网络恢复正常再将其发送出去。
2.  实时数据频繁的操作，故一定将段时间内的数据存于内存，同时应实时将这些数据以一定的方式存储下来(最好有冗余备份)，交由另一台服务器负责将其存入数据库。
3.  用户客户端每５秒向服务器申请一次刷新(传送增量数据：改动或新增的数据)．
4.  还不知道
这个系统大概能值多少钱？
BYE THE WAY ：ADD A HEAD