这是一个创建于 2205 天前的主题，其中的信息可能已经有所发展或是发生改变。
问题
最近一个项目，对计算效率时实性要求比较高，我把所有数据都放到内存里面操作计算，这个时候如果进程被意外终止（人为 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;
}
第 1 条附言 · 2018-11-09 14:53:46 +08:00
经过大神指点，参考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
爬山心得
|
Select Language