一个故障的生命周期

774 查看

这是一个关于mysql的故事

前奏:

记录移动设备id在移动开发中应该是很常见的操作,一般的流程是:移动设备在应用商店中下载app后打开,这时客户端程序会将获取设备信息并提交到服务器端接口入库。但是由于XX原因我们需要在这之前再加一个同样的请求,也就是在这之前有可能已经写入数据库了,但是还要再走一遍相同的逻辑。

症状:

当我写好程序交由客户端同学去测试的时候,不可思议的事情发生了:有大概20%的概率会报错“Duplicate entry XXX”(此处省去30字),然后客户端同学还反映说如果两个请求间隔1秒钟就没问题。

分析

我看完代码后发现逻辑是这样的:model文件里首先判断设备id是否存在,不存在则写入。结合之前的反馈我断定:第一次写入成功且第二次判断时为空的时候,再写入的时候数据库里已经有数据了。运维同学说服务器mysql是读写分离的,也就是说出现这种问题的原因是:第一次访问服务器时如果设备id不存在(slave)则写入master,这时master开始向slave同步,第二次访问服务器时如果之前的同步完成了则不会二次写入,如果同步没有完成则会第二次写入master,这时就报错了。

解决

1.既然客户端同学说延迟1秒就ok了淡然可以这样干,但是这个时间其实和同步时间相关的,不一定是这个数字,有一定的风险,所以不建议采纳,但是救急是可以的。

2.我的方案是:第一次写入的时候将当前的设备id保存在memcache中,第二次访问的时候直接判定memcache中是否存在,保存时间的话,设置个10秒钟基本就够了。

结语:

其实这种连续写入同一数据到同一表中的需求不是很多,但是业务需求千奇百怪,熟悉业务的同时也要熟悉生产环境,这样才能快速定位问题,解决问题。