本文来自苏三说技术，郎涯进行简单排版与补充
MongoDB 是一个高可用、分布式的文档数据库，用于大容量数据存储。文档存储一般用类似 json 的格式存储，存储的内容是文档型的。通常情况下，我们用来存储大数据或者 json 格式的数据。
用户写数据的请求，核心数据会被写入数据库，json 格式的非核心数据会写入 MongoDB。流程图如下：
此外，在数据库的表中，保存了 MongoDB 相关文档的 id。用户读数据的请求，会先读数据库中的数据，然后通过文档的 id，读取 MongoDB 中的数据。流程图如下：
这样可以保证核心属性不会丢失，同时存储用户传入的较大的数据，两全其美。
目前双写 MongoDB 和数据库的数据，用的最多的就是下面这两种方案。
该方案最简单，先在数据库中写入核心数据，再在 MongoDB 中写入非核心数据。流程图如下：
如果有些业务场景，对数据的完整性要求不高，即非核心数据可有可无，使用该方案也是可以的。但如果有些业务场景，对数据完整性要求比较高，用这套方案可能会有问题。
当数据库刚保存了核心数据，此时网络出现异常，程序保存 MongoDB 的非核心数据时失败了。但 MongoDB 并没有抛出异常，数据库中已经保存的数据没法回滚，这样会出现数据库中保存了数据，而 MongoDB 中没保存数据的情况，从而导致 MongoDB 中的非核心数据丢失的问题。
所以这套方案，在实际工作中使用不多。
在该方案中，先在 MongoDB 中写入非核心数据，再在数据库中写入核心数据。流程图如下：
关键问题来了：如果 MongoDB 中非核心数据写入成功了，但数据库中的核心数据写入失败了怎么办？
这时候 MongoDB 中非核心数据不会回滚，可能存在 MongoDB 中保存了数据，而数据库中没保存数据的问题，同样会出现数据不一致的问题。
答：我们忘了一个前提，查询 MongoDB 文档中的数据，必须通过数据库的表中保存的 mongo id。但如果这个 mongo id 在数据库中都没有保存成功，那么，在 MongoDB 文档中的数据是永远都查询不到的。也就是说，这种情况下 MongoDB 文档中保存的是垃圾数据，但对实际业务并没有影响。
这套方案可以解决双写数据一致性问题，但它同时也带来了两个新问题：
- 用户修改操作如何保存数据
- 如何清理垃圾数据
我之前聊的先写 MongoDB，再写数据库，这套方案中的流程图，其实主要说的是新增数据的场景。但如果在用户修改数据的操作中，用户先修改 MongoDB 文档中的数据，再修改数据库表中的数据。流程图如下：
如果出现 MongoDB 文档中的数据修改成功了，但数据库表中的数据修改失败了，不也出现问题了？那么，用户修改操作时如何保存数据呢？
这就需要把流程调整一下，在修改 MongoDB 文档时，还是新增一条数据，不直接修改，生成一个新的 mongo id。然后在修改数据库表中的数据时，同时更新 mongo id 字段为这个新值。流程图如下：
这样如果新增 MongoDB 文档中的数据成功了，但修改数据库表中的数据失败了，也没有关系，因为数据库中老的数据，保存的是老的 mongo id。通过该 id，依然能从 MongoDB 文档中查询出数据。
使用该方案能够解决修改数据时，数据一致性问题，但同样会存在垃圾数据。
其实这个垃圾数据是可以即使删除的，具体流程图如下：
在之前的流程中，修改完数据库，更新了 mongo id 为新值，接下来，就把 MongoDB 文档中的那条老数据直接删了。
该方案可以解决用户修改操作中，99% 的的垃圾数据，但还有那 1% 的情况，即如果最后删除失败该怎么办？
答：这就需要加重试机制了。
我们可以使用 job 或者 mq 进行重试，优先推荐使用 mq 增加重试功能。特别是想 RocketMQ，自带了失败重试机制，有专门的重试队列，我们可以设置重试次数。流程图优化如下：
这样基本可以解决修改删除垃圾数据失败的问题。
还有一种垃圾数据还没处理，即在用户新增数据时，如果写入 MongoDB 文档成功了，但写入数据库表失败了。由于MongoDB 不会回滚数据，这时候 MongoDB 文档就保存了垃圾数据，那么这种数据该如何清理呢？
我们可以使用 job 定时扫描，比如：每天扫描一次 MongoDB 文档，将 mongo id 取出来，到数据库查询数据，如果能查出数据，则保留 MongoDB 文档中的数据。
如果在数据库中该 mongo id 不存在，则删除 MongoDB 文档中的数据。
如果 MongoDB 文档中的数据量不多，是可以这样处理的。但如果数据量太大，这样处理会有性能问题。
这就需要做优化，常见的做法是：缩小扫描数据的范围。
比如：扫描 MongoDB 文档数据时，根据创建时间，只查最近 24 小时的数据，查出来之后，用 mongo id 去数据库查询数据。
如果直接查最近 24 小时的数据，会有问题，会把刚写入 MongoDB 文档，但还没来得及写入数据库的数据也查出来，这种数据可能会被误删。
可以把时间再整体提前一小时，例如：
in_time < 当前时间-1 and in_time >= 当前时间-25
获取 25 小时前到 1 小时前的数据。
这样可以解决大部分系统中，因为数据量过多，在一个定时任务的执行周期内，job 处理不完的问题。
但如果根据时间缩小范围之后，数据量还是太大，job 还是处理不完该怎么办？
答：我们可以在 job 用多线程删除数据。
当然我们还可以将 job 的执行时间缩短，根据实际情况而定，比如每隔 12 小时，查询创建时间是 13 小时前到 1 小时前的数据。
或者每隔 6 小时，查询创建时间是 7 小时前到 1 小时前的数据。
或者每隔 1 小时，查询创建时间是 2 小时前到 1 小时前的数据等等。
其实删除垃圾数据还有另外一种思路。
不知道你了解过 Redis 删除数据的策略吗？它在处理大批量数据时，为了防止使用过多的 CPU 资源，用了一种随机删除的策略。
我们在这里可以借鉴一下。有另外一个 job，每隔 500ms 随机获取 10 条数据进行批量处理，当然获取的数据也是根据时间缩小范围的。