一个故障的生命周期

这是一个关于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秒钟基本就够了。

结语：

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