之前用python写了一个实时分析日志文件的脚本，对分析的数据结果写入mysql数据库。期初因为对入库的实时性没有做太多关注，最近一个项目对数据写入db的实时性非常看重，发现之前的脚本在现在的场景下，会出现累积时间延迟。运行时间长了后，会产生很大的累积时延。
开始分析问题，还好在分析日志文件和入库的部分加了log打印，定位时先将入库部分屏蔽，发现实时分析系统么有问题，分析文本没有时延引入。
接下来看入库部分，开始优化sql，调整db的引擎，分表这些手段都使用了后，也没有改善。
在分析网络，写入的数据库和执行写入脚本的服务器分表部署在不同城市IDC，网络时延约为30ms，本地时延0.7ms。看到这个结果后，开始考虑同idc部署。
在开始申请资源的同时，也在考虑使用的入库方式。原来在每处理一条业务数据的时候，就马上去写入db，这样因为mysql的同步API导致每次都会引入一定时延，然后这个引入时延就会叠加到处理下一条文件数据。随着数据量增大就会带来更大的时延
开始考虑读取一定量的文本数据后，再批量写入一次DB。按照这个思路重新修改sql语句。类似“insert into table (name1,name2) values (val1,val2),(val11, val22)”，在mysql客户端上执行命令没有问题，但是用python的cursor.execute(sql)执行的时候发现，报语法错误。于是google这种情况，发现python的MySQLDb模块本身有个处理多条插入的接口：executemany。
于是赶紧加入到代码中验证，使用了批量提交后，基本分析都是实时了。引入的操作db时延，只会让下一次处理的文本数据内容多一些，不会累积产生时延。在入库操作快于文件生成速度时，不会带来时延问题。
另外在文本分析阶段，引入set，对重复数据做一次去重。
使用sql的insert ignore语句将主键重复的数据也丢弃掉，最终需要写db得数据就会很少
问题得到解决，结论值得思考，如果使用Python的模块时，最好多该模块的所有接口都了解一下，弄清楚使用场景。
另外分析这种实时系统里，一定要考虑各个环节带入的时延是否具有累积性。for循环内部不要引入时延
阅读(1566) | 评论(0) | 转发(0) |
