从MongoDB搬家到Redis的那些事儿，聊聊redis移库过程中的坑和心得

根据多位开发者在技术社区如CSDN、博客园、Stack Overflow上的经验分享,以及个人项目实践中的总结综合而成）

从MongoDB搬家到Redis，这事儿听起来好像就是把数据从一个仓库搬到另一个小仓库，但真动手了才发现，这俩压根就不是同一种东西，MongoDB是个文档数据库，像个大仓库，东西可以随便堆，结构灵活；Redis呢，更像是一个功能超级多的精装储物柜，存取极快，但每个格子怎么用，规矩很明确，所以这个“搬家”过程，与其说是搬运,不如说是一次彻底的数据结构和应用逻辑的重构。

先说最开始遇到的坑，就是数据模型对不上，MongoDB里，一个文档可能嵌套了好几层，结构复杂，比如存一篇文章，文章本身有标题、作者、内容，下面还嵌套着评论数组，每个评论又有评论人、内容和时间，你想直接把这么一坨数据塞进Redis？门儿都没有，Redis可没这现成的结构来存，你得拆解，得想办法，当时我们就纠结了很久，是直接用一个大JSON字符串把整个文档存成String类型？还是用Hash来存文章的基本信息，然后用List或者Sorted Set来存评论？用String存倒是简单，一次性读写，但你想单独更新一个评论点赞数就没戏了，得整个读出来，改完再整个塞回去，又慢又容易出问题，最后我们选择了用Hash存文章主体，用Sorted Set存评论（用评论时间做分数），这样既能快速取文章，又能按时间排序取评论，但这个设计过程本身就很费脑筋,得根据业务场景反复权衡。

然后就是数据迁移工具的选择，一开始想偷懒，找个现成的ETL工具或者写个脚本，从MongoDB里读出来，转一下格式再写到Redis，但很快就发现不行，首先是数据量大了之后，单线程脚本慢得像蜗牛，还容易中途崩溃，其次是直接转移忽略了Redis的一个重要特性：它支持设置过期时间（TTL），MongoDB里的数据可没这概念，如果我们不手动给迁移到Redis的数据设置TTL，那Redis的内存很快就会被塞满，变成只进不出的“貔貅”，到时候就得哭着去手动清理或者扩容了，后来我们放弃了简单的脚本，自己写了个多线程的迁移程序，在读取MongoDB数据后，会根据业务规则（比如文章发布时间）主动为Redis里的数据计算并设置一个合理的TTL，这一步是血的教训,千万不能忘。

迁移过程中还有个不大不小但很烦人的坑，就是数据类型搞错，MongoDB的字段类型比较松散，一个数字可能存成了NumberInt，也可能存成了NumberLong，甚至有时候不小心存成了字符串，但Redis对类型要求很严格，你往一个Hash字段里存了个字符串“123”，然后想用INCRBY命令给它加1，Redis会直接给你报错，因为它期望的是个数字，我们在测试阶段就发现了好几次这种错误，就是因为源数据里有些字段类型不干净，所以迁移前，对MongoDB里的数据做一次彻底的“体检”，清洗一下数据类型,非常有必要。

等数据终于搬过去了，以为万事大吉了？错，应用代码的改动才是大头，以前查询MongoDB，可能一个复杂的聚合查询（Aggregation Pipeline）就搞定了，现在到了Redis这边，得拆解成好几个命令，可能要先从Hash里取文章ID，再用这些ID去Sorted Set里做范围查询，最后再去Hash里把详情捞出来，虽然每个操作都很快，但网络往返次数多了，整体延迟可能会上去，这就要求我们对业务代码做大量重构，把之前依赖数据库做的复杂查询逻辑，拿到应用层来实现，这个过程很容易引入新的Bug,测试工作量巨大。

最后聊聊心得吧，最大的心得就是：别为了用Redis而用Redis，这次迁移是因为我们的业务场景中，大部分都是高频读取、很少修改的数据，比如文章详情、热门评论列表，用Redis做缓存能极大提升性能，但如果你的业务需要频繁的复杂查询、事务支持，那MongoDB可能依然是更好的选择，甚至可以考虑MongoDB和Redis共存，热数据放Redis，冷数据和分析查询还放在MongoDB，各司其职，这次“搬家”让我深刻认识到，没有万能的数据库，只有最适合具体场景的数据库，搬家之前，一定要想清楚为什么要搬，目标是什么，否则很容易从一个坑跳进另一个更大的坑，整个过程虽然踩了不少坑，但也逼着我们对数据模型和业务逻辑做了次深度优化，从结果看,还是值得的。