Redis和MongoDB的区别以及应用场景
项目中用的是MongoDB，但是为什么用其实当时选型的时候也没有太多考虑，只是认为数据量比较大，所以采用MongoDB。
最近又想起为什么用MongoDB，就查阅一下，汇总汇总：
之前也用过redis，当时是用来存储一些热数据，量也不大，但是操作很频繁。现在项目中用的是MongoDB，目前是百万级的数据，将来会有千万级、亿级。
就Redis和MongoDB来说，大家一般称之为Redis缓存、MongoDB数据库。这也是有道有理有根据的，
Redis主要把数据存储在内存中，其“缓存”的性质远大于其“数据存储“的性质，其中数据的增删改查也只是像变量操作一样简单；
MongoDB却是一个“存储数据”的系统，增删改查可以添加很多条件，就像SQL数据库一样灵活，这一点在面试的时候很受用。
Mongodb与Redis应用指标对比
MongoDB和Redis都是NoSQL，采用结构型数据存储。二者在使用场景中，存在一定的区别，这也主要由于
二者在内存映射的处理过程，持久化的处理方法不同。MongoDB建议集群部署，更多的考虑到集群方案，Redis
更偏重于进程顺序写入，虽然支持集群，也仅限于主-从模式。
| 指标 | MongoDB(v2.4.9) | Redis(v2.4.17) | 比较说明 |
|---|---|---|---|
| 实现语言 | C++ | C/C++ | – |
| 协议 | BSON、自定义二进制 | 类Telnet | – |
| 性能 | 依赖内存，TPS较高 | 依赖内存，TPS非常高 | Redis优于MongoDB |
| 可操作性 | 丰富的数据表达、索引；最类似于关系数据库，支持丰富的查询语言 | 数据丰富，较少的IO | MongoDB优于Redis |
| 内存及存储 | 适合大数据量存储，依赖系统虚拟内存管理，采用镜像文件存储；内存占有率比较高，官方建议独立部署在64位系统（32位有最大2.5G文件限制，64位没有改限制） | Redis2.0后增加虚拟内存特性，突破物理内存限制；数据可以设置时效性，类似于memcache | 不同的应用角度看，各有优势 |
| 可用性 | 支持master-slave,replicaset（内部采用paxos选举算法，自动故障恢复）,auto sharding机制，对客户端屏蔽了故障转移和切分机制 | 依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制；不支持自动sharding,需要依赖程序设定一致hash机制 | MongoDB优于Redis；单点问题上，MongoDB应用简单，相对用户透明，Redis比较复杂，需要客户端主动解决。（MongoDB 一般会使用replica sets和sharding功能结合，replica sets侧重高可用性及高可靠性，而sharding侧重于性能、易扩展） |
| 可靠性 | 从1.8版本后，采用binlog方式（MySQL同样采用该方式）支持持久化，增加可靠性 | 依赖快照进行持久化；AOF增强可靠性；增强可靠性的同时，影响访问性能 | MongoDB优于Redis |
| 一致性 | 不支持事物，靠客户端自身保证 | 支持事物，比较弱，仅能保证事物中的操作按顺序执行 | Redis优于MongoDB |
| 数据分析 | 内置数据分析功能（mapreduce） | 不支持 | MongoDB优于Redis |
| 应用场景 | 海量数据的访问效率提升 | 较小数据量的性能及运算 | MongoDB优于Redis |
Redis和Mongodb应用场景
现在的分布式项目基本都会用到redis和mongodb，可是redis和mongdb到底有什么不同呢，今天我就基于我们公司的项目来具体介绍一下redis和mongodb的各自的应用场景。
首先我们这个项目中有两种应用场景：
场景一：要求TPS（不知道的右转百度）特别高的，比如我们项目有一个点赞的功能，这个点赞的功能促发频率特别高，而且并发量也会特别大，但是它的数据量不会特别大。基于这种情况下，我们采用redis来实现点赞功能。
场景二：项目中涉及评论的内容，而且这个评论表的数据后期会非常大（海量的数据），最后在数据量非常大的情况下还要求比较复杂的查询。基于上述这些情况，我们采用mongodb作为评论表存储数据库。
应用升级：
现在在给大家介绍一下我们项目中关于redis和mongodb深入的应用，我们接着上面的应用场景继续往下说。下面我们接着深入上面的这两个场景，例如下面的这两个场景：
场景一：比如我们上面说到的场景一中点赞这个行为，因为我们项目对点赞这个数据的安全性要求特别高，而且取消点赞的过程种会涉及其它关联的操作，而且必须保证是线程是安全的，最重要的是我们需要redis高可用性，不能轻易的挂掉。这个时候我们就用到了redis中数据持久化和分布式锁的内容了，通过redis数据持久化，我们可以将缓存的数据保存到本地中来。利用redis分布式锁，我们可以控制取消点赞数据安全问题。关于高可用性的话，我们可以采用redis集群来实现，redis集群我们采用rediscluster来实现，这样我们就可以实现点赞这种场景的所有要求了。
场景二：我们接着评论表的内容，刚开始评论表可能数据不是特别大，可是随着时间的增长，评论表的数据会越来越大，但是我们查询的时间要控制在一段的间内，不能太久才搜索到相关的评论。最后也是同样的要求，评论查询的高可用性。基于这种场景我们可以采用mongodb中的分片来实现，通过mongodb的分片机制，我们可以将海量的数据查询分别负载到不同的分片服务器上面，最后将数据查询的数据结果整合到一起。基于这种情况，不管数据量有多大，我们都可以实现快速的查询功能，查询时间约等于（数据量/分片数量）。分片其实本身就是一种高可用性的方案，因为每一个分片都保留着完整的一份数据，每次插入数据的时候，先插入一个主分片中，然后同步复制到所有从分片中，即使一个分片挂了，其余分片也能自动升级为主分片，继续工作。
疑问点：
这边可能会有人要问，既然每片的数据都一样，那查询的时间不肯定也一样吗，怎么可能是（数据量/分片数量），不应该是（数据量*分片数量）时间吗。关于这个疑问的话，大家可能得仔细研究一下mongodb分片的规则了，mongodb分片的同时也会把数据进行分片划分，同样一份数据但是每片查询的区域是不一样的，比如分片一会查询数据的前半截，然后分片二会查询数据的后半截。这样不就可以做到同样的一份数据，但是每一份查询的数据区域都是不一样的。我这边只是简单的说明，想具体研究的话，可以自己百度百度研究研究。
原文地址
https://blog.csdn.net/linzhiqiang0316/article/details/80721237
https://www.cnblogs.com/java-spring/p/9488227.html
