现在的分布式项目基本都会用到redis和mongodb,可是redis和mongdb到底有什么不同呢,今天我就基于我们公司的项目来具体介绍一下redis和mongodb的各自的应用场景。 首先我们这个项目中有两种应用场景: 场景一:要求TPS(不知道的右转百度)特别高的,比如我们项目有一个点赞的功能,这个点赞的功能促发频率特别高,而且并发量也会特别大,但是它的数据量不会特别大。基于这种情况下,我们采用 redis来实现点赞功能。 场景二:项目中涉及评论的内容,而且这个评论表的数据后期会非常大(海量的数据),最后在数据量非常大的情况下还要求比较复杂的查询。基于上述这些情况,我们采用 mongodb作为评论表存储数据库。 redis和mongodb相同点和不同点我这边就不进行过多的描述,网上的文章满地都是,比如这篇文章: ​​https://zhidao.baidu.com/question/178866950875265404.html​​​

应用升级:现在在给大家介绍一下我们项目中关于redis和mongodb深入的应用,我们接着上面的应用场景继续往下说。下面我们接着深入上面的这两个场景,例如下面的这两个场景: 场景一:比如我们上面说到的场景一中点赞这个行为,因为我们项目对点赞这个数据的安全性要求特别高,而且取消点赞的过程种会涉及其它关联的操作,而且必须保证是线程是安全的,最重要的是我们需要redis高可用性,不能轻易的挂掉。这个时候我们就用到了 redis中数据持久化和分布式锁的内容了,通过redis数据持久化,我们可以将缓存的数据保存到本地中来。利用redis分布式锁,我们可以控制取消点赞数据安全问题。关于高可用性的话,我们可以采用redis集群来实现,redis集群我们采用 rediscluster来实现,这样我们就可以实现点赞这种场景的所有要求了。 场景二:我们接着评论表的内容,刚开始评论表可能数据不是特别大,可是随着时间的增长,评论表的数据会越来越大,但是我们查询的时间要控制在一段的间内,不能太久才搜索到相关的评论。最后也是同样的要求,评论查询的高可用性。基于这种场景我们可以采用 mongodb中的分片来实现,通过mongodb的分片机制,我们可以将海量的数据查询分别负载到不同的分片服务器上面,最后将数据查询的数据结果整合到一起。基于这种情况,不管数据量有多大,我们都可以实现快速的查询功能,查询时间约等于 (数据量/分片数量)。分片其实本身就是一种高可用性的方案,因为每一个分片都保留着完整的一份数据,每次插入数据的时候,先插入一个主分片中,然后同步复制到所有从分片中,即使一个分片挂了,其余分片也能自动升级为主分片,继续工作。

疑问点:

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

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

Redis和Mongodb应用场景研究_mongodb