解析大文件日志随笔

最近工作中，有一个要解析文件，每天的文件大概30G左右gz压缩文件，每行大概是一个diviceId对应着一堆package，插入数据库的要以package为主键，等于是转一下映射。

显然全部读取到内存的方法也就只能想想了

最初的想法，写文件，首先按行遍历日志文件，每一行有大概50-100个package名字，循环package，写相应package名字的文件，然后，解析出文件之后，再写数据库。

单线程遍历这数据，大概24小时消费不完一天的日志。

加了几个时间戳，发现占用时间较多的是每一行遍历package写文件的时候，于是想用线程池，去消化这部分操作，主线程遍历每行，遍历到这个package数组就加入线程池，等待子线程消化，顺其自然的也加上了文件锁。

刚开始的时候，的确很快，阿里云的16核16G内存，开的15个线程，开始很快，后来越来越慢，cpu利用率也就刚到1，发现本来不应该消耗太多的内存，却消耗了很多，以为是流没关，检查了多遍代码都没效果之后，发现可能是，线程池的队列内存占用很多。

于是，换了一种模式，每个线程消费一个文件，每天的日志有20多个文件，每个线程负责读取文件，解析行，写package的文件，这样，内存降下来了，但是随着时间的推移依然很慢，猜测可能是锁的原因，让每个线程，单独写一个package的文件，依然得不到缓解，反而更慢了。

后来猛然发现，，锁是进程共享的。。我却用线程去获取锁，释放锁。。只得改成进程，启动脚本同时启动8个进程去并行写文件。

然而，写的速度依然越来越慢。。。最终发现还是因为管理的文件太多，因为文件已package命名，每天大概60W个文件，只得放弃这个中转文件的格式，改用每个线程写一个文件，写的每一行加上package名字，这样速度才稳定。。同时读写的文件，不能太多，，即使写完就释放。。。

每个线程写一个文件，导致同一个package依然会存在每个线程的文件中，查找一个package需要遍历所有的文件，依然没法继续，又修改为获取package的md5，写16个文件，这样使得相同的package在同一个文件，这样的结果可以接受。

文件锁是进程级别的。。。