Redis和Mongodb应用场景研究

╰+攻爆jí腚メ 2022-05-22 06:24 182阅读 0赞

**现在的分布式项目基本都会用到redis和mongodb，可是redis和mongdb到底有什么不同呢，今天我就基于我们公司的项目来具体介绍一下redis和mongodb的各自的应用场景。**

首先我们这个项目中有两种应用场景：

**场景一**：要求TPS（不知道的右转百度）特别高的，比如我们项目有一个点赞的功能，这个点赞的功能促发频率特别高，而且并发量也会特别大，但是它的数据量不会特别大。基于这种情况下，我们采用 **redis**来实现点赞功能。

**场景二**：项目中涉及评论的内容，而且这个评论表的数据后期会非常大（海量的数据），最后在数据量非常大的情况下还要求比较复杂的查询。基于上述这些情况，我们采用 **mongodb**作为评论表存储数据库。

redis和mongodb相同点和不同点我这边就不进行过多的描述，网上的文章满地都是，比如这篇文章： [https://zhidao.baidu.com/question/178866950875265404.html][https_zhidao.baidu.com_question_178866950875265404.html]

**应用升级：现在在给大家介绍一下我们项目中关于redis和mongodb深入的应用，我们接着上面的应用场景继续往下说。下面我们接着深入上面的这两个场景，例如下面的这两个场景：**

**场景一**：比如我们上面说到的场景一中点赞这个行为，因为我们项目对点赞这个数据的安全性要求特别高，而且取消点赞的过程种会涉及其它关联的操作，而且必须保证是线程是安全的，最重要的是我们需要redis高可用性，不能轻易的挂掉。这个时候我们就用到了 **redis中数据持久化和分布式锁**的内容了，通过redis数据持久化，我们可以将缓存的数据保存到本地中来。利用redis分布式锁，我们可以控制取消点赞数据安全问题。关于高可用性的话，我们可以采用redis集群来实现，redis集群我们采用 **rediscluster**来实现，这样我们就可以实现点赞这种场景的所有要求了。

**场景二**：我们接着评论表的内容，刚开始评论表可能数据不是特别大，可是随着时间的增长，评论表的数据会越来越大，但是我们查询的时间要控制在一段的间内，不能太久才搜索到相关的评论。最后也是同样的要求，评论查询的高可用性。基于这种场景我们可以采用 **mongodb中的分片**来实现，通过mongodb的分片机制，我们可以将海量的数据查询分别负载到不同的分片服务器上面，最后将数据查询的数据结果整合到一起。基于这种情况，不管数据量有多大，我们都可以实现快速的查询功能，查询时间约等于 **（数据量/分片数量）**。分片其实本身就是一种高可用性的方案，因为每一个分片都保留着完整的一份数据，每次插入数据的时候，先插入一个主分片中，然后同步复制到所有从分片中，即使一个分片挂了，其余分片也能自动升级为主分片，继续工作。

**疑问点：**

这边可能会有人要问，既然每片的数据都一样，那查询的时间不肯定也一样吗，怎么可能是**（数据量/分片数量），不应该是（数据量\*分片数量）**时间吗。关于这个疑问的话，大家可能得仔细研究一下mongodb分片的规则了，mongodb分片的同时也会把数据进行分片划分，同样一份数据但是每片查询的区域是不一样的，比如**分片一**会查询数据的前半截，然后**分片二**会查询数据的后半截。这样不就可以做到同样的一份数据，但是每一份查询的数据区域都是不一样的。我这边只是简单的说明，想具体研究的话，可以自己百度百度研究研究。

想要更多干货、技术猛料的孩子，快点拿起手机扫码关注我，我在这里等你哦~

![70][]

[https_zhidao.baidu.com_question_178866950875265404.html]: https://zhidao.baidu.com/question/178866950875265404.html
[70]: /images/20220522/272acd590c63408b9b646a27e7ab6a8a.png