高流量秒杀系统的优化思路

业务概述：

业务采用典型的微服务架构，分为网关服务、用户服务、商品服务、交易服务（含秒杀接口）等。

优化步骤概述如下：

1）应用的水平扩展

采用Nginx做反向代理，按照各系统的容量预估部署合适数量的应用服务器。优化tomcat的线程等配置，优化nginx的长连接等配置，采用基于JWT Token的分布式会话管理。



2）多级缓存架构

秒杀业务是个典型的读多写少的业务场景，读优化上考虑如下优化点：



CDN服务：用于缓存动静分离后的静态资源，除了css、js、图片等纯静态资源外，也可对某些页面使用全页面静态化技术。考虑使用全页面静态化技术之后，对应的缓存更新就变得非常困难，考虑将对应的商品模型做更细力度的拆分并使用不同的缓存策略：

对于价格、库存实时性要求高的每次都到服务端拿最新的值；

对于sku中其他的属性取CDN内容就行，如果这些实时性要求不高的属性变化了（商品变动或下架），由后端系统触发异步消息给某一个服务，这个服务负责调用爬虫技术例如phantomjs重新生成最新的页面后推送给cdn服务，这些都是需要api对接的。



redis：视需缓存的数据量的大小，如单台redis能容纳（10G以下缓存），采取一主多从+哨兵模式，即可满足读高并发的横向扩展；如数据量巨大，采取redis cluster的多主多从的模式，同时满足读写的高并发。



nginx：用于保存热点缓存数据，若负载非常大，可采取分发层+应用层的双层架构。第一层为分发层+keepalived，它不管业务，只管代理、数据压缩等基础功能；第二层为应用层，管业务，可以做缓存、限流等功能，做到区分，引入的代价是网络上多了一个消耗节点。nginx的缓存基于LRU淘汰算法，发现没有了先取redis，取不到了再访问应用服务。



应用服务器的缓存：先取本地缓存，取不到取redis，再取不到则删除redis缓存+读数据库+更新redis和本地缓存。为了保证集群间的原子性操作，更新缓存需要分布式锁。同理， 更新数据库的库存等操作也需要分布式锁。 为了保证严格的一致性，需要根据商品ID做一致性hash到同一台机器的一个内存队列，去执行上述操作。



3）消息队列

应用消息队列做流量削峰，事务性消息等。RocketMQ有多种集群部署模式，可视数据量大小采用，建议多主多从的部署方式，同步复制、异步刷盘。



4）防刷限流技术

前端的验证码技术，防止用户恶意下单。

后端的限流采用hystrix，根据系统的实际支持的TPS做限流相关的配置，并设置相应的熔断降级策略。



5）数据库的水平扩展

mysql的多主多从架构，数据分片技术。保证数据量激增后能横向扩展并保证高可用。



6）大数据分析技术

存量数据在每日非活跃时间段导入HDFS，供Spark或Hive做离线分析；线上活跃日志流经Storm或Flink等，做热点分析和系统监控等。最终这些加工后的数据回流至MySQL等关系型数据库，供运营优化，形成良性的商业闭环。