还记得那是一个令人窒息的下午，大促刚刚开启没多久，监控大屏上的流量曲线突然断崖式下跌，紧接着就是一片刺眼的红——系统彻底崩了。这不是某个接口响应慢那么简单，而是整个核心交易链路陷入了长达半个多小时的瘫痪。用户们打开APP，面对的是一片空白，什么也干不了既kan不了商品，也下不了单，geng别提支付了。

事后复盘时CEO的那句话至今还在我耳边回响：“公司砸了那么多真金白银Zuo广告预热，结果就换来这么个烂摊子？”那一刻，技术团队的压力可想而知。这不仅仅是一次技术事故，geng是一次对旧有技术架构的“宣战”。也就是从那时起，我们意识到，修修补补Yi经没用了必须来一场彻底的技术革命。

说实话，那时候公司的核心业务系统，从商品、库存到订单、支付，清一色全是PHP写的。在业务规模还没起来的时候，PHP开发快、部署方便，确实是把利器。但随着用户量滚雪球般增长，业务需求也变得越来越刁钻，PHP的短板就开始暴露无遗了。

Zui让人头疼的是PHP-FPM的运行机制。大家dou知道，PHP-FPM是典型的“每个请求一个独立Worker进程”的模式。这意味着什么？意味着进程之间内存是不共享的。你Neng开多少个Worker进程，直接就框死了你系统的并发上限。一旦进程数上去了操作系统在进程上下文切换上的开销就会变得非常夸张，吞吐量不升反降，就像一辆开到极速的车，引擎Yi经开始冒烟了。

还有一个hen现实的问题：招人。当时市面上优秀的Java工程师一抓一大把，但资深PHP的高手却凤毛麟角。用PHP去维护一个承载亿级用户流量的核心系统，人才池子太小了人员风险极高。这就像是用造自行车的材料去造飞机，勉强Neng飞，但随时可Neng散架。

商品系统的数据量级当时Yi经到了十几亿，而且还在持续膨胀。在PHP架构下因为进程间内存不共享，我们根本没法在JVM层面Zuo高效的本地缓存。每个请求要么硬着头皮去查数据库，要么走Redis这类外部缓存。这带来的直接后果就是网络IO成了巨大的瓶颈。而Java应用就不一样，它Ke以把热数据直接加载到堆内内存，同一个JVM里的所有请求douNeng直接读取，速度不可同日而语。

特别是到了大促期间，流量模式会发生剧烈变化。平时流量虽然也不低，但大促开始的那一瞬间，用户会像潮水一样从收藏夹涌入商品详情页。这就是所谓的“流量脉冲”。在32台机器上，我们要面对的是瞬间爆发的70万并发读请求。这种时候，PHP那种每次dou要绕一圈网络去取数据的模式，根本扛不住。

痛定思痛，CTO拍板决定：用Java重构所有核心系统。但这事儿说起来容易Zuo起来难。重构和从零开始新建系统完全是两个概念。新建系统你Ke以天马行空，但重构是在不影响存量业务的前提下把底层给换了。这就好比给一辆正在高速行驶的汽车换引擎，既不Neng停车，也不Neng翻车。

约束条件非常苛刻：不Neng停服、数据不Neng丢、要Neng随时回滚、调用方必须无感切换。这些约束叠加在一起，技术方案的复杂度呈指数级上升。为此，公司专门成立了一个重构部门，从各处挖来了不少在高并发、大数据量场景下摸爬滚打过的技术专家。数据架构师负责新模型，业务架构师负责领域拆分，基础架构师负责中间件，各路神仙齐聚一堂。

在动手写代码之前，我们先得把商品系统在业务上的定位搞清楚。从技术视角kan，公司的电商业务Ke以划分为三条主线：

第一条是选购线。 这是流量的入口，用户浏览、搜索、kan详情、收藏，dou在这条线上。商品系统和库存系统是这条线的核心。

第二条是下单支付线。 用户从购物车发起下单，选支付方式，完成支付。订单系统和支付系统是这里的C位。

第三条是用户营销会员线。 涉及注册、登录、积分、优惠券等。

而商品系统，作为Zui底层的基础数据服务，几乎被所有面向C端的业务系统所依赖。首页、搜索、商详页、购物车、下单、收藏夹、推荐……这些系统dou要从商品系统读数据。平时流量就不小，一到搞活动，商品域的流量在全公司绝对是排第一的。

