关于算法:浅谈融云即时通讯服务日志优化

《神探狄仁杰》剧迷们对狄仁杰的断案能力极为叹服，狄小孩儿总是能将十分诡异的案件查得上不着天; 下不着地，连武则天都赞他“神乎其技”。实际上，狄仁杰之所以被称为“神探”，很大一部分起因，是他善于通过极为细小的线索推导、还原，进而破案。关注【融云 RongCloud】，理解协同办公平台更多干货。

对应到软件开发上，用来记录零碎或程序运行状态的 日志，已成为程序运行问题的重要“线索”，它能够记录程序运行过程，疾速定位问题，便于程序的监控和优化。

日志应用

Java 畛域有多种日志框架，Log4j2 是其中一种。Log4j2 凭借可配置化的集成形式、简略的 API、弱小的性能及性能劣势，成为 Java 畛域应用最宽泛的日志解决方案。

融云即时通讯服务的日志框架抉择的就是 Log4j2。

日志级别

Log4j2 定义了 8 个日志级别，别离是：OFF、FATAL、ERROR、WARN、INFO、DEBUG、TRACE、ALL。其中罕用的日志级别是 4 个，优先级从低到高为 DEBUG、INFO、WARN、ERROR。

DEBUG
指定细粒度信息事件是最有用的利用程序调试，次要用于开发过程中打印一些运行信息。

INFO
指定可能突出在粗粒度级别的利用程序运行状况的信息，能够帮忙程序员无效理解程序的流转，可用于生产环境中输入程序运行的一些重要信息。

WARN
指定具备潜在危害的状况，有些信息是错误信息，但也须要给程序员的一些提醒。

ERROR
谬误事件，可能依然容许应用程序持续运行，打印谬误和异样信息。

日志性能

日志打印对服务器性能产生损耗，会增大服务的提早，升高服务吞吐量。尤其 在高并发大业务量状况下，日志打印得越多，服务的性能损耗越大。

即时通讯服务在进行压力测试过程中，开启 INFO 级别日志与开启 ERROR 级别日志做比拟，随着业务量级的增大，服务的性能损耗也一直增大。

而在理论运行中，因私有化部署的束缚和对问题排查便利性的思考，即时通讯服务往往是开启 INFO 级别日志，这就对在 INFO 级别下即时通讯服务的性能提出了更严厉的考验和更高的要求。

为此，融云即时通讯服务除了做好日志级别分类和日志内容精简外，还进行了相干优化。

日志优化

敞开 Location 信息

如果 Log4j 配置了 %C or $class, %F or %file, %l or %location, %L or %line, %M or %method 等配置项，Log4j 将会获取堆栈的快照，遍历堆栈轨迹来获取 Location 信息，从而影响性能。

对于同步日志记录器来说，速度要慢 1.3 – 5 倍；对于异步日志记录器而言，获取堆栈快照的性能影响甚至更大，因为有地位的日志记录比没有地位的日志记录慢 30-100 倍。因而，异步日志记录器和异步附加器在默认状况下不蕴含地位信息。

所以，融云即时通讯服务去掉了 %C or $class, %F or %file, %l or %location, %L or %line, %M or %method 等配置，通过在日志中增加类名以及埋点标识的形式用于疾速定位问题代码。

应用 Async Loggers

Asynchronous Loggers 是 Log4j2 中的一个新性能，它们的指标是从对 Logger.log 的调用尽快返回到应用程序。

LMAX Disruptor
Asynchronous Loggers 应用了 Disruptor，Disruotor 是一个无锁的线程间通信库，不应用队列，取得了更高的吞吐量和更低的提早，可通过 Maven 引入。

劣势
a. 更高的峰值吞吐量
应用异步日志记录器，应用程序能够以 6 – 68 倍 于同步日志记录器的速度记录音讯。
b. 更低的响应提早
响应提早是在肯定工作负载下调用 Logger.log 返回所需的工夫。

劣势
错误处理。如果在日志记录过程中呈现问题并抛出异样，那么 Asynchronous Logger 或 Appender 不太容易向应用程序裸露此问题。不过，可通过混合同步和异步日志记录器的形式解决，即同步和异步日志记录器在配置中组合应用。

全副异步日志记录器

可通过以下形式使所有日志记录器异步。将 disruptor 的 jar 增加到环境变量，并设置服务启动的 JVM 参数，减少

-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector

或

-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector

混合同步和异步日志记录器

同步和异步日志记录器能够在配置中组合应用，这样可提供更大的灵活性，但与所有日志记录器都是异步的相比性能略有降落。

性能比拟

吞吐量

下图比拟了同步日志记录器、异步 Appender 记录器和异步日志记录器的吞吐量，这是所有线程的总吞吐量。在应用 64 个线程的测试中，异步日志记录器的速度比异步 Appender 记录器快 12 倍，比同步日志记录器快 68 倍 。异步日志记录器的吞吐量随着线程数量的减少而增长，然而不论记录日志的线程数多少，同步日志记录器和异步 Appender 记录器的吞吐量根本不变。

下图将异步日志记录的峰值吞吐量与其余日志框架中的异步 Appender 记录的峰值吞吐量进行了比拟，与上图后果相似。异步 Appender 记录器，在增加更多线程时，线程的日志吞吐量根本放弃不变, 异步日志记录器在多线程场景中能更无效地利用机器上可用的多个外围。

响应提早

下图比拟了 Logback 1.1.7、Log4j 1.2.17 与 Log4j 2.6 各种异步日志记录选项的响应时间延迟，可看到 Logback 1.1.7、Log4j 1.2.17 的提早峰值比 Log4j 2 大了很多数量级。

下图比拟了雷同测试的 log4j2 后果，可看到基于 ArrayBlockingQueue 的 Async Appender 的响应工夫最高，Garbage-free Async Loggers 具备最佳响应工夫。

测试

测试条件

1. 3000 client 在线
2. 25W 条单聊音讯

测试比照

应用的同步日志记录器

应用的全副异步日志记录器

吞吐量比照图

响应提早比照图

测试论断

优化后，融云即时通讯服务在开启 INFO 级别日志时，应用全副异步日志记录器比应用同步日志记录器在性能上将取得更大晋升，吞吐量晋升约 50%，响应提早升高约 50%。

回看狄仁杰封神之路不难发现，破案离不开对仅存证据的抽丝剥茧；相应的，想要迅速锁定程序出问题环节，日志就是最无力的“证据”。作为即时通讯服务赛道上长期“参赛者”，融云将秉持初心和使命，保持自我反动、继续迭代，致力于为更多客户提供最优即时通讯服务。