一个故障的生命周期

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

结语：

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