旧的商品表是典型的PHP宽表结构。这种结构在业务简单时hen直观，但随着运营需求的频繁变geng，它的弊端就显现出来了。运营人员经常要新增各种销售属性，比如“是否爆款”、“是否支持某类折扣”、“适用人群标签”等等。在宽表模式下每加一个属性就得DDL加一列，还得走DBA审核、选低峰期执行、验证数据，流程繁琐得让人想哭。

为了解决这个问题，重构后我们采用了EAV模型。简单来说就是把每个属性变成表里的一行记录，而不是一列。记录里包含属性名称、类型、值等元数据。这样一来运营想加新属性，只需要插入一条新记录就行，完全不需要改表结构。虽然这会让查询和代码层面的复杂度增加——查一个商品得聚合多行记录，参数校验也得先读元数据——但为了灵活性，这个代价是值得的。

商品系统的流量特征非常明显：读多写少。C端用户只kan不改，写操作全靠运营后台，量hen小。但读流量有两个大坑：一是全天候持续不断，不像秒杀有明确的时间窗口；二是大促时的流量脉冲。面对这种场景，缓存体系的设计就是生死的关键。

我们设计了一套完整的三级缓存体系：

第一级是本地缓存：OHC。 商品数据体量有好几个G，Ru果全放在JVM堆内，会严重影响GC，导致停顿。所以我们选择了OHC，把数据存在JVM堆外的直接内存中。这部分内存不参与GC扫描，虽然需要自己处理序列化和反序列化，但极大地减少了GC停顿时间。每种商品数据类型dou有独立的Loader，保证了加载效率。

第二级是中央缓存：Redis。 本地缓存没命中的请求，会去查Redis。这里面的学问就多了Key怎么命名才不冲突？过期策略怎么定？大Value怎么拆分？怎么防缓存穿透、防击穿？特别是那些热Key，必须要有专门的处理机制，否则hen容易把Redis打挂。

第三级才是数据源：MySQL。 这是Zui后一道防线。

这三层之间的加载、geng新、失效策略必须形成一个闭环。比如运营刚修改了商品信息，怎么保证各层缓存的一致性？这就涉及到预热策略、过期geng新以及专门的主从延迟处理方案。

除了缓存，我们在流量治理和API设计上也下了不少功夫。

我们把C端读服务和运营后台写服务彻底分开部署。读服务Ke以独立扩容，完全不受写操作的影响。数据库层面也采用了一主多从，读请求分散到多个从库。当然主从同步带来的延迟问题，我们也通过业务层面的妥协或技术手段进行了规避。

geng重要的是流量隔离。大促开始那瞬间的流量太恐怖了Ru果让大促流量和日常浏览走同一条链路，正常请求肯定会被挤死。所以我们在流量层面Zuo了物理隔离，大促流量有专门的通道，互不干扰。

商品系统被七八个业务系统调用，每个调用方想要的数据dou不一样。Ru果给每个调用方定制一个接口，接口数量会爆炸；Ru果提供一个全量接口，又会传输大量无用数据，浪费带宽。

我们的解决方案是让调用方在请求时声明自己需要哪些字段，系统按需组装返回。这种设计虽然增加了后端的组装复杂度，但极大地提升了网络传输效率和接口的通用性。

Zui后也是Zui难的一环：如何把这套新系统上线，还不Neng出岔子？

我们制定了严格的“平滑迁移”策略。不Neng停服务直接割接，必须走双写、灰度、回滚的完整流程。在hen长一段时间里新旧系统是并存的，数据同时写入两边。然后通过切流工具，一点点把流量从旧系统切到新系统。一旦发现异常，立刻回滚。这期间，大家的心dou是悬着的，直到Zui后全量切换成功，kan到监控指标平稳，才敢松一口气。

回顾这次重构，从PHP到Java，从宽表到EAV，从简单缓存到多级缓存体系，每一步dou不是为了炫技，而是为了解决那个特定业务规模下的特定痛点。技术方案从来不是凭空设计出来的，它们dou是从需求和约束条件里一点点推导出来的。

如今面对百万级并发的挑战，我们不再像当年那样手足无措。系统稳了业务才Neng跑得快。这大概就是技术人Zui大的成就感所在吧。