【腾讯Bugly干货分享】微信mars 的高性能日志模块 xlog

本文来自于腾讯bugly开发者社区，未经作者同意，请勿转载，原文地址：http://dev.qq.com/topic/581c2c46bef1702a2db3ae53

Dev Club 是一个交流移动开发技术，结交朋友，扩展人脉的社群，成员都是经过审核的移动开发工程师。每周都会举行嘉宾分享，话题讨论等活动。

本期，我们邀请了 腾讯 WXG Android 高级工程师“闫国跃”，为大家分享《微信mars 的高性能日志模块 xlog》。

---

大家好 我是来自腾讯微信的闫国跃，很荣幸能给大家做这个分享，我今天主要给大家分享微信mars 的高性能日志模块 xlog 

1. Mars 简介

首先介绍一下mars 是什么。

mars 是微信官方的终端基础组件，是一个使用 C++ 编写的业务性无关，平台性无关的基础组件。 

可以看一下mars 简单的架构图：

从图中就可以看出它主要包括以下几个部分：

1. comm：可以独立使用的公共库，包括 socket、线程、消息队列、协程等
2. xlog：可以独立使用的日志模块
3. sdt：可以独立使用的网络诊断模块
4. stn：可以独立使用的信令分发网络模块

目前接入平台：Android、iOS、Mac、Windows、WP等 。现正在筹备开源中。可以这么说，接入 mars 之后，开发一个应用只需要把开发重心放在业务层和 UI 层上，底层的日志模块和网络模块在 mars 中都已经提供。

在使用用户数上有月活跃8亿的微信用户帮忙背书(数据来源于财报)。 在数据监控上，纯网络监控，长连接有18项 短连接7项。

接下来我重点讲今天的主角mars的 xlog 部分。我们先来思考一下为什么需要日志，日志什么时候能显示其作用。

2. 为什么需要 xlog

我们来看一下微信早期跟进问题的流程是怎么样的： 

当用户反馈或者我们发现问题时，我们需要联系用户，用户答应配合后，然后修改代码打开日志重新编包让用户试图重现问题，重现之后才能继续排查。这个流程是由当时使用的日志方案所决定的。例如 Android 平台使用 java 实现日志模块，每有一句日志就加密写进文件。这样在使用过程中不仅存在大量的 GC，更致命的是因为有大量的 IO 需要写入，影响程序性能很容易导致程序卡顿。

选择这种方案，在 release 版本只能选择把日志关掉。不仅定位问题的效率低下，而且并不能保证每个需要定位的问题都能重现。这个方案可以说主要是为程序发布前服务的。

在接着往下讲之前，我们先来分析一下这个日志方案所存在的问题。这个日志方案主要的问题就是性能太差。主要性能瓶颈是出现在频繁写文件上。写文件的大致流程如下图： 

当写文件的时候，并不是把数据直接写入了磁盘，而是先把数据写入到系统的缓存(dirty page)中，系统一般会在下面几种情况把 dirty page 写入到磁盘：

• 定时回写，相关变量在/proc/sys/vm/dirty_writeback_centisecs和/proc/sys/vm/dirty_expire_centisecs中定义。
• 调用 write 的时候，发现 dirty page 占用内存超过系统内存一定比例，相关变量在/proc/sys/vm/dirty_background_ratio（ 后台运行不阻塞 write）和/proc/sys/vm/dirty_ratio（阻塞 write）中定义。
• 内存不足。 

数据从程序写入到磁盘的过程中，其实牵涉到两次数据拷贝：一次是用户空间内存拷贝到内核空间的缓存，一次是回写时内核空间的缓存到硬盘的拷贝。当发生回写时也涉及到了内核空间和用户空间频繁切换。

dirty page 回写的时机对应用层来说又是不可控的，所以性能瓶颈就出现了。

而且相对于机械硬盘，SSD 存储还有一个“写入放大”的问题。这个问题主要和 SSD 存储的物理结构有关。当 SSD被全部写过一遍之后，再写入的数据是不可以直接更新，只可以通过覆盖重写，在覆盖之前需要先擦除数据。但写入的最小单位是 Page，擦除的最小单位是 Block，而 Block 远大于 Page，所以在写入新数据时就需要先把Block 上的数据读出来和要写入的数据合并在一起，再把 Block 擦除，最后把读出来的数据重新写入到存储上，这样导致实际写入的数据可能远远大于最开始需要写入的数据。 

举个最简单的例子：