前些天有幸和一位移动端的架构师一起探讨了移动端日志采集、存储、上传的架构设计，受益匪浅。在此总结一下。
总体架构图如下：
LogUploadFramework.png
日志采集、存储、上传三要素：
1. 客户端。用户在客户端上的操作可以产生日志，包括用户交互动作，网络请求结果等。
2. 数据库。保存日志适合用数据库进行存储，便于进行增删改查操作。
3. 服务器。移动端将日志上传到服务器，由服务器对日志做进一步分析处理。
日志类型
移动端的日志并没有统一的分类标准，在此仅仅列出三个可供参考的日志分类：
1. 及时上传的日志。例如，崩溃日志。
2. 定时或定量上传的日志。例如，某个按钮被点击的次数。
3. 用于本地调试，不需要上传的日志。例如，某个接口的响应结果。
上传日志优先级
对应不同的日志类型，建议设置不同的上传优先级：
1. 立即上传。
2. 定时或定量上传。
3. 无需上传。
数据库分表及建立索引
对应不同类型的日志，建议分成不同的表，便于对日志进行增删改查操作。
日志较多时，建议建立索引便于查询和删除。
日志三要素的协调者：checker、uploader
checker: 校验工具类。用于读取数据库中的数据，检查是否有日志符合上传的条件，一旦有符合上传条件的日志，就通知uploader。
uploader: 上传工具类。用于根据上传条件，从数据库中取数据，并上传。根据上传结果，更新数据库或通知checker做进一步处理。
触发日志上传校验的事件
移动端的日志何时上传，需要一个触发机制。一般而言，可分为：
1. 日志存储成功后，若是需要立即上传的日志，主动触发一个立即上传的事件
2. APP启动时事件
3. APP从后台切换到前台事件
4. 日志上传失败
三要素及三要素的协调者设计原则
-
各司其职。
* client负责搜集日志，并将日志传给storage。 * storage用于存储日志，并对外提供增删改查的接口. * checker负责在合适的时机，查询storage中是否有符合上传的日志，一旦有符合上传的日志，便交由uploader进一步处理. * uploader从storage中读取数据，并发起网络请求，上传到server。 -
设计模式--工厂模式
* 日志分为不同的类型，对应不同类型的日志有不同的处理过程，例如，存储、校验、上传。 * 尽管处理过程不同，但他们的处理过程有相似之处，只是在具体实现上有部分差异。 * 工厂模式--定义一个用于创建对象的接口，让子类决定实例化哪一个类。
其他细节
* 失败重传策略
* 不同网络状态下，上传策略的优化
* 数据库建立索引字段的选择
* checker查询数据库粗略查询VS精确查询。例如，查询需要定量上传的日志时，只统计每条日志的粗略size,而非精确地size,可提升查询效率
