阅读服务器的文件系统并非随意堆砌,而是围绕“用户隔离、资源共享、可扩展维护”三大原则精心布局的。把握住每一级目录的职责,才能在日常运维、故障排查乃至容量规划时从容应对。
根目录下唯一的 storage 文件夹充当所有业务数据的根基,内部划分为 assets、cache、data、localStore 四大子目录。
当 reader.app.secure 为 false 时,所有用户共用 data/default;开启安全模式后,每个用户名对应 data/<username>,实现数据完全隔离。每个用户目录下必备三类文件:
bookSource.json:该用户可用的书源列表,支持本地编辑与远程同步。bookshelf.json:书架元数据,记录书名、来源、最近阅读进度。<hash> 为书源标识,内部保存 <hash>.json 目录结构。缓存层采用两级策略:cache/bookInfoCache 缓存搜索结果,cache/ 根目录直接存放封面图片等二进制文件。为防止磁盘膨胀,阅读服务器默认开启 30 天自动清理,且提供 autoClearInactiveUser 参数可按用户活跃度回收孤立缓存。
WebDAV 与 MongoDB 双向备份是官方推荐的容灾方案。WebDAV 负责 data/<username>/webdav 目录的完整快照,MongoDB 则同步 bookshelf.json 与 bookSource.json 的结构化数据。恢复时,只需将对应用户的 WebDAV 包重新上传,系统会自动重建章节缓存。
cache 与 data 分别挂载在不同的分区,以降低读写竞争。reader.app.secure 并限制 userLimit,可有效抑制恶意爬虫导致的磁盘耗尽。掌握这些细节后,阅读服务器的扩容、迁移乃至故障恢复都不再是“黑盒”。只要目录结构保持清晰、备份策略落到实处,后端的可用性自然稳如磐石。
参与讨论
这配置文档写得挺清楚,照着整了一遍没踩坑。
data目录分用户隔离确实方便管理,我们这边已经上线了。
cache自动清理是按最后访问时间算的吗?求问
localStore能多个用户共用书仓,但怎么控制权限啊?
我之前也搞过类似结构,结果backup没弄好直接GG了😭
说的有道理,不过SSD挂载目录这块能不能再展开讲讲?
这玩意儿文档比代码还长,看得头大。
章节缓存用哈希命名虽然防冲突,但调试起来真够呛。
autoClearInactiveUser这个参数有没有实际运行的示例?