不要老想着重构｜Devlog · 12

发布于：12/03/2025 15:14:27 · #devlog

最近 Solar Network 服务器爆炸的越来越频繁，原因竟是羊闲的没事在重构缓存模块。

缓存如今是 Solar Network 业务的核心一块，不仅是 Solar Network，几乎所有互联网厂商的快速都依赖于高缓存覆盖率，为了进一步提升效率，羊发表重大社论「服务器的缓存一定要能缓存」

于是，一场轰轰烈烈的由 GPT 5 Codex High 领导的缓存重构开始了……

Commits on Dec.png

后面省略 20 多个修复新缓存系统的 commits

所以，新缓存改了什么？

  1. 使用 MessagePack 代替 JSON 来做序列化
  2. 使用 RedLock 来代替自己实现的 Redis-based Distributed Lock
  3. 使用微软的 IDistributedCache 接口重新规范缓存 CacheService 的设计，提升效能

总体上来说本次行动还是是很成功的，至少代码整洁了不少，不过 MessagePack 的替换确实是一大败笔，这也是导致最近多次 500 的罪魁祸首。

CSharp 的 MessagePack 没有像 JSON.NET 和 System.Text.Json 那么完善的测试，面对 EF Core 这个天才设计的无限回环应用直接 Stackoverflow，而且似乎 C# MessagePack 的作者没考虑到这个因素，不像 JSON 解析库自身外部有一个限制，MsgPack 直接让 dotnet 抛出了 Stackoverflow 的异常，导致服务终端，docker 重启。

后来对 MsgPack 的 Serializer 进行了大量改进，确实可用了，但是面对 Upload Task 这种复杂的结构体 (Class 里面套 Dictionary 再套 Class) 就显得力不从心，于是果断扑街，造成一系列上传文件的问题。

所以本次事件的主要原因是犯了高傲之罪的 MessagePack for C#，仗着自己性能好就在为所欲为，实际上鲁棒性非常不好，遂将其打入冷宫，换回 JSON

其次命名缓存工作的好好的，非要重构，也是造成这次事故的一大原因，并且测试不完善就推送服务器更新的开发习惯也不好。但是永远伟大、光荣、正确的羊是不会犯错的，所以错的是 GitHub Actions 没有测试出来这种潜在的问题，嗯对。