Lobsters项目优化：使用SQLite替代文件存储提升Rack-Attack性能

在Web应用开发中，速率限制和基本WAF功能是保护系统免受恶意请求的重要手段。Lobsters项目使用Rack-Attack中间件来实现这些功能，但原有实现存在性能瓶颈需要优化。

原有架构的问题

项目最初配置Rack-Attack使用Rails默认的文件存储作为缓存后端。这种实现方式会产生数十万个小文件，当遇到流量激增时，文件过期清理操作会导致明显的性能下降。小文件I/O操作频繁，不仅占用大量inode资源，还会增加文件系统维护开销。

解决方案：迁移到SQLite存储

团队决定采用SolidCache作为新的存储后端，这是一个基于SQLite的缓存解决方案。相比文件存储，SQLite具有以下优势：

1. 所有缓存数据存储在单个数据库文件中，减少文件系统压力
2. 事务支持确保数据一致性
3. 成熟的索引机制提高查询效率
4. 自动维护机制简化管理工作

实施细节

迁移过程主要涉及以下配置变更：

1. 在database.yml中新增专门用于缓存的SQLite数据库配置
2. 修改Rack-Attack初始化代码，指定使用新的缓存存储
3. 创建专用的SQLite数据库文件（如/srv/lobste.rs/cache/cache.sqlite3）

值得注意的是，这种变更需要完全重启Puma服务器才能生效，简单的配置重载（reload）不足以使中间件切换到新的存储后端。

经验总结

通过这次优化，团队获得了以下经验：

1. 缓存存储的选择对系统性能有显著影响
2. 从文件存储迁移到数据库存储需要仔细验证数据迁移过程
3. 中间件配置变更有时需要完全重启服务才能生效
4. SQLite作为轻量级数据库，非常适合这类缓存场景

这种优化不仅解决了性能问题，还为系统未来的扩展提供了更好的基础架构支持。SQLite的稳定性和可靠性将使Rack-Attack在高压环境下表现更加出色。