前言
在项目选型阶段，MongoDB被选中主要是基于其处理大规模数据集的能力，而当时并未深入探讨其他替代方案。此前，Redis被用于管理少量但访问频繁的热数据。目前，项目采用MongoDB存储百万级数据，预计未来数据量将增长至千万级甚至亿级。
通常，Redis被定义为缓存系统，而MongoDB则被视为数据库系统，这种区分是有其合理性的。Redis将数据主要存储于内存中，其核心功能更偏向于缓存，数据操作简单快捷，类似于变量操作。相对地，MongoDB是一个功能全面的数据存储解决方案，支持复杂的增删改查操作，可通过多种条件进行数据筛选，其灵活性与传统SQL数据库相似，这一特点在技术面试中常被提及并受到重视。
比较
| 指标 | 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 |
生活中总是充满了各种选择，点餐纠结，出行选择，聚餐座位，团队投票结果不明，随机抽签一锤定音等等！为了解决这个问题，我开发了一款微信小程序，随机做出决策！无论是随机抽选还是投硬币，都能轻松搞定。现在通过微信小程序二维码就能体验！快来试试吧，让选择变得更简单！
