夜雨聆风这不是一份产品经理写的功能需求文档。商品系统的重构需求来自技术团队，触发原因是一次大促事故。重构的范围不只是商品系统，而是公司所有核心系统从PHP到Java的整体迁移。后续的每一个技术方案，都要回到这份文档里找依据。
文档概要
需求背景
业务现状
公司是一家几亿用户规模的互联网公司，业务覆盖多个C端渠道。当时所有核心系统都是PHP实现的，商品、库存、订单、支付、用户、营销，全部是PHP。
商品系统是公司最底层的基础数据服务。首页、搜索、商详页、购物车、下单、收藏夹、推荐，几乎所有面向C端用户的业务系统都从商品系统读取数据。平时流量就不小，一到大促，商品域的流量在整个公司排第一。
PHP时期的商品系统，日常流量下能用，瓶颈已经很明显了。
触发事件
某一年的大促活动，系统直接瘫痪了。
不是某个接口响应慢、某个页面打不开，是核心交易链路整体不可用，持续了半个多小时。用户打开APP什么都干不了，不能浏览商品，不能下单，不能支付。
公司为这场大促投了大量广告费做预热和推广。活动还没开始多久，系统就挂了。CEO说了一句话：公司花了那么多广告费来做这场大促，结果没取得预期的效果。
这次事故的直接后果：
• 大促期间的预期营收目标没有达成 • 大量用户涌入后遇到系统不可用，用户体验严重受损 • 运营团队此后对大规模活动持谨慎态度，不敢轻易放量 • 技术团队事后复盘确认：PHP系统在架构层面已经无法承载当前的业务规模
重构决策
那场事故之后，CTO做了一个决定：用Java重构公司所有核心系统。
这不是修修补补式的优化，是一次彻底的技术革命。
CTO成立了一个专门的重构部门，50号人，从业界挖了不少在高并发、大数据量场景下有实战经验的技术专家。各路架构师全部上场：数据架构师负责新的数据模型设计，业务架构师负责业务领域的拆分和梳理，基础架构师负责中间件和基础设施的选型与搭建。
新的业务需求基本暂停了，所有技术资源集中在重构上。从立项到核心系统全部切换到Java，耗时差不多一年。
重构全景
公司整体的「电商」业务从技术视角可以划分为三条线。
选购线。 用户浏览、搜索、查看商品详情、收藏的完整链路。商品系统和库存系统是这条线的核心。
下单支付线。 用户从购物车发起下单、选择支付方式、完成支付的完整链路。订单系统和支付系统是这条线的核心。
用户营销会员线。 用户注册、登录、会员等级、积分、优惠券、营销活动等。用户系统和营销系统是这条线的核心。
三条线不是完全独立的。下单需要读取商品数据（名称、价格、库存），营销活动需要关联商品信息。商品系统作为基础数据源，被其他两条线的多个系统依赖。
我当时在重构部，负责选购线中的商品系统和库存系统的重构。这个专栏聚焦商品系统，库存系统的重构不在范围内。
商品系统的重构范围：
• 商品数据模型重新设计（从PHP的宽表迁移到EAV模型） • C端商品读服务全量重写 • 多级缓存体系建设（OHC堆外缓存 + Redis中央缓存） • 读接口API重新设计 • 十几亿条商品数据的迁移 • 灰度上线和数据质检
商品系统的业务职责
在讲技术问题之前，先把商品系统在业务上干的事情说清楚。
商品系统管理的是公司所有在售商品的基础数据。这些数据对C端用户是只读的，由运营人员在后台维护。C端用户通过各种入口浏览和查询商品信息，不会修改数据。
调用方
开篇词里提过，商品系统被公司几乎所有C端业务系统依赖。具体的调用方和各自需要的数据：
不同调用方需要的字段差异很大。这个特征直接影响了后面读接口的API设计方式。
数据类型
商品系统管理的数据分三类。
基础信息。 商品名称、描述、图片、分类、品牌。创建后很少修改。
销售属性。 运营会频繁新增的字段：是否爆款、是否支持某种折扣、是否在特定频道展示、适用人群标签。这类属性的特点是数量不固定，运营每隔一段时间就会提需求要加新的属性。
价格与状态。 价格、上下架状态、可售渠道。修改频率中等，对一致性要求高。
流量特征
商品系统的流量模式是读多写少。C端用户只读不写，写操作来自运营后台，量很小。读流量有两个特征。
日常流量持续且不低。 不像秒杀系统有明确的时间窗口，商品数据的读取是全天候的。任何时候用户打开APP、浏览商品、搜索，都在读商品数据。
大促期间出现明显的流量脉冲。 用户提前收藏商品，活动一开始从收藏夹涌入商品详情页，短时间内集中读取同一批商品。开篇词里提过的峰值数据：32台机器上的70万并发读请求。
现有PHP系统的问题
重构不是因为PHP这个语言有问题，是因为当时的PHP系统在那个业务规模下已经到了瓶颈。
性能瓶颈
PHP-FPM的每个请求由一个独立的Worker进程处理，进程之间不共享内存。高并发场景下，能开多少Worker进程直接决定了并发处理能力的上限。进程数到一定程度后，操作系统在进程切换上的开销会明显增加，吞吐量反而下降。
当时的商品系统在日常流量下已经需要大量机器来撑。大促时流量翻几十倍，靠加机器已经不现实了。
缓存能力受限
PHP进程之间内存不共享，这一点影响很大。Java应用可以在JVM层面做本地缓存，商品数据加载到内存后，同一个JVM里的所有请求都能直接读取，不需要走网络。PHP做不到，每个请求要么从数据库读，要么走Redis这类外部缓存。
商品数据体量有好几个G。全部走Redis，网络开销在高并发下会成为瓶颈。Java可以用OHC这类堆外缓存把热数据放在本机内存里，极大减少对外部缓存的依赖。PHP没有对等的技术方案。
数据模型僵化
PHP时期的商品表是传统的宽表结构。每新增一个销售属性，需要DDL改表结构，加一列。表结构改动意味着走发版流程：协调DBA审核SQL、选择低峰期执行、验证线上数据。运营新增属性的需求很频繁，加一个字段的周期如果是一周，一个月要加三四次，这个流程的效率问题就暴露出来了。
团队结构
公司的技术团队以Java工程师为主，PHP工程师的招聘难度越来越大。核心系统用PHP，意味着一个很小的人才池在维护一个很关键的系统，人员风险很高。
重构目标
技术指标
架构目标
读写分离。 C端读服务和运营后台写服务分开部署，读服务可以独立扩容，不受写操作影响。
多级缓存。 OHC堆外缓存作为一级缓存，Redis作为中央缓存，MySQL作为数据源。三层之间的加载、更新、失效策略要形成一套完整的体系。
流量隔离。 大促流量和日常流量走不同的处理通道，互不影响。
平滑迁移。 不能停服务直接割接。需要双写、灰度、回滚的完整机制，保证迁移过程中线上业务不受影响。
核心技术需求
这一章把重构需要解决的关键技术问题列出来。每个问题在专栏后续的文章里会有完整的设计和实现，这里只做概述。
数据模型：EAV
传统宽表模式下，每个销售属性是表里的一列。商品表有几十列甚至上百列，大部分在某个具体商品上是空值。每加一个新属性就要DDL。
重构后采用EAV模型（Entity-Attribute-Value）。每个属性是表里的一行记录，而不是一列。记录里包含属性名称、属性类型、属性值等元数据信息。新增属性只需要插入一条记录，不需要改表结构。
EAV的代价是查询和代码层面的复杂度增加。查一个商品的完整信息，需要聚合多行属性记录。参数校验不能靠字段类型硬编码，要先读属性的元数据再做校验。
缓存体系
商品数据量大（G级别），读频率高（日常持续加上大促脉冲），对缓存体系的要求比一般系统高很多。
本地缓存：OHC。 商品数据放JVM堆内会严重影响GC停顿。OHC把数据存在JVM堆外的直接内存中，不参与垃圾回收扫描。需要自己处理序列化和反序列化，每种商品数据类型有独立的Loader。
中央缓存：Redis。 本地缓存未命中的请求走Redis。需要设计Key命名规则、过期策略、大Value拆分方案、防穿透和防击穿机制、热Key处理。
预热与更新。 本地缓存的预热策略、过期后的更新方式、运营修改数据后各层缓存的一致性处理。
读接口设计
商品系统被七八个业务系统调用，每个调用方需要的字段不同。需要一种API设计方式，让调用方声明自己需要哪些数据字段，系统按需组装和返回。避免每个调用方定制一个接口导致接口数量爆炸，也避免一个全量接口把大量无用数据传给调用方。
高并发支撑
数据库一主多从。 读请求分散到多个从库。写操作走主库后，主从之间存在同步延迟。运营刚修改了商品信息，C端用户可能读到旧数据。主从延迟的处理需要专门的方案。
大促流量隔离。 大促开始的瞬间，收藏夹的流量涌入商品详情页，集中在少数热门商品上。如果和正常浏览走同一条链路，正常请求会被挤压。需要在流量层面做隔离。
数据迁移
商品数据量在十几亿级别。旧表是PHP的宽表结构，新表是EAV模型，表结构完全不同。迁移要解决几个问题：
• 新旧表的字段映射关系 • 双写方案：迁移期间新老系统同时写，保证数据一致 • 十几亿数据的全量迁移，不能影响线上服务 • 灰度切换：按比例把流量从旧系统切到新系统 • 回滚方案：灰度过程中发现问题能快速回退 • 数据质检：迁移完成后验证数据的完整性和准确性
约束条件
验收标准
性能
数据
稳定性
风险评估
术语表
小结
技术重构和新建系统有一个根本区别：新建系统的约束少，方案可以自由发挥；重构是在不影响存量业务的前提下替换底层实现，约束条件决定了方案的复杂度上限。不能停服、数据不能丢、要能回滚、调用方无感切换，这些约束叠加在一起，技术方案的复杂度远超从零开始建一个新系统。
这份文档把重构的背景、范围、目标、约束和验收标准写清楚了。后面的技术方案设计，每一个选择都能在这份文档里找到对应的依据。EAV模型对应的是运营频繁新增属性的需求，OHC堆外缓存对应的是商品数据量大到堆内放不下的现实，流量隔离对应的是大促流量会冲击正常浏览的问题。
技术方案不是凭空设计的，它是从需求和约束条件里推导出来的。
所有的代码都可以在知识星球里获取。这个专栏在星球里是免费的，也可以接受无限次的咨询。后续新写的所有付费专栏，在知识星球里都是免费的。我的星球是：
• 老码头的技术浮生录
专栏发布在知乎，欢迎订阅，我的知乎名是:
• SamDeepThinking
