MySQL serverTimezone=UTC配置引发的投票限制失灵事件

1.1 案发现场

事情是这样的，前阵子做了一个投票系统，结果后来经用户反应，每天凌晨到早上八点可以无限制刷票。

1.2 事件经过

得到消息后我立马连接上数据库,查看投票记录，经过排查发现数据库投票记录真的有投票时间间隔极短，甚至出现一秒投票好几次的灵异事件。

然后我开始排查代码，遇到这种问题，我的第一反应是不是由于并发没限制好导致的？

最开始我尝试的方法是在Controller 的投票方法中使用synchronized 关键字修饰，避免投票并发问题。
但是有朋友说，当synchronized 关键字修饰Controller 中的方法时，可能不奏效，因此我将投票的相关判断逻辑放到Service 方法中，并根据投票用户Id和投票的视频Id 作为key,放到一个共享的ConcurrentHashMap中，实现投票前后加锁和解锁。

也就是说当投票的时候,判断是不是同一个用户对同一个视频进行投票请求，如果是，进行拦截这种刷票的恶意行为。

修改后代码如下：

@Override
    public synchronized AppResponse doVoteService(Long loginUserInfoId,Long videoId,VideoWorksSave videoWorksSave) {
        //构造key
        String key=loginUserInfoId+videoWorksSave.getId();
        //如果等于空 那么说明没有投过票
        //如果当前值等于false
        if(null== MyShareData.voteFlag.get(key)||MyShareData.voteFlag.get(key).equals(true)){
            //标记下拿到锁了，这样其他线程取数据的时候就会发现是false
            //加上锁 尽致其他线程进来
            MyShareData.voteFlag.put(key,false);
            //投票记录查询
            VoteRecordQuery voteRecordQuery = new VoteRecordQuery();
            voteRecordQuery.setVoteUserInfoId(loginUserInfoId);
            voteRecordQuery.setVoteVideoId(videoId);
            Boolean checkVoteFrequencyLimitResult = this.voteRecordService.checkVoteFrequencyLimit(voteRecordQuery);
            if (!checkVoteFrequencyLimitResult) {
                this.appResponse.setResponseCode(201);
                this.appResponse.setResponseMessage("投票失败,每人每天同一个视频只能投票三次");
                this.appResponse.setResponseData(null);
                MyShareData.voteFlag.put(key,true);
                return this.appResponse;
            }
            // 检查用户当天投票总个数是否大于10
            Boolean checkVoteCountLimitResult = this.voteRecordService.checkVoteCountLimit(voteRecordQuery);
            if (!checkVoteCountLimitResult) {
                this.appResponse.setResponseCode(201);
                this.appResponse.setResponseMessage("投票失败,每人每天最多只能投票给十个视频");
                this.appResponse.setResponseData(null);
                MyShareData.voteFlag.put(key,true);
                return this.appResponse;
            }
            //执行投票
            VideoWorksEntity videoWorksEntity = this.updateVideoVote(videoWorksSave);
            //投票记录
            if (null == videoWorksEntity) {
                this.appResponse.setResponseCode(201);
                this.appResponse.setResponseMessage("投票失败");
                this.appResponse.setResponseData(null);
            } else {
                VoteRecordAdd voteRecordAdd = new VoteRecordAdd();
                voteRecordAdd.setVoteUserInfoId(loginUserInfoId);
                voteRecordAdd.setVoteVideoId(videoId);
                VoteRecordEntity voteRecordEntity = this.voteRecordService.addedVoteRecord(voteRecordAdd);
                if (null == voteRecordEntity) {
                    this.appResponse.setResponseCode(201);
                    this.appResponse.setResponseMessage("投票失败");
                    this.appResponse.setResponseData(null);
                } else {
                    this.appResponse.setResponseCode(200);
                    this.appResponse.setResponseMessage("投票成功");
                    this.appResponse.setResponseData(videoWorksEntity);
                }
            }
            //释放锁
            MyShareData.voteFlag.put(key,true);
            return this.appResponse;
        }else{
            this.appResponse.setResponseCode(201);
            this.appResponse.setResponseMessage("投票频率过快,恶意刷票会取消参赛资格,且刷票的票数无效,系统会定期清理");
            this.appResponse.setResponseData(null);
            return this.appResponse;
        }
    }

