1. 生成行为数据

神策的服务端 SDK 是通过 Consumer 去构建适用不同场景的 SensorsAnalytics 实例,一般来说会有三种 Consumer:DebugConsumer、BatchConsumer、FileConsumer(在不同代码实现里实际的类名和这里不一致)。他们分别对应三种使用场景:

  1. DebugConsumer 会通过网络直接发送数据,它是为方便开发者调试而设置的模式,该模式会逐条校验数据并在校验失败时抛出异常。
  2. BatchConsumer 会通过网络直接发送数据,通常用于导入小规模历史数据或者离线 / 旁路导入数据的场景。
  3. FileConsumer 会把数据输出到指定目录并按天切割生成日志,通常线上服务建议采用此模式。

因为 FileConsumer 完全不会使用到网络请求,只是吐行为数据的日志,因此它在服务端的表现最为稳定。服务端网络波动的情况不会影响到 Consumer 的运行,只要服务器不宕机就不会影响到线上用户行为的采集。FileConsumer 毕竟只是吐日志,我们还需要配合 LogAgent 将数据导入到神策。

2. 上报行为数据

LogAgent 是神策自研用于将后端数据实时导入到神策分析的工具,它一般适用于以下场景:

  1. 我的程序不方便嵌入神策分析的 SDK,但又想将程序输出的数据导入神策分析。
  2. 我希望在本地生成神策分析的导入数据,并在本地保留完整的副本。
  3. 我不想自己控制数据发送进度,但又希望发送的数据不重不漏。

LogAgent 会不停的 tail 目录下符合规则的文件,如果有数据那么就将数据简单格式校验并打包发送到神策分析,如果没有那么就等待一段时间再次 tail 检查。LogAgent 还可以自动切换到新生成的按天切割的日志文件并且它在启动时会和神策服务端通信,获取到本地目录文件的发送进度,以实现断点续传。

3. 总结

通过 FileConsumer 和 LogAgent 的配合,把数据的生产与上报环节完全的分开,尽可能的适应服务端的复杂情况。日志会有一定的容灾能力,而 LogAgent 负责不重不漏完成上报。

 

每日一问的答案中可能无法全完解读这个问题,如果您是相关技术专家或者是对本问题有自己的见解,欢迎带着「批判性」的态度阅读,指正其中的不足。