C++ 高性能无锁日志系统
服务器编程中,日志系统需要满足几个条件
.高效,日志系统不应占用太多资源
.简洁,为了一个简单的日志功能引入大量第三方代码未必值得
.线程安全,服务器中各个线程都能同时写出日志
.轮替,服务器不出故障是不重启的,半年一年的日志放到一个文件会导致文件过大
.及时保存,程序故障导致异常退出,此时需要通过日志诊断问题,不缓冲的日志系统更易用
著名的日志库有log4xxx系列,提供了非常灵活的功能,当然随之而来的代价就是庞大的库。在大多数服务器应用中,所需的功能不多,我偏向于选择一个支持按时间轮替的简洁的日志库。
为了同时做到线程安全和支持轮替,大多数日志系统都使用锁。写出日志时,首先获取锁,如果需要轮替,则进行轮替操作,否则写到现有文件,最后释放锁。
google开源的leveldb的日志系统中,同时做到了“线程安全”和轮替,但是没有用锁,这引发了我的兴趣。
仔细阅读发现它的运作原理是
.每个log操作,都会生成相关的字符串,最终调用write,写出到日志系统的文件描述符fd。
.进行rotate操作时,重新命名旧文件,保持旧文件的打开状态,然后打开新文件,将fd设置为新文件。
.接下来sleep 200ms,然后把close旧文件
那么轮替过程中,fd的值为fd_old或者fd_new,只要fd的读写是原子的,不会读取到非fd_old和fd_new的其他值即可(fd是int,这点可以做到)。write操作就没有问题
如果由于系统繁忙,fd读取为fd_old之后,走到操作系统的write之前,线程被切换,并且经过了200ms,那么fd_old就有可能会在sleep 200ms之后被关闭,那么write就可能失败。
因此这种做法是简洁的,能够应对绝大多数情况,但并非安全,而且切换时需要sleep 200ms也是个让人头疼的问题。
借鉴leveldb的做法,加上posix上的dup2调用则可以完美的解决这个问题。
.轮替时,首先重命名旧文件,保持旧文件的打开状态,然后打开新文件。
rename(oldname, newname);
fd = open(oldname,...);
.使用dup2系统函数把fd_new复制到fd_old上
dup2(fd, fd_);
.关闭fd_new
close(fd);
其中dup2是原子操作,它会关闭fd_old并且把fd_old也指向fd_new打开的文件。因此fd_old这个文件描述符总是保持打开状态,并且值不变,但是前后指向了不同的文件。另一边write也是个原子操作,它与dup2不会交叉进行,因此保证了日志系统的正确性。
详情参见开源库handy中的logging.h和logging.cc,里面一部分代码采用了C++11的语法
https://github.com/yedf/handy/tree/master/handy
handy的日志系统中,日志要做的内容就是使用snprintf格式化要输出的内容,然后调用write,没有多余的工作,因此做到了简洁高效
通过前面介绍的原理同时实现了无锁的线程安全,和日志轮替
每次日志的输出都write,即使程序崩溃,日志也已经到了操作系统层,不会丢失,易于调试问题
当然高效与及时保存有一定的冲突,如果缓存多条数据然后合并write能够提升一定的性能,但这里我选择简洁与易用
handy的日志系统性能测试可以参见项目examples下的log-bench.cc,在我笔记本电脑上的虚拟机的压力测试中,输出文件为/dev/null时,能够达到75w/s的qps
PS:handy的日志轮替中,对lastRotate_的读取和修改并非原子类型,可能会导致多轮替一次,解决方法为使用C++11中的原子类型,或者就容忍了(多轮替一次会在后续的操作中失败,仅仅多输出了一条信息到标准错误)。
C++ 高性能无锁日志系统的更多相关文章
- 高性能无锁队列 Disruptor 初体验
原文地址: haifeiWu和他朋友们的博客 博客地址:www.hchstudio.cn 欢迎转载,转载请注明作者及出处,谢谢! 最近一直在研究队列的一些问题,今天楼主要分享一个高性能的队列 Disr ...
- DIOCP开源项目-Delphi高性能无锁队列(lock-free)
最近想在DIOCP中加入任务调度线程,DIOCP的工作线程作为生产者(producer)将接受到的数据对象,投递到任务调度线程中,然后统一进行分配.然而这一切都需要一个队列, 这几天都在关注无锁队列. ...
- BP-Wrapper:无锁竞争的缓存替换算法系统框架
BP-Wrapper:无锁竞争的替换算法系统框架 最近看了一个golang的高性能缓存ristretto,该缓存可以很好地实现如下功能: Concurrent High cache-hit ratio ...
- HAProxy + Keepalived + Flume 构建高性能高可用分布式日志系统
一.HAProxy简介 HAProxy提供高可用性.负载均衡以及基于TCP和HTTP应用的代 理,支持虚拟主机,它是免费.快速并且可靠的一种解决方案.HAProxy特别适用于那些负载特大的web站点, ...
- 基于无锁队列和c++11的高性能线程池
基于无锁队列和c++11的高性能线程池线程使用c++11库和线程池之间的消息通讯使用一个简单的无锁消息队列适用于linux平台,gcc 4.6以上 标签: <无> 代码片段(6)[ ...
- php的高性能日志系统 seaslog 的安装与使用
一.什么是日志系统 一般用于记录系统运行时的信息,一般分为三类:系统日志,应用程序日志,安全日志.日志功能不能影响用户的正常使用. 二.为什么需要日志功能 1.了解系统运行情况 2. ...
- EasyDarwin开源流媒体服务器高性能设计之无锁队列
本文来自EasyDarwin团队Fantasy(fantasy(at)easydarwin.org) 一. EasyDarwin任务队列实现 EasyDarwin的任务队列是通过OSQueue类来组织 ...
- 【转载】scribe、chukwa、kafka、flume日志系统对比
原文地址:http://www.ttlsa.com/log-system/scribe-chukwa-kafka-flume-log-system-contrast/ 1. 背景介绍许多公司的平台每天 ...
- scribe、chukwa、kafka、flume日志系统对比 -摘自网络
1. 背景介绍许多公司的平台每天会产生大量的日志(一般为流式数据,如,搜索引擎的pv,查询等),处理这些日志需要特定的日志系统,一般而言,这些系统需要具有以下特征:(1) 构建应用系统和分析系统的桥梁 ...
随机推荐
- accept_mutex与性能的关系 (nginx)
注:运行环境CentOS 6+ 背景 在对启动了20个worker的nginx进行压力测试的时候发现:如果把配置文件中event配置块中的accept_mutex开关打开(1.11.3版 ...
- MVC5 网站开发之九 网站设置
网站配置一般用来保存网站的一些设置,写在配置文件中比写在数据库中要合适一下,因为配置文件本身带有缓存,随网站启动读入缓存中,速度更快,而保存在数据库中要单独为一条记录创建一个表,结构不够清晰,而且读写 ...
- C#多线程之线程同步篇2
在上一篇C#多线程之线程同步篇1中,我们主要学习了执行基本的原子操作.使用Mutex构造以及SemaphoreSlim构造,在这一篇中我们主要学习如何使用AutoResetEvent构造.Manual ...
- CRL快速开发框架系列教程十二(MongoDB支持)
本系列目录 CRL快速开发框架系列教程一(Code First数据表不需再关心) CRL快速开发框架系列教程二(基于Lambda表达式查询) CRL快速开发框架系列教程三(更新数据) CRL快速开发框 ...
- 总结30个CSS3选择器
或许大家平时总是在用的选择器都是:#id .class 以及标签选择器.可是这些还远远不够,为了在开发中更加得心应手,本文总结了30个CSS3选择器,希望对大家有所帮助. 1 *:通用选择器 ;; ...
- iOS从零开始学习直播之3.美颜
任何一款直播软件都必须进行美颜,不然哪来的那么多美女,所以技术改变世界,不只是说说而已.美颜在采集的时候就得就行,让主播实时看到直播的效果. 1.美颜原理 其实美颜的本质就是美白和磨皮,分别通 ...
- HTML5 标签 details 展开 搜索
details有一个新增加的子标签--summary,当鼠标点击summary标签中的内容文字时,details标签中的其他所有元素将会展开或收缩. 默认状态为 收缩状态 设置为展开状态为 <d ...
- JS中关于字符串的几个常用又容易忘记的方法
1>.字符串连接:concat(): 左边字符串. concat(连接的字符串1,字符串2,....); 获取指定位置的字符:charAt(): 返回指定位置的字符: 字符串.charAt(i ...
- ReactNative入门 —— 动画篇(下)
在上篇动画入门文章中我们了解了在 React Native 中简单的动画的实现方式,本篇将作为上篇的延续,介绍如何使用 Animated 实现一些比较复杂的动画. 动画组合 在 Animated 中提 ...
- 论C#之多继承
C#多继承的讨论似乎是个古老的问题了,但今天本文要向大家展示的C#多继承可能是大家闻所未闻见所未见的,甚至是发明C#语言的人也不曾想到我会这样去写代码,并且自得其乐. 说起多继承,首先大家可以想想这个 ...