日志上报里的方案折衷！（第22讲）

《架构师之路：架构设计中的100个知识点》

22.日志上报里的方案折衷

为了节省流量，APP能不能不上报日志？

不能。有些用户行为是不会与服务器进行交互，例如TAB的点击，外链的跳转，从服务器日志无法完成统计。

APP一般怎么主动上报日志？

通常有三种方法：

其一，第三方SDK，例如：Google Analytics；

其二，可以开发一个web应用收集；

其三，复用web-server日志收集；

其中，第三种方案使用较多。

如何复用web-server日志进行数据收集？

例如，在Nginx下放一个空文件，APP访问这个空文件，利用GET参数传递数据，通过access日志得到数据。

如何通过GET参数传递数据？

通常有两种方法：

其一，约定格式法。例如：

http://shenjian.com/up?[bj][123][login]

其中，空白文件是up，分隔符是[]，第一个字段城市，第二个字段uid，第三个字段登录行为。

约定格式法省流量，但扩展性差。

其二，KV法。例如：

http://shenjian.com/up?city=bj&uid=123&action=login

KV法扩展性好，能自解释，使用广泛，但大量重复KEY导致耗流量。

那有什么节省流量的方法吗？

可以进行这6大优化：

其一，手动构造HTTP请求，去除UA，COOKIE等无效内容；

其二，用尽可能短的域名；

其三，用尽可能短的KEY，不要用city=bj，直接用c=bj；

其四，可以先存本地，批量上报；

其五，数据压缩；

其六，检测到wifi连接时优先上报；

先存本地，再批量上报，怎么保证数据时效性？

会有少量延时，但影响不大，可以实施这3大策略来优化：

其一，特殊时间点上报策略，例如：APP退出前必须上报；

其二，按时间上报策略，例如：每隔3分钟上报一次；

其三，按数据量上报策略，例如：每100条日志上报一次；

通常来说，这三种策略可以结合使用。

我去，上报个日志，有必要搞这么复杂吗？

不复杂，能晋升吗？

想省事，还是花钱用第三方SDK吧。

知其然，知其所以然。

==全文完==