明天就是五四青年节了
按往年惯例,我们组织了一次五四青年节答题竞赛抽奖的活动,活动规则就不在这里阐述了,
预估是1000左右用户会在下午3点进入小程序开始答题,30分钟,120道题,每道题15秒
下午3点30分大家陆陆续续进来很顺利,毕竟提前开通了小程序云开发的按量付费服务,能够支持1000个数据库并发
但是在答题结束时,始料未及出现了一个问题,就是部分用户交卷后,没有答题记录,也就是说交卷操作,往集合中,插入这条记录时,出现了异常。
由于我在现场做技术支持,第一时间看到这个截图,我心里咯噔一下,药丸
事故的原因是由于:
我在集合里面用一个时间戳来(具体就是年月日时分秒)作为_id,同时这个时间戳没有加随机数,而高并发情况下,这样的_id就很容易重复,由于_id作为集合的主键,重复后,插入就会报异常。
我在做的时候,也没有想到这个小程序作品在同一秒内会有两个人同时用的"高并发"存在,所以在思想上就没有重视,在写代码的时候,也就不会着重考虑。
我回想一下
当初用时间戳作为集合_id,也是想让id有一定的业务用途,没想到造成了这个教训。其实本来对今天下午这次活动是有所期待的,毕竟跟小伙伴一起奋斗过一整天,就为了这个高光时刻,结果就是没有红酒,没有庆祝,等来了小伙伴异样的眼神
解决方案:
_id还是用云开发系统自己生成吧
问题回顾:
像这种情况能够发生,不能说我们前期测试不够充分,这个场景我们几个甚至几十个测试,确实是不能发现问题,还是在开发具体逻辑时,从思想上,就要高度重视。
欢迎大家扫码体验
直接用数据库的主键_id了。
这个最靠谱吧
随机数方案可以用uuid方案,不推荐,还是主键靠谱。
如果时间精确到毫秒级呢
哈哈那看来云开发还真的能规避不少问题耶hhh