除此之外，我还尝试使用JMeter （一种接口并发压力测试工具）对接口进行了并发测试，发现一切良好，没有问题。

但是当到了第二天早上，又被反应可以无限制刷票了，我试了下确实如此，我做的两重拦截压根失灵了。

这就很奇怪了，到底是哪里出了问题呢？

第三天早上，我六点起来，测试了接口发现仍然可以无限制刷票，观察了下数据库表的投票记录，由于是今天投的票，那么投票记录就应该又2020-08-18日的才对，但是当我查询今天的投票记录却发现是0.

代码里这么写的

    <!-- 检查用户当天针对该视频投票次数是否大于3-->
    <select id="checkVoteFrequencyLimit" resultType="java.lang.Long">
        SELECT
            COUNT( 1 )
        FROM
            t_vote_record
        <where>
            TO_DAYS(create_date) = TO_DAYS(NOW())
            <if test="voteUserInfoId!=null">
                AND vote_user_info_id = #{voteUserInfoId}
            </if>
            <if test="voteVideoId!=null">
                AND vote_video_Id = #{voteVideoId}
            </if>
        </where>
    </select>

我开始 怀疑是不是SQL 函数有问题，于是换了一个写法试试。

SELECT
	COUNT( 1 ) 
FROM
	t_vote_record 
WHERE
	create_date >= STR_TO_DATE(CONCAT('2020-08-18',' 00:00:00'),'%Y-%m-%d %H:%i:%s' )
	AND 
	create_date <= STR_TO_DATE(CONCAT('2020-08-18',' 23:59:59'),'%Y-%m-%d %H:%i:%s' )
	AND vote_user_info_id = '7977470752808697856' 
	AND vote_video_Id = 10

但是发现还是一样的结果

于是开始猜想会不会是服务器的时区不是中国的时间呢？

因此我登陆了服务器，输入Linux命令查看了下当前服务器的时区

date -R

显示结果如下：

[root@xxxxxx ~]# date -R
Tue, 18 Aug 2020 09:40:36 +0800

我们可以看出Linux服务器时区确定是东八区没错。

而且我在代码日志里打印了插入时间，new Date() 方法显示的时间也是正常的。

对了，我们的数据库使用的是阿里云的云数据库PolarDB，但是想了下也不可能，毕竟阿里云那么多用户，应该不会出现这种错误。

因此我好奇看了下我的数据库连接配置。

spring:
  application:
    name: xxxxxx
  datasource:
    # MySQL 5.x
    #driver-class-name: com.mysql.jdbc.Driver
    # MySQL 8.x
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://xxxxx:3306/app_prod_db?serverTimezone=UTC&useUnicode=true&useSSL=false&allowPublicKeyRetrieval=true&characterEncoding=UTF-8
    username: xxxxxxx
    password: xxxxxx
    initialization-mode: never

我们可以看到serverTimezone=UTC ,这里指定的时区是UTC,于是我赶紧查了下UTC。

然后看到了 serverTimezone=UTC的那些坑 这篇博文。

• 首先，介绍一下什么是UTC，UTC，简称世界统一时间，跟北京时间相比，比北京早8个小时，也就是说，北京2020年3月20日18点的时候，UTC时间为2020年3月20日10点
• 如果你用编译器连接数据库，定义了serverTimezone=UTC，那么在你编译器上执行的SQL语句，会先以UTC时区进行存储，发送到MySQL,然后MySQL以本地时区进行转换，就会导致，执行时间比从编译器上的执行时间早8个小时，导致，同一段SQL语句，在mysql直接执行，与编译器执行，结果不同，因为时间相差8个小时

至此，问题终于找到了。

1.3 解决方案

将serverTimezone=UTC 修改为 serverTimezone=Asia/Shanghai 即可

最终修复解决方法如下：

spring:
  application:
    name: xxxxx
  datasource:
    # MySQL 5.x
    #driver-class-name: com.mysql.jdbc.Driver
    # MySQL 8.x
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://xxxxx:3306/app_prod_db?serverTimezone=Asia/Shanghai&useUnicode=true&useSSL=false&allowPublicKeyRetrieval=true&characterEncoding=UTF-8
    username: xxxxxxx
    password: xxxxxx
    initialization-mode: never

本篇完～