采集器延迟问题总结

       这个没有那些技术细节


       中间其实就是加了两个队列，一个用来接受数据，一个用来批量往数据库插数据


        两个轮流换，用一个标识位判断现在哪个接受数据

 

        系统怎么防止数据传输过程中的中断，比如断电、断网？

 

       我们有两套服务器，一主一备

 

       接口有超时重传机制，还有心跳监控，像这种宕机，心跳监控肯定会报警，而且肯定大量数据包超时

 

        超时一定次数就会切换到备用服务器

 

 

 

       工行网银防中断策略：

       工行有六百多套服务器，分七节点，北方四节点，南方三节点，这样基本上个别服务器宕机，和一个地方大的自然灾害啥的都能恢复过来

        前端用的是f5硬件负载均衡，平常用户访问https是走443端口，我们还另外开了一个446端口用与f5健康检查。

 

       数据的采集方式：

 

主动和被动都有

 

主动是会定时去底层系统的数据库或者文件里采集数据，被动就是实时数据了，是下面给发过来

 

低层数据库或文件的数据有哪些

 

我们有些实时性要求不高的数据，比如用来做日报表的数据，像加点站充电数据，车辆行驶数据，就放在下面那些充电监控和车载系统数据库里，我们每天定时去读

 

实现上就是通过spring的定时任务管理器开线程去读

 

 

 

 

报表这块还出国性能问题

 

 

 

充电数据太大，很快就到几千万条了

 

 

实时报表展现速度特别慢

 

 

瓶颈就在数据库，每次展现报表就要在那么多数据库里来几个子查询，有时候十几分钟都跑不完

 

 

后来优化从两部走

 

 

首先是sql语句，主要是调整那些嵌套子查询，把关联子查询改称非关联的

 

 

后来发现速度变快，但还是满足不了要求

 

 

尝试加索引什么的都不管用

 

 

最后开始考虑优化程序逻辑

 

 

以前每次展现报表都是直接从原始表读数据分析

 

 

后来通过分析，业务要求的数据其实是有共同点的，基本上都是在原始表上面做一些计算

 

后来想到加一个中间表

 

每天半夜采集数据后，顺带把原始表数据加工成报表需要的内容，放入中间表

 

这个过程虽然速度不快，但是在半夜不影响客户使用，跑十几分钟也没事

 

 

 

 

等到客户在页面里展现报表时，直接读中间表，加一些查询就行了，因为中间表数据大大小于原始表，所以就很快了

需要采集数据的设备：

主要是充电桩

 

充电站的其他东西也有监控

 

 

 

 

这个系统的最后一个问题，咱们采集的应该有很多重复记录，重复记录有除重吗

 

咱有两个库，一个实时一个历史

 

历史好像没有去重

 

实时库之前用的是更新的方式，所以不存在重复