最近一个项目,对计算效率时实性要求比较高,我把所有数据都放到内存里面操作计算,这个时候如果进程被意外终止(人为 kill 或者说 oom kill 都可能),数据就会全部丢失,所以需要定时的把内存数据备份到磁盘(数据可能几十 M,也可能十几个 G ),这样进程重启就可以读取备份文件恢复数据到内存,丢失几分钟的数据还是可以接受的;还有一个需求是需要有个触发器线程,会在一定情况触发去同步内存数据到硬盘。
总的来说就是一个定时线程,一个触发器线程,有几率会出现多线程写一个文件情况,多线程写文件比较好解决,首先想到的就是给文件上锁,确实可以解决多线程环境写的问题,但是无法解决在写的时候,进程被意外 kill,写到一半操作被终止,数据就会被损坏,这个时候比较尴尬的就是直接在原文件基础操作的,数据完全被损坏,进程重启找不到完整的数据去恢复,于是想到每次备份的时候写到不同的文件里面,这个时候面临的问题就是如果数据很大,就会产生 n 个备份文件,极端情况也无法接受,毕竟磁盘也是钱阿。所以抛出的问题就是多线程环境内存数据安全持久化到磁盘。
寻找一种原子级别的备份操作,备份成功则数据更新,备份失败保留原始数据,由于是原子操作,也不存在多线程的竞争问题
首先将内存数据写入一个随机的 tmp 文件,然后使用 rename 函数将 tmp 文件更新为备份文件名字,rename 的 manpage
If newpath already exists it will be atomically replaced (subject to a few conditions; see ERRORS below), so that there is no point at which another process attempting to access newpath will find it missing.
重点就是只要操作系统不 crash,rename 操作就是原子的。
bool
concurrent_safe_backup()
{
ofstream ofs;
std::string tmp = "tmp";
static default_random_engine e(time(0));
//random filename
tmp += to_string(e());
//open
ofs.open(tmp);
if (!ofs) {
return false;
}
std::string contentString = "data";
ofs << contentString;
ofs.close();
int ret = rename(tmp.c_str(), "memory.bak");
if (ret == -1) {
return false;
}
//done
return true;
}
经过大神指点,参考redis实现,最后我修改代码大概是这样,调用fflush和fsync强制数据刷入磁盘。
bool
concurrent_safe_backup()
{
ofstream ofs;
std::string tmp("tmp");
//random filename
static default_random_engine e(time(0));
tmp += to_string(e());
//open
FILE* fp = fopen(tmp.c_str(), "w");
if (!fp) {
return false;
}
std::string contentString("dataaaaaa\n");
fwrite(contentString.c_str(), 1, contentString.length(), fp);
/* Make sure data will not remain on the OS's output buffers */
if (fflush(fp) == EOF) return false;
if (fsync(fileno(fp)) == -1) return false;
if (fclose(fp) == EOF) return false;
/* Use RENAME to make sure the DB file is changed atomically only
* if the generate DB file is ok. */
int ret = rename(tmp.c_str(), "memory.bak");
if (ret == -1) {
return false;
}
//done
return true;
}
1
polythene 2018-11-08 15:54:08 +08:00
Write Ahead Log?
|
2
feverzsj 2018-11-08 16:09:25 +08:00
把中间数据提交到数据库不就可以了
|
3
muntoya 2018-11-08 16:14:21 +08:00 1
fork 以后在子进程里安心写磁盘就行了,子进程的内存保持不变,redis 就这么做的
|
4
huhu3312 2018-11-08 16:19:01 +08:00
天池大赛啊。。。。key-value 数据库复赛
|
5
yzmm 2018-11-08 16:20:38 +08:00
hi...
|
6
iiusky 2018-11-08 16:23:31 +08:00
hi,二狗
|
7
petelin 2018-11-08 17:24:20 +08:00
推荐看下#3 的方式去写数据. 可以保证内存数据不变.另外你可以创建文件名是 data_{utcnano}.txt 的文件不就不会覆盖之前的了吗. 写失败的你就删了就得了.
|
8
ooo3o 2018-11-08 17:35:17 +08:00
先分线程各自写一个, 再跑一个慢慢归并.
|
10
firebroo OP @muntoya 问题不在于内存变不变。。而是解决写的时候写操作被 kill -9 中断导致写文件损坏
|
12
leavan 2018-11-08 18:29:15 +08:00
一般来说如果是追加到文件末尾的话,即使 kill 掉也只会导致文件末尾没写上...
|
13
feverzsj 2018-11-08 18:31:40 +08:00
你让 sqlite 之类的嵌入式数据库帮你代理读写就可以了,你想原子就原子,你想质子就质子
|
16
firebroo OP @feverzsj 数据库场景不合适,十几个 G 数据全量变化更新,不然我就不把数据放内存里面了,再次也用 redis 这种内存数据库,测试 redis 没满足性能需要
|
17
lihongjie0209 2018-11-08 19:09:53 +08:00
重新发明一个数据库
|
18
feverzsj 2018-11-08 19:14:07 +08:00
@firebroo 了解,你原来根本搞不清楚问题在哪,写入完整性本来就是依赖副本交换实现的,十几 G 根本不算大,sqlite 完全能胜任
|
19
429839446 2018-11-08 19:15:34 +08:00 via Android
可以看微信开源的 mmkv ?
|
20
firebroo OP @feverzsj 你没测试就说可以胜任我的场景,我说的是数据有完整性,不能单一的一条条更新,必须整体更新,不是写入完整性。
|
23
xylophone21 2018-11-08 19:47:34 +08:00
@muntoya 说到问题的关键了,但感觉楼主还在一些不重要的细枝末节上出不来,或者没找到重点,不解释。
|
24
firebroo OP @feverzsj 我讨论 redis 这种内存数据库是如何实现安全持久化内存数据到磁盘的,然后自己实现个类似的,你让我把这种事情交给 redis 去搞,你是扛精。。?
|
25
feverzsj 2018-11-08 19:53:15 +08:00
@firebroo 我根本没提过 redis,你说说你想实现的东西,有什么不能用 sqlite 实现的? sqlite 能在保证事务性的基础上达到良好的 io 效率,你自己用标注库 io 能做到?
|
26
firebroo OP @feverzsj redis 和 sqlite 有差吗,就是把这件事交给数据库去完成,某些场景确实需要,不然微信为啥有 mmkv 这种轮子不用 sqlite
|
27
feverzsj 2018-11-08 20:03:31 +08:00
@firebroo mmkv 是非常低层次的 kvstore,根本不管你数据死活,sqlite 是完整的关系型数据库,根本不是一个层面的
|
28
liuxu 2018-11-08 20:10:16 +08:00
能不能写到 ramdisk 呢,然后一个线程定期刷到硬盘呢,记录好日志,这样进程即使死了 ramdisk 数据依然不会丢失,重启进程分析日志继续写入到硬盘
|
30
firebroo OP @xylophone21 科普一下,我确实没有看懂 3 楼回复,redis 的实现没看过
|
31
firebroo OP @muntoya
@xylophone21 原来是你好像真的没看懂问题是啥。。我刚去翻了下 redis 持久化的源码 ```c /* Use RENAME to make sure the DB file is changed atomically only * if the generate DB file is ok. */ if (rename(tmpfile,filename) == -1) { serverLog(LL_WARNING,"Error moving temp append only file on the final destination: %s", strerror(errno)); unlink(tmpfile); return C_ERR; } ``` |
32
msg7086 2018-11-09 09:11:26 +08:00
没看懂问题是啥。
写临时文件然后 rename 算是基本操作,rsync 之类的软件也是这么跑的。 值得注意的是你这里写完临时文件以后需要 flush 一下底层的文件系统,确保文件内容已经刷入磁盘了,再 rename 比较好。 |
34
firebroo OP @msg7086 我 rename 之前已经 close 了 tmp 文件,会自动 flush 吧
|
38
firebroo OP @msg7086 fflush:是把 C 库中的缓冲调用 write 函数写到磁盘[其实是写到内核的缓冲区]。fsync:是把内核缓冲刷到磁盘上。 这个吧?学习了。
|
39
no1xsyzy 2018-11-09 11:10:27 +08:00
@firebroo #31 https://github.com/antirez/redis/blob/2f8f29aa0e63a198aa628296ce617214b3ae1575/src/aof.c#L1540
Redis 实现 rewriteAppendOnlyFileBackground() 的时候用了 fork() 而在子进程中断开监听端口,调用 rewriteAppendOnlyFile() 进行写入。 不过 Redis 是单线程的,多线程的话 fork 要处理锁,因为这时候系铃人可能消失了,解不了铃。 |
40
no1xsyzy 2018-11-09 11:21:11 +08:00
@firebroo #14 全量写入也可以追加文件末尾啊,虽然又碰上数据量过大的问题了。有没有想过上磁带?
或者保证只有 2 份文件存在。写 A 不碰 B,写 B 不碰 A。 |
42
no1xsyzy 2018-11-09 16:04:31 +08:00
@firebroo 磁带+RAID 0,单位容量价格极低,顺序读写速度堪比 SSD,缺点是基本只能顺序,随机查找 IOPS 极低,但你这个情景用磁带做持久,之后用磁带还原状态,也就顺序……要是 VPS 上跑就当我没说
|
44
pythonCoder 2018-11-12 13:38:00 +08:00
爬山心得
|