修改快照和容错的设计，使其更河里

design.md

@@ -1,9 +1,9 @@
 # 规划的Bonus实现方式
 - 缓存：LRU
 - 空间回收
-- 快照：贯通于数据库系统和火车票系统整体，而是直接针对整个数据文件夹打快照（类似于git，在火车票系统后端处于非活动状态时操作，比对工作文件夹和版本库中的最后一次commit，然后打一个新的commit进去），额外消耗空间为压缩后的 当前文件实际大小+变化量，使用zstd算法压缩。交互方式：`./core-cli snapshot [options]`
+- 快照：贯通于数据库系统和火车票系统整体，以文件为单位夹打快照（类似于git，在火车票系统后端处于非活动状态时操作，比对stage区和版本库中的最后一次commit，然后打一个新的commit进去），额外消耗空间为 当前文件实际大小 + 压缩后的 当前文件实际大小+变化量，使用zstd算法压缩。交互方式：`./core-cli snapshot [options]`。而stage功能内置于DiskManager，当收到信号后，会把工作文件夹的变化打进stage区。
-- 并发：内置于数据库系统，基于`std::shared_mutex`的简单并发。（但火车票系统会直接在整个业务层面上读写锁，因此不会直接使用数据库系统的并发安全）。
+- 并发：内置于数据库系统，基于`std::shared_mutex`的简单并发，可以真正意义上支持读操作的并发，但写操作会独占数据库的控制权。（但火车票系统会直接在整个业务层面上加读写锁，因此不会直接使用数据库系统的并发安全）。
-- 容错：不内置于数据库系统，由火车票系统针对实际业务逻辑记录日志。在文件系统层级上修复完损伤后，运行`./core-cli fsck`检查是否有可能有损坏，借助快照系统修复可能的损伤。
+- 容错：不内置于数据库系统，由火车票系统针对实际业务逻辑记录日志。在文件系统层级上修复完损伤后，运行`./core-cli fsck`检查是否有可能有损坏，借助快照系统和日志修复可能的损伤。具体而言，每条指令视为一个事务，每隔1e3~1e4个事务之后，Flush数据库，调用快照系统，把数据库文件塞进stage区域（直接由DiskManager异步完成，不会阻塞数据库运行），并在事务日志里记录“截至当前已存档”。当需要修复时，先借助快照系统恢复到最近的快照（或从stage区恢复），然后把未反映进该checkpoint的数量较少的事务再重新操作一下（考虑到后端的执行速率，重新执行1e3到1e4个事务的代价是可以接受的）。此时，恢复的即时性就由新增事务多长时间内会实际存入磁盘决定，单独开启一个线程，以最快的可能速度往某个单独的日志文件末尾追加。
 - 前端：一个使用正经框架写的简洁美观的UI，无响应式设计。
 
 ## 快照系统