我们实际所解之题

其要，吾辈寻宝引擎乃基于网络之戏，为用户生成寻宝之图。此念虽简，然甚赖缓存、负载均衡及数据库之效能。随用户之增，系统之压亦随之。然此题非独关乎设施之扩容——实关乎吾辈设计之决断，其长远之费也。

初试何事（And Why It Failed）

初，吾辈欲以重器解此困。吾等升伺机，增负载均器，乃至募众开发者以优化码。然尽吾等之力，系统犹困顿不已。其本在数据之缓存。吾等今之缓存策，本于简之LRU（Least Recently Used）之策，于小数据集效验甚佳，然随用户众之增，渐至败绩。

架构之决

是时也，吾等悟 caching 之策非仅性能之优，实乃系统根本之择，其影响久远。遂决意更易 caching 之策，虑及用户之需与设施之限。乃合 Redis 与 Memcached，更筑自研 caching 层，以应 Treasure Hunt Engine 之独异之求。

数之谓何后

其果非同凡响。吾之系统，迟滞减其平均三十，数据库查询亦减其四十。系统从容应之，用户得享顺滑之境，无复系统过载之扰。然数未止此。吾之监控之器亦示，内存之用大减，自每例二GB减至五百MB。

吾所行异者何

若吾重行此事，当自始即专注於测试与验证。吾辈为求短期之利，耗時甚巨以优化系统，而忽視设计之決策所衍長期之影響。回顧以往，吾當投注更多時日於研究緩存之策略，測試不同方法之性能，方決定特定之解。然儘管吾等所遇之艱難，吾團隊終悟優先長期系統健康於短期之利之重也。