Record

机会是留给有准备的人

组织开发抢购活动

最近负责组织开发抢购活动,刚听到都有些小紧张啊,因之前公司搞的大型秒杀抢购都是遇到某系统挂了,但是看过老大搞的秒杀抢购的代码,心中还是有点数的,只是没实战过。这次终于有机会了。然后开始...

活动专题

需求是运营给的,抢购活动核心就是要使用预约码,就是预先领取一个号码,等抢购那天凭此码来抢,没预约码的就哪凉快哪呆着哈。

UED设计活动专题页,设计花了一天就把设计搞弄出了。

前端与php负责切图,拉数据,领取预约码等,代码与调试各花了一天。

后端预约码领取数量,预约码查询,手机验证等都是用java处理。这代码都是以前写好的,我就测试了一下,还能用就给他们了。

终于在21号晚上上线。在公司待到9点,没发现啥事,就高高兴兴回家了,
突然在回家路上运营来电,就知道有事发生,
果然回家一看,老用户可以正常领取,新用户就领半天都不行,一猜是手机未绑定问题,
之前是看着前端同学测试的。到线上就没了,郁闷之极,第二天一早就陪他们改bug,却发现还有其他问题
1.答题错误就永远错误,是关闭弹窗校验问题。
2.用户完善手机号时又多请求一次,会提示此号码已被使用。
最后在上午终于改完,一切ok。只是关闭弹窗要刷新页面,因时间问题就没让他们改了。不影响领取。
其实看他们调试发现有以下几个问题:
1.由于是模版发布,前端同学有时候直接在编辑页改代码,代码没保存到就会丢失了
2.由于有缓存原因php同学与前端同学保存代码不一至,还好二人坐一起,可以商量弄 ,坐远了,改了就不知道谁覆盖了谁的代码了
3.看他们在用alert调试代码,要添alert代码,保存发布很费时间,而且不精准定位问题,其实firefox,chrome的debug功能还是比较强大的。

防高并发

应对高并发请求,首选nginx,能抗住每秒2万请求,嘿嘿,没写过nginx,
老大让我自己想办法,代码之前老大有写过的。我就照着他的代码,写了一个。
其实都简单,核心是有个计数器的东东。超过多少人就重定向到系统繁忙页了。
如果全都放进来,java是抗不住的。预计抢购当天有1万人。
在开发过程中又发现问题:
1. 请求java取活动时间时,在nginx有缓存,导致活动时间有延时现象。
2.活动专题页与抢购页的倒计时不同步,因为活动专题是php的,抢购页是java的 各自取时间不一样,最后统一取nginx服务器时间。

开始抢购

在26号上午12点08分大家开始抢购,此时流量直线上升,打开页面有些缓慢。
后台显示一单单的抢购成功幸运者,并付款成功。好吧可以开开心心的吃午饭了。
吃饭中微博却像突然一盆冷水泼来。搞的吃不下饭,网友在微博上大骂怎么预约码错误。
后来找了一个下午原因,从代码,缓存数据取出,日志分析都未找到真正正确的原因。
郁闷中度过一个下午。。。
遇到这事只能以后防范:
1.永远不要让用户知道哪错了。让他知道其实是系统太忙了就好或还在排队中。可以减少公关压力
2. 加多一些日志记录

end