从需求角度来讲，用户往往需要采集指定目录指定格式下的文件，常用方式是配置路径通配符，例如这样: /path/*/*.log，意思就是收集/path/a/web.log、/path/b/web_2018-12-11.log等日志。但是，用文件名来标识文件是不准确的，移动一个文件mv a.log b.log，虽然名称是变成了b.log，但实际日志依旧是a.log的日志，把b.log当做新文件处理就会出现采集到重复日志的问题。

那换成inode作为文件唯一标识怎么样？答案是，会好点。为啥是好一点而已呢，原因有2个，一是不同文件系统间的不同文件inode可以一样，二是同个文件系统下，不同时刻存在的文件inode可以一样。这2个问题都可以导致读取日志时的偏移量错乱问题，最终导致数据丢失或者数据重复。

那换成内容前缀的方式唯一标识怎么样？内容前缀指的是使用文件前N个字节作校验。很显然，这也是一个缓解的操作，因为不同日志依旧有出现相同校验码的情况。这里的校验码算法可以使用crc32或者adler32，后者相比前者可靠性弱一点，性能则是前者的2~3倍。

目前最靠谱的方式是通过inode+内容前缀的方式唯一标识文件，虽然没办法完全解决唯一标识文件的问题，但鉴于同个文件系统不同时刻产生的文件刚好内容前缀有相同的情况概率比较低，所以该方案已经符合业务使用了。

有时用户有合并日志的需求，比较常见的就是异常堆栈信息，一行日志被换行符分割成了多行。因为日志都是有规范的，会按时间、日志等级、方法名、代码行号等信息顺序打印，那这里一个简单的处理方式就是使用正则匹配的方式来解决，按照匹配行作split划分日志。

批量化处理，一是日志读取批量化，虽然读取日志已经是顺序读了，但如果在读取时通过预读取提前把待读取的日志都读取出来放进buffer，这方式可以进一步提升性能。二是发送批量化，发送批量化的好处主要体现在2方面，一方面是提高压缩比，像日志这类存在大量重复内容的数据，数据越多压缩比越高，另一方面，降低了请求头部的大小占比，减少带宽的浪费。

异步化处理，文件监听、日志处理、日志发送3个模块解耦并异步化，数据及通知通过队列传递。

非阻塞发送，发送端要处理的常规操作包括参数校验、序列化、压缩、协议包装、ack、重试、负载均衡、心跳、校验和、失败回调、数据收发、连接管理。如果这系列操作都是由一个nio线程处理掉，发送效率肯定很低，但考虑到通常数据接收端数量不会太多（小于1000），所以这里使用reactor的多线程模型完全足够了，netty支持reactor多线程模型的，所以可以直接基于netty开发。这里只需要注意io线程除了连接管理，其余事情都交由工作线程处理就行。