《苏宁易购：商品详情系统架构设计》阅读笔记
一、背景
商品详情系统是一个展示商品基本信息、参数等详情的系统，是商品购买的入口。
它是电商平台中访问量最大的系统之一，苏宁易购大促期间PV量和UV量很大，这么大的访问量对系统的并发能力要求高。
在业务上它与周边系统的关系是高耦合。依赖商品详情系统的的系统特别多，比如：促销系统、推荐系统、大聚惠、等众多营销系统、还有主数据系统、购物车、收藏夹等，业务复杂度高对系统设计提出更多的要求。
二、商品详情系统三要素
1、展示
产品上需要设计好页面区分展示的内容
技术上主要是页面缓存设计、前端页面模版和JAVA程序的解耦
2、数据处理
数据全部来源于其它系统，在数据上分为：
基本数据，外部系统传过来直接就可以使用的数据
聚合数据，需要加工才能使用的数据
3、服务依赖
通过MQ解耦，异构数据
解决好以上三个问题就解决了此系统核心问题。
三、数据库
1、商品详情系统数据库用Mysql，采用主从加读写分离结构，注意：
主从不在同一个物理机上，也不在同一组路由器中。应用层中业务上对时效性要求高的数据在写库中操作，业务上对于时效性要求不高数据在读库中操作。
主从结构保证在主库出现故障比如岩机自动切换到从库。读库通过LVS做负载均衡做到高可用。
2、DalClient组件支持对数据库的分库分表，同时支持横向扩展。
四、分布式Redis缓存
1、应用层逻辑优先从Reids中获取业务数据，如果Redis中没有，再从DB中获取。
Redis采用sharding方案，每个sharding由一个master和一个salve组成，再通过sentinel保证高可用。
当master出现不故障，比如网络跳动，sentinel会自动把salve切换为master，这个切换是毫秒级的。
master和salve通过主动和被动两种方式来同步，做到最终一致性，符合CAP理论演变过的BASE理论。
2、借鉴JAVA GC中对内存分代思路解决Redis缓存过期产生的惊群现象。
五、前台设计
页面设计：
1、动静分离
JavaScript、CSS统一放到公共的静态服务器上，完全独立的子域名，防止脏Cookie问题和动态域名中无用Cookie问题，通过文件版本号解决系统新版和旧版本之间冲突问题。
所有图片由独立的分布式图片系统管理，对原图进行不同规格的无损裁减和压缩。
2、异步加载和懒加载
商品价格、营销活动信息、库存等动态数据通过异步加载
非首屏数据做懒加载处理，提高首屏加载时间，比如评价、商品详情等内容
3、多级缓存策略
a. 浏览器本地缓存
协商缓存，对于某些时效要求较高的资源通过Last-modified控制数据。做到StatusCode=304
强缓存，JS、CSS等静态资源或者一些页面碎片伪静态数据通过Expires、Cache-Control(http1.1支持)设置做到强缓存，在不强制刷新的情况下可以做到200
b. CDN缓存
CDN分两条线有自营CDN和合作商的CDN，图片、静态资源与伪静态数据分别放在不到的CDN上
c. Varnish缓存
Varnish在设计上负载使用轮询方式，不使用URL HASH策略，用空间换时间的策略， 从而避免热数据问题，也支持横向扩展。
Varnish 缓存和CDN缓存在失效时间错开，从而避免同时失效回源压力过大。
d. 精准缓存
精准缓存失效用于促销活动准时展示的场景，基于Varnish缓存，通过精准控制缓存有效期实现缓存精准失效保证促销活动准时切换。
组件逻辑设计：
商品详情系统中的购买按钮和加入购物车会因商品不同走不同的流程。如：大聚惠商品、定金团商品、预售商品等因促销方式不同，走不同的业务处理流程。
促销模式变化多端，可能每个月都会有变化，通常的面向接口编程和加上工厂方法或者依赖管理框架Spring也很难做到真正的解耦，虽然这样做已经符合开闭原则。我们通过观察者模式很好的解决了这个问题。
让前端的页面模版和JAVA应用程序之间真正的解耦。
六、后台设计
商品数据统一处理设计
商品详情系统商品主数据通过MQ消息来源于外部系统，比如：商品基本信息、参数、参数模版、品牌、品类等。我们设计时把共性抽出来分成三部分：
1、接受MQ消息并持久化通过Listener
2、解析报文
3、业务处理上简化为add、update、delete三个动作
4、异常组件以观察者模式实现，记录处理失败的MQ消息并对消息进行截取，并供下次再反向执行
原文链接：
