（五）如何编写高性能日志

一、服务器端日志与客户端日志的区别

在正式讲解之前，我们先来看一个日志类的实现方法，这个日志类也是代表着大多数客户端日志的主流写法：

这个Log类的定义和实现代码节选自我的一款12306刷票软件，如果需要使用这个类的话包含Log.h头文件，然后使用宏：LogInfo/LogWarning/LogError这三个宏就可以了。示例如下：

这个日志类，每次输出一行，一行中输出时间、日志级别、线程id、文件名、行号、函数签名和自定义的错误信息，演示如下：

上文中也说了，以上示例是我曾经写的一款客户端程序的日志，注意“客户端”这个重要的关键字。因为上述日志的实现虽然通用，但其局限性也只能用于客户端这样对性能和效率要求不高的程序（这里的性能和效率是相对于高并发高性能的服务器程序来说的，也就是说上述日志实现可用于大多数客户端程序，但不能用于高性能高并发的服务器程序）。那么上述程序存在什么问题？问题是效率低！

不知道读者有没有注意上，上述日志类实现，是在调用者线程中直接进行IO操作，相比较于高速的CPU，IO磁盘操作是很慢的，直接在某些工作线程（包括UI线程）写文件，程序执行速度太慢，尤其是当日志数据比较多的时候。

这也就是服务器端日志和客户端日志的区别之一，客户端程序日志一般可以在直接在所在的工作线程写日志，因为这点性能和时间损失对大多数客户端程序来说，是可以忽略的，但对于要求高并发（例如并发量达百万级乃至千万级的系统）的服务器程序来说，单位时间内耗在磁盘写操作上的时间就相当可观了。我目前的做法是参考陈硕的muduo库的做法，使用一个队列，需要写日志时，将日志加入队列中，另外一个专门的日志线程来写日志，我给出下我的具体实现代码，如果需要查看muduo库的做法，请参考陈硕的书《Linux多线程服务端编程：使用muduo C++网络库》关于日志章节。注意：以下是纯C++11代码：

以上代码只是个简化版的实现，使用std::list来作为队列，使用条件变量来作为新日志到来的触发条件。当然，由于使用了两个固定长度的数组，大小是256和512，如果日志数据太长，会导致数组溢出，这个可以根据实际需求增大缓冲区或者改用动态长度的string类型。使用这两个文件只要包含Logger.h，然后使用如下一行代码启动日志线程就可以了：

生成日志，使用头文件里面定义的三个宏LogInfo、LogWarning、LogError，当然你也可以扩展自己的日志级别。

二、日志里面应该写些什么？

我开始在试着去写日志的时候，也走了不少弯路，无论是客户端还是服务器端，日志写的内容倒是不少，但都是些废话，虽然也报出故障，但对解决实际问题时毫无作用。尤其是在服务器上生产环境以后，出现很多问题，问题也暴露出来了，但是由于日志含有的当时现场的环境信息太少，只能看到错误，却没法追踪问题，更别说解决问题了。我们来看两个具体的例子：

这条日志记录，只打印出一条警告信息和命令号（cmd），对具体产生这个警告的输入参数和当时的环境也没进行任何记录，即使产生问题，事后也无法追踪。再看一条：

这条日志，因为http请求报了个简单的错误，至于产生错误的参数和原因一概没有交待，这种日志如果在生产环境上出现如何去排查呢？出错原因可能是设置的参数非法，这是外部原因，可以解决的，甚至是交互双方的一端传过来的，需要对方去纠正；也可能是当时的网络故障，这个也可以解决，也不算是程序的bug，不需要解决；也可能是的bug引起的，这个需要程序作者去解决。另外，如果是服务器程序，甚至应该在错误中交待下产生日志的用户id、操作类型等信息，这样事后才能便于定位位置，进行重现等。

总结起来，日志记录应该尽量详细，能反映出当时出错的现场情节、产生的环境等。比如一个注册请求失败，至少要描述出当时注册的用户名、密码、用户状态（比如是否已经注册）、请求的注册地址等等。因为日志报错不一定是程序bug，可能是用户非法请求。日志详细了，请不用担心服务器的磁盘空间，因为相比较定位错误，这点磁盘空间还是值得的，实在不行可以定期清理日志嘛。

另外一点是，可以将错误日志、运行状态日志等分开，甚至可以将程序记录日志与业务本身日志分开，这样排查故障时优先查看是否有错误日志文件产生，再去错误日志里面去找，而不用在一堆日志中筛选错误日志。我的很多项目在生产环境也是这么做的。

以上是关于日志的一些个人心得吧，如有一些说的不对的地方，欢迎指正。