背景
疫情初期某地政府决定发放一批免费口罩面向该市市民,该市市民均可免费预约领取,预约时间为早上9点-12点,因此该场景为限时抢购类型场景,会面临非常大的定时超大流量超大并发问题,在该项目的落地过程中,涉及的架构演变,做了一些记录和思考。
原始架构图示&分析(2月2号晚上22点左右的原始架构)
2月2号晚上22点左右的原始架构
这样架构设计:
结果:事实证明该应用一经上线就立刻被打挂了,因未知原因预约页面被泄露,导致还未到预约时间,服务即被打挂。
随后我方介入,进行架构调整,24点左右找的我们,早上9点要开服,时间太紧,任务太重,程序不能动的情况下,几十万的并发架构如何做?
2月3号早上9点左右的架构,4号也恢复了这个架构)
2月3号早上9点左右的架构
这样架构设计:
结果:因为流量太大导致用户一度打不开页面,同时由于域名服务商 XX 的限制,客户无法自助添加解析,且当晚联系不到域名服务商客服,导致 CDN 方案搁浅。
2月5号的架构
这样架构设计:
理想架构
这样架构设计:
时间紧任务重,遇到了N多的坑:
Windows + 烂程序
性能真的极差;最后的成果统计(采样分析,实际数据比这个还大):
成果统计(采样分析)
最后上线的三代架构,为了保险起见上了 150 台机器,但是根据活动期间的观察,以及对压测结果的评估,上 50 台机器应该就可以抗住了,从持续 5 小时一直崩溃被终端用户骂街,到 7 分钟库存售罄的领导赞赏,虽然经历了 3 个通宵的戮战,依然可以隐隐约约感觉到身心都得到了升华。
net.ipv4.tcp_max_tw_buckets = 5000 --> 50000
net.ipv4.tcp_max_syn_backlog = 1024 --> 4096
net.core.somaxconn = 128 --> 4096
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1(5和6同时开启可能会导致nat上网环境建联概率失败)
net.ipv4.tcp_tw_recycle = 1
/etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535
worker_connections 1024-->10240;
worker_processes 1-->16;(根据实际情况设置,可以设置成auto)
worker_rlimit_nofile 1024-->102400;
listen 80 backlog 511-->65533;
部分场景也可以考虑nginx开启长连接来优化短链接带来的开销
/usr/bin/java -server -Xmx8g -verbose:gc -XX:+PrintGCDetails -Xloggc:/var/log/xxxx.gc.log -Dserver.port=xxxx -jar /home/app/we.*****.com/serverboot-0.0.1-SNAPSHOT.jar
maxTotal 8-->20
acceptcount优化(对标somaxconn)