抢口罩活动系统优化

背景

2020年2月份左右，正值疫情肆虐，突然在过年的某一天.接到领导需求，说要在app上实现线上口罩预约，线下药店申领的功能，而且要尽快上线,包含C端，后台，及B端。C端实现线上预约，B端核销 ,当时团队成员鏖战3天，满足上线要求。

上线效果

定时上线，没想到一到时间点涌上来的流量与预估流量相差甚远，页面卡顿，加载白屏，只有提前进去服务的人才能成功预约到,客诉压力也是巨大,没办法，先紧急扩容吧，只能说效果好了那么一点点。

优化措施    

前端采用node开发,部署在docker中，没用docker swarm管理,首先前端针对静态资源做了一次压缩处理,项目原因，没够买cdn服务，不过建议条件允许还是用cdn比较好。当时node是跑在docker里，启动方式也不是pm2启动，后来从docker中迁移出来，改用pm2方式启动，相比以前快了几个数据来，咨询运维，是因为这种方式可以比原来多很多节点提供服务，比如三台集群，跑在docker中是三个节点，但是迁移出来改用pm2,单个服务器上等同于cpu核数个节点在提供服务，比如服务器是32核,那单台就是32个节点，3台服务器就是96个节点在提供服务，可想而知，事实证明效果确实好了，基本都能够正常进入服务。

后端当时优化了springboot默认容器由tomcat改为了undertow,修改了数据库连接池的相关参数，代码层面需求是根据用户当前的定位按照距离降序展示预约药店列表，计算经纬度的逻辑是数据库计算的，因此请求会直接打到db，如图所示：

后来思考了一种方案，将药店id及经纬度信息初始化存储在redis里，用redis的geo数据结构计算距离排序,测试下来接口响应速度也确实提升了,代码如下

nginx配置keepalive等参数配置,另外还发现流量高峰期间，tcp time-wait状态数居高不下，因此查阅相关资料，针对服务器相关参数进行如下优化：

---

fs.file-max=102400   //系统可以打开最大文件数量

net.ipv4.tcp_mem = 3097431 4129911 6194862 //tcp内存大小

net.ipv4.tcp_rmem = 4096 87380 6291456   //tcp读取缓冲区大小

net.ipv4.tcp_wmem = 4096 65536 4194304 //tcp发送缓冲区

net.ipv4.tcp_max_tw_buckets = 5000 //表示系统同时保持TIME_WAIT套接字的最大数量

net.ipv4.tcp_tw_recycle = 1 //表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_tw_reuse  = 1 //表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭

net.ipv4.tcp_syncookies  = 1 //#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

net.ipv4.tcp_fin_timeout = 15 #表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。

net.ipv4.ip_local_port_range = 1024 65535 #表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为1024到65000

net.ipv4.tcp_max_syn_backlog = 8192 #表示SYN队列长度，默认1024，改成8192，可以容纳更多等待连接的网络连接数。

net.ipv4.tcp_keepalive_time = 1200 //表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为30分钟

net.core.somaxconn  = 65535  //#Linux kernel参数，表示socket监听的backlog(监听队列)上限

net.core.netdev_max_backlog  = 200000 #该参数决定了，网络设备接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。

另外机房的带宽以及机房waf,流量限制(比如1分钟有同一个ip大量访问了服务器，会被认为ddos攻击从而触发拉入黑名单等防御措施)等，都需要协调相关人,相关资源去协调排查，排查系统瓶颈时监控很重要,各中间件的性能指标情况如nginx,redis,数据库连接数，内存等状态都能提供很大帮助等。