在当今互联网应用中，缓存技术已成为提升系统性能和吞吐能力的关键工具。几乎所有开发框架都对缓存服务提供了原生支持，启动Redis或Memcached实例，仅需简单配置即可集成。然而，当业务规模增长到一定程度时，单一缓存实例的瓶颈便会逐渐显现，如何有效扩展缓存能力成为亟待解决的问题。7shifts作为一家致力于改善餐厅团队管理体验的科技公司，在2023年的高速发展阶段，也面临着Redis扩展的挑战并付诸实践，本文将详尽介绍其扩展Redis缓存的全过程及宝贵经验。 起步阶段，简洁架构为核心价值 7shifts在初创阶段并未采用应用缓存架构，所有数据操作均依赖数据库完成，包括会话数据等。这样的设计让系统架构异常简洁，对当时的业务负载来说完全可行。
数据库的扩容策略也通过提升资源硬件的形式满足了早期增长需求。然而，以数据库扩容为单一手段，面对不断增长的访问压力，显然难以长期支撑，服务的响应性能和扩展空间受到限制。 首次引入Redis缓存后，7shifts将高成本查询的模型数据纳入Redis缓存，减少对数据库的直接压力同时提升了应用响应速度。此时搭配的架构是在数据库写入的同时同步更新Redis缓存，典型的读写缓存协作模式，显著优化了性能表现。 连接数激增下的架构困境 虽然缓存的引入带来明显好处，但伴随着应用规模的增长，出现了新的瓶颈。7shifts使用的是单体PHP应用，应用每个请求都会建立并关闭与Redis的连接。
在规模较小时这种连接开销不大，但随着请求量攀升及高并发场景出现，这种“开-关”连接模式对Redis带来了沉重负担，系统延迟开始与Redis连接数呈正相关。 为此，团队快速找到了引入连接代理或连接池的解决方案。通过保持一组持久连接，代理降低了频繁建立连接带来的开销。7shifts最终选用了Twemproxy作为中间层，成功显著降低了Redis直接连接数，改善了延迟和系统负载，架构变得更加稳健。 随着用户量激增，单实例Redis已不堪重负 到了2023年夏季，7shifts用户快速增加，数据库CPU资源利用率攀升至90%以上，升级数据库硬件空间已接近极限。拆分数据库服务虽可以缓解压力，但复杂性和成本高昂。
团队决定从增加缓存数据入手，令更多频繁访问的数据模型纳入Redis缓存。 出乎意料的是，新增缓存后整体延迟却有所升高。细致的监控数据显示，虽然Redis内存使用充足，但CPU资源早已超负荷，导致请求排队。Redis的单线程特性使得通过增加更大实例来扩容存在天花板。7shifts团队意识到需要对缓存架构进行本质上的重新设计。 Redis扩展的多重方案权衡 初步调研中，Redis Cluster方案因其自动数据分片特性成为首选，但由于7shifts基于Google Cloud Platform（GCP）的MemoryStore部署，且当时GCP尚不支持Redis Cluster，故被暂时搁置。
读副本方案也是GCP提供的服务，但这需要客户端或应用层具备更复杂的连接逻辑，影响开发者体验和系统简洁性。 团队转而考虑手动分片设计，开始着手配置多Redis实例，暂存不同数据分区。但直接将分片逻辑放在应用层仍然增加复杂度。偶然间，团队发现Envoy代理支持客户端分片（Client-side Sharding），能够将分片负担下沉至代理层，这样应用无需感知分片细节，开发者体验保持简洁，基础设施团队亦更好掌控扩容策略。 Envoy的引入及性能革新 首先，7shifts将原有的Twemproxy替换为Envoy作为代理层。Envoy不仅承担连接池功能，更支持丰富的路由和分片配置。
这次替换带来了出乎意料的收益，Redis实例CPU占用率显著下降，应用延迟同步降低，客户体验有明显提升。 随后，7shifts开始构建多实例Redis集群，Envoy配置成分片代理，将缓存请求按策略分发到多个Redis节点。为保证数据完整性，团队采用请求镜像功能，实现双写机制，确保数据逐步同步到新架构中，实现平滑切换。 分片挑战及热键问题的应对 分片后，监控数据显示不同分片Redis实例间CPU使用率分布不均。进一步调查发现，部分热点Key集中落于个别节点，造成负载不均衡现象。借助Redis命令行工具的--hotkeys功能，7shifts识别出多条高访问频率的Key。
针对该问题，团队在应用层定义“高频Key”策略，通过在Key前缀添加特殊标识（如HIGH_FREQ_）引导Envoy做特殊分发。高频Key在写入时以广播方式写入所有Redis分片，读取时采取轮询访问，均衡了负载，避免单个节点过载，有效解决了热点Key带来的性能瓶颈。 经验总结与未来展望 7shifts的Redis扩展之路是一段充满挑战与创新的过程。起初的无缓存架构因简单直接而实用，伴随着业务增长逐步引入缓存，解决数据库压力，再面对连接数爆表、单实例CPU瓶颈，积极探索代理池和分片策略。Envoy代理的引入成为关键转折点，使缓存系统获得了质的提升。针对热点数据的不均衡访问，定义应用侧高频Key策略，完善了分片架构的负载均衡。
整个过程不仅是技术调优的体现，也显示了架构灵活应变的能力。7shifts的经验有助于其他同样面临缓存扩展瓶颈的团队借鉴，实现性能与成本的平衡。展望未来，随着GCP对Redis Cluster与更多分布式缓存模式的支持持续完善，7shifts也将持续优化缓存体系，以支持更大规模与更高稳定性的餐厅管理服务。 从7shifts的案例可以看出，缓存扩展不仅是技术选型的赛道，更是设计思想的较量。低耦合、高透明的分片设计和代理层解耦策略，是企业稳定、高效扩展核心存储服务的关键。对于希望通过缓存提升应用性能的开发者和架构师而言，7shifts的实践无疑提供了宝贵的参考和启示。
。
