又回会影响到下发服务，回查DB变慢，下发服务处理变慢。因此写服务经常会出现抖动，写变慢、下发延迟。
架构3.0平台化、精准化
2015年中开始，架构师李帅启动3.0架构升级，其理念是解耦、简化。架构越简单越好，没接触过的人新人很快可以上手；架构也必须松耦合的，写、下发、读都可以各自做升级，相互不影响，逐步提升整体性能。
用Jingobus基于从库日志识别商品信息变动，并发送通知、刷新redis集群。异步引擎消息可配置化，商品属性的组合对应消息队列。例如：搜索关注skuSKU状态变化，那么只有skuSKU的上下柜状态变化时，才会发送消息，消息体中只包含skuSKU编号及状态。可配置化的任务引擎，新需求响应快、开发接近零成本；实现了按需发送，给消费方减压（例如：给wms的消息量降低80%+）；并且写系统解耦，整体稳定性增强。在推广过程中，还进行跨部门技术协作，共同升级技术架构。例如网站单品页数据异构升级项目，降低50%+接口交互，节约上百台Docker。
商品服务作为超0级系统 ，必须具有高可用性。任何影响到订单的系统故障都必须在三分钟内解决，有了统一切换平台，执行预案是可以很快的。因此发现问题并警报至关重要。在研发负责人赵湘建的引领下，商品组启动秒级监控平台的研发。内存级监控信息收集、合并、延迟秒级。并且实现了秒级监控的平台化，可将监控能力输出到其他系统。
期间商品读服务也在持续进行着升级。因为skuSKU数量大（数十亿）且持续增长（周增长率约105%），Redis存储集群规模也大。读服务为其他众多系统提供商品数据的查询服务，访问量很大，特别是在618，双11期间，所以需要多组Redis集群分担流量。NIO的Redis客户端，降低了连接数量；后续为解决多组Redis集群流量均衡问题，对NIO版本的客户端做了扩展，实现了多分片连接统一管理，使其负载均衡，并能当某一分片宕机的情况下，自动从集群中剔除，恢复后自动加入集群中，达到故障自动转移与恢复的目的。不仅提高了集群整体的吞吐量，而且提升了可靠性。
同时因为商品数量增长很快，Redis集群的规模也成倍增加，为减少资源的利用，设计三级缓存功能，将最热数据放应用内存中，缓存时间较短；热数据放在规模较小的Redis集群中，全量数据放到规模较大的集群中，这样全量数据的Redis集群OPS较少，可以减少部署组数，从而减少资源利用。
图1-3 商品架构V3.0
京东商品系统在业务创新、数据智能化、性能及稳定性提升方面，将持续努力提升，努力实践让技术改变生活的愿景。
本文转载自：http://www.dalbll.com/Group/Topic/ArchitecturedDesign/5121