后台回复「加群」，进群一起学习
阅读本文大概需要 5 分钟。
“二麻子，听说昨天你系统上线后出了个大 Bug？”
“真是好事不出门，坏事传千里，你这么快就知道了？”
“必须的呀，我对其他事情不敏感，但是对 Bug 有天生的感知力。”
“切！”
“赶紧说说出了啥 Bug，好让我乐乐。”
“简单的说，就是页面提交的 Bug，就是前端提交数据到后台时，没有保证数据的一致性。”
“还是一头懵，再说详细点吧。”
“那我给你说下测试步骤应该就知道了：
1、打开系统某一个任务的编辑页面，并启动编辑；
2、接着再打开同一个任务的另一个编辑页面，并且在编辑完内容后提交到后台；
3、返回到第一步打开的页面中继续进行编辑，提交完成后检查操作结果。
预期结果是在第二步更新完的基础上更新了步骤三的结果，但实际上步骤二的结果完全被步骤三给覆盖了。”
“嗯，这么说我就明白了，这是典型的并发冲突的问题吧，应该是前端在启动编辑的时候从后台拉取了数据，然后提交的时候没有去检查后台是否更新，就直接把前端数据提交了，这个过程中如果没有其他并发，是完全没问题的，一旦有其他并发操作，必然出问题。”
“对对，就是这个问题，后来我看了下代码实现，就是在展示的时候拉取了数据，编辑后，直接把展示时拉取的数据又全部提交了，这么做就是为了省事，因为数据库设计时，是把整个表单的内容存放在一个字段里面的，如果只更新其中某一部分内容，还需要把这个字段进行拆分解析。”
“这么说最终是数据库设计不合理了？”
“问题肯定还是前端（后台接口）实现的问题，再麻烦也不能出问题是吧，至于说数据库，设计上确实可以优化，如果用 MongoDB，因为有格式化存储，一个表单存放在一起还是可以接受的，如果是 MySQL，最好还是分表存储更清晰易操作。”
“那最后是怎么修改的呢？”
“两步走：第一步先把本次问题解决了，就是只把修改内容传到后台，后台从数据库中获取内容并更新，再塞回数据库；第二步，把数据库迁移到了 MongoDB，这样后面更新任意字段数据时，都可以快速单独操作更新了，简化了后台对数据处理的复杂度。”
“嗯，感觉这个场景还是挺常见的，后面所有涉及表单提交的地方，都需要考虑这种并发操作的用例了。”
“是呀，和这个类似的，我还可以提供一个典型案例供参考。”
”好呀好呀，我就喜欢一线的实际案例。“
”大家都知道 MySQL 的数据记录有一个自增 id 的功能，特别方便，MongoDB 也有这样一个 field，但是 ObjectId 类型，可读性不太好，所以有些设计会额外增加一个 id 的 field，只是这个 field 不会自动自增，需要每次插入数据时显式指定。“
”听起来这没毛病呀，会有啥问题？“
”这么用是没毛病，但是这个自增 id 在什么时候计算直接关系到它是否会出毛病。“
“愿闻其详。”
“比如还说表单提交吧，一般这时候是新建表单，如果是 Bug 管理系统，那就是新建 Bug 的步骤，如果我们在点击新建 bug 按钮时，就去获取数据库中最新的 id，并 +1 后当作本次 id，这样就有问题了，比如这个 Bug 还在编辑，其他人也点击了新建 Bug，同时获取了 id，糟糕，这两个新建操作的 id 就重复了。”
“哦……明白了，但是这么明显的问题，应该没人会犯吧。”
“那可说不定哦，特别是当前端和后台开发人员不是一个人时，出现这种错误的概率会更高。”
“嗯，不管怎么样，这个用例都是肯定要覆盖的了。”
“如果用 MySQL 的话，基本不会出现这个问题，它的 id 是自己管理，不需要显式传入，但是 MongoDB 就得特别关注了，所以可以根据不同数据库，针对这个用例设置不同的优先级。”
“对对，我得赶紧回去问问我们开发用的哪个数据库。”
“别急呀，是你的 Bug 它也跑不了，先把我文章转发朋友圈让更多人看到。”
“得，必须的。”
以上，我通过两个简单的场景，说明了 Web 表单提交时，常见的一类问题，一般稍有点经验的开发，都不会犯这种低级错误，但是作为测试，我们不能忽略任何一个可疑点不是？欢迎留言说说你是否碰到过类似的问题。
当然， 如果你认同我的观点，欢迎分享文章到朋友圈 + 点个「在看」让更多人看到，谢谢。
为了感谢大家的支持，我准备了一个抽奖，在 3 月 9 号上午 8 点 15 分自动开奖。
感谢你的阅读、在看和转发，点我抽奖，祝你好运！
推荐阅读：
扫一扫
5242
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
