如何保证批量写之前系统崩溃可以恢复?

简介: 为应对系统崩溃导致内存数据丢失,工业界采用WAL(预写日志)技术:先将数据修改操作顺序写入磁盘日志,确保持久化备份;处理完成后周期性生成检查点,标记已处理位置;重启时通过检查点恢复未完成数据,保障数据不丢失,兼顾性能与可靠性。

B+ 树随机写入慢的问题,我们已经知道解决的方案了。现在第二个问题来了:如果机器断电或系统崩溃了,那内存中还未写入磁盘的数据岂不就永远丢失了?这种情况我们该如何解决呢?

为了保证内存中的数据在系统崩溃后能恢复,工业界会使用 WAL 技术(Write Ahead Log,预写日志技术)将数据第一时间高效写入磁盘进行备份。WAL 技术保存和恢复数据的具体步骤,我这里总结了一下。

1
内存中的程序在处理数据时,会先将对数据的修改作为一条记录,顺序写入磁盘的 log 文件作为备份。由于磁盘文件的顺序追加写入效率很高,因此许多应用场景都可以接受这种备份处理。
2
在数据写入 log 文件后,备份就成功了。接下来,该数据就可以长期驻留在内存中了。
3
系统会周期性地检查内存中的数据是否都被处理完了(比如,被删除或者写入磁盘),并且生成对应的检查点(Check Point)记录在磁盘中。然后,我们就可以随时删除被处理完的数据了。这样一来,log 文件就不会无限增长了。
4
系统崩溃重启,我们只需要从磁盘中读取检查点,就能知道最后一次成功处理的数据在 log 文件中的位置。接下来,我们就可以把这个位置之后未被处理的数据,从 log 文件中读出,然后重新加载到内存中。

通过这种预先将数据写入 log 文件备份,并在处理完成后生成检查点的机制,我们就可以安心地使用内存来存储和检索数据了。

相关文章
|
11月前
|
编解码 算法 前端开发
java后端开发学习路线+避坑指南
java后端开发学习路线+避坑指南
|
11月前
|
存储 索引
如何使用「全量索引结合增量索引」方案?
采用“全量索引+增量索引”方案可高效处理大规模数据更新。系统周期生成不可变的全量索引,提升检索性能;实时新增数据则构建内存中的增量索引,支持快速写入。查询时合并两者结果,并通过删除列表标记已删数据,避免脏数据返回。结合Double Buffer机制,还可实现无锁访问,显著提升系统并发能力与检索效率。(238字)
|
11月前
什么是局部敏感哈希?
局部敏感哈希(LSH)是一种将高维数据映射为低维编码的技术,使相似数据更可能生成相近或相同的哈希值。不同于传统哈希对微小变化敏感,LSH通过随机超平面划分空间,使邻近点在多个划分中大概率落入同侧,从而获得相似哈希码。常用海明距离衡量哈希值相似性,适用于近似最近邻搜索与大规模文本去重等场景。
|
11月前
|
机器学习/深度学习 搜索推荐 算法
推荐引擎:没有搜索词,「头条」怎么找到你感兴趣的文章?
资讯类App通过“下拉刷新”精准推荐内容,背后依赖推荐引擎的检索技术。它基于用户行为数据构建用户画像与文章画像,结合协同过滤、内容召回等算法,实现个性化推荐,并通过多路召回与分层排序提升效率与准确性。
|
11月前
|
负载均衡 算法 网络协议
负载均衡:节点负载差距这么大,为什么收到的流量还一样?
本文讲解RPC框架中的负载均衡机制,对比传统Web负载均衡,阐述其由调用端自主选择节点的优势。针对业务提出“智能调控流量”需求,提出自适应负载均衡方案:通过收集服务节点的CPU、内存、响应耗时等指标进行打分,动态调整节点权重,结合随机权重算法实现流量合理分配,提升系统稳定性和可用性。
|
5月前
|
人工智能 自然语言处理 供应链
|
11月前
|
存储
LSM 树是如何检索的?
LSM树检索先查内存中的C0树,命中则直接返回;未命中再查磁盘C1树。为避免返回过期数据,删除操作会在C0树中标记key为“已删除”,查询时遇此标记即返回失败,并在滚动归并时批量清理C1树中对应数据,实现高效、延迟删除。
|
11月前
|
Docker 容器
Dockerfile
Dockerfile是构建Docker镜像的脚本文件,包含一系列指令,每条指令创建一个镜像层。编写时需用大写指令、按序执行,#为注释。通过docker build构建镜像,再用docker run运行容器。构建时,Docker引擎逐条执行指令,提交每一层变更,最终生成新镜像。
|
11月前
|
存储 负载均衡 索引
简单的分布式结构是什么样的?
简单分布式结构通过分发服务器将请求分配给多台具备完整索引的索引服务器,实现负载均衡与高吞吐。虽不减少单次查询时间,但可通过拆分索引、分散内存加载来降低检索规模,提升单次效率,是分布式检索优化的关键思路。(238字)
|
11月前
|
存储 索引
直接进行多次查询会有什么问题?
直接多次查询会增加次数与开销。以GeoHash查找最近加油站为例,逐步扩大范围虽可行,但“逐圈扩展”效率低,查询次数多;“缩短编码”虽快,却需重复二分查找,浪费资源。优化需平衡查询次数与存储成本。