工作总结:WAR3 2018新年活动踩坑记录

WAR3 2018新年活动踩坑记录

1、sql初始化脚本

sql脚本存在中文时,字符编码保存为utf8( ps:未设置utf8之前,dba导入到线上数据库的中文内容全部不能看。结果加班改数据,泪奔~)

db邮箱账号放长一点。varchar(128) (ps:虽然网易通行证邮箱现在限制长度了,鬼晓得以前的邮箱千奇百怪……)

2、库存维护

不安全)从数据库读取库存quantity,判断quantity>0,扣库存,执行后续操作。

为什么不安全呢? 少量的状况下或许不会有问题,但是大量的数据存取一定会出问题。如果我们需要在quantity>0 的情况下才能扣库存,假设程序在第一行SELECT 读到的quantity 是2 ,看起来数字没有错,但是当MySQL 正准备要UPDATE 的时候,可能已经有人把库存扣成0 了,但是程序却浑然不知,将错就错的UPDATE 下去了。因此必须透过的事务机制来确保读取及提交的数据都是正确的。

解决办法1: 通过redis维护库存

1L); ```
1
2
3
4

*需要注意的问题:在redis减少库存之后,后续的db操作如果出现报错发生回滚,需要补偿redis库存*

``` redisService.forString().opsForValue().increment(key, -1L);

解决办法2: mysql事务 select for update

select for update:
console 1:
console 1

console 2:

console 2

select * from dz_2018_new_year_summary where id =3 ;没有影响 ,可以直接查询到结果

在窗口1 COMMIT WORK之后,窗口2可以立刻获得select的结果;
war3_2018ny_3.png

PS:mysql查看是否auto commit`

SHOW VARIABLES LIKE '%AUTOCOMMIT%';

war3_2018ny_4.png

select @@autocommit

war3_2018ny_5.png

3、过载保护

引用大神的一篇文章:过载保护算法

本次活动没有太大的并发量主要是防止玩家短时间内重复点击“兑换”按钮。具体的实现比较简单粗暴,在redis设置一个key,设置失效时间,玩家点击兑换,如果key存在则拒绝请求。

分享到: