写点什么

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

用户头像
铁血杰克
关注
发布于: 2020 年 07 月 01 日

业务概述:

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

优化步骤概述如下:

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等关系型数据库,供运营优化,形成良性的商业闭环。



发布于: 2020 年 07 月 01 日阅读数: 86
用户头像

铁血杰克

关注

还未添加个人签名 2017.12.18 加入

还未添加个人简介

评论

发布
暂无评论
高流量秒杀系统的优化思路