关于redis、memcache、mongoDB
1.性能
都比较高，性能对我们来说应该都不是瓶颈。
总体来说，TPS方面redis和memcache差不多，要大于mongoDB。
2.操作的便利性
memcache的数据结构单一。（key-value）
redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数，同时还提供list，set，hash等数据结构的存储。
mongodb支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富。
3.内存空间的大小和数据量的大小
redis在2.0版本后增加了自己的VM特性，突破物理内存的限制；可以对key value设置过期时间(类似memcache)
memcahce可以修改最大可用内存，采用LRU算法。memcahce代理软件magent，比如建立10台4G的memcache集群，就相当于有了40G。magent -s 10.1.2.1 -s 10.1.2.2:11211 -b
10.1.2.3:14000
mongoDB 适合大数据量的存储，依赖操作系统VM做内存管理，吃内存也比较厉害。服务不要和别的服务在一起。
4.可用性(单点问题)
redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照，无增量复制，因性能和效率问题，所以单点问题比较复杂；不支持自动sharding，需要依赖程序设定一致hash机制。一种替代方案是，不用redis本身的复制机制，采用自己做主动复制(多份存储)，或者改成增量复制的方式(需要自己实现)，一致性问题和性能的权衡。
memcache本身没有数据冗余机制，也没必要；对应故障预防，采用依赖成熟的hash或者环状的算法，解决单点故障引起的抖动问题。
mongodb支持master-slave,replicaset(内部采用选举算法，自动故障恢复)，auto sharding机制，对客户端屏蔽了故障转移和切分机制。
5.可靠性(持久化)
对于数据持久化和数据恢复
redis支持(快照、AOF):依赖快照进行持久化，aof增强了可靠性的同时，对性能有所影响；
memcache不支持，通常用在做缓存，提升性能；
mongodb从1.8版本开始采用binlog方式支持持久化的可靠性；
6.数据一致性(事务支持)
memcache在并发场景下，用cas保证一致性；
redis事务支持比较弱，只能保证事务中每个操作连续执行；
mongodb不支持事务；
7.数据分析
mongodb内置了数据分析的功能(mapreduce)，其他不支持
8.应用场景
redis：数据量较小的更性能操作和运算上
memcache：用于在动态系统中减少数据库负载，提升性能；做缓存，提高性能（适合读多写小，对于数据量比较大，可以用sharding）
mongodb：主要解决海量数据的访问效率问题。
| 对比参数 | memcache | redis | mongodb |
|---|---|---|---|
| 数据库类型 | 纯粹的key-value数据库,数据结构单一 | 结构化数据库 | 对象数据库 |
| 支持数据类型 | string | string,list,sort,sorted,hash 丰富的数据表达 | 索引，类似于关系型数据库 |
| 可用性 | 没有数据冗余机制，使用一致性hash增加可用性 | 支持ms,mss结构，slave重连主节点会导致一次全量同步产生，影响性能和效率。可以实现读写分离，slave重连使用全量数据，性能和效率会有问题，不支持自动sharding，需要程序上实现一致性hash | 支持ms,支持replication set，set可以自动故障转换，支持autosharding |
| 持久化支持 | 数据完全放在内存中，没有持久化支持 | 支持持久化，快照持久化和aof持久化 | 1.8版本开始采用binlog方式支持持久化的可靠性 |
| 内存空间优化 | 最大内存限制，LRU算法淘汰（可选） | 独立的vm机制,最大内存限制，数据ttl过期设置，内存淘汰（可选） | 依赖于操作系统的vm管理机制,使用内存映射文件，把剩余内存作为缓存使用，没有最大内存限制，数据存在文件系统上和内存 |
| 是否多线程 | 是，可以通过-t控制进线程数 | 单线程 | 多线程 |
| 性能 | 15W/s的GET,11W/s的SET | 单个实例qps:8.5W左右（GET/SET）（RH2285） | 单个qps:3.5W左右（GET/SET）（RH2285） |
| 事务支持 | 并发场景下，用cas保证一致性 | 事务支持比较弱，保证每个事务操作连续执行，如果一个操作失败，不会回滚。使用乐观锁实现cas。 | 不支持事务 |
| 数据分析 | 简单的get查询功能 | 简单查询功能,支持对集合和hash的操作等 | 查询方便，有类似于sql的语法，支持条件查询 |
| 应用场景 | 常作为前端缓存 | 缓存和数据存储，队列 | 大数据量存储 |
| 特点 | - | 支持使用pipeline减少查询次数 | auto sharding，故障自动切换，mapreduce支持，大文件下的GridFs文件系统 |
| 安全问题 | 目前没有身份验证 | 支持密码验证（requirepass） | 支持collection级别的身份验证（auth） |
| 数据备份和还原 | 数据存放于内存中，不方便备份和还原（stats cachedump） | 可以使用持久化做备份和还原 | mongodump倍份,mogorestore还原。数据导出：mongoexport,mongoimport,导出数据支持csv格式 |
| slowlog相关 | 没有slowlog相关的设置 | 支持slowlog，slowlog存在于数据库中，使用slowlog get获取相关日志，slowlog的大小有限制，超过后会删除旧的 | 支持slowlog（profiling），slowlog存在于system.profile（capped collection）的collection中 |
| 状态查看 | stats | info | mongostat,db.serverStatus(),db.stats(),rs.statsu()等 |
| tunning | 1.object size不要太大（默认只支持1M）2.object 的expires设置（缓存应该具有超时的特点）3.适合数据处理后的缓存，不适合缓存后的处理输出 | 1.开启vm，将不常用的value值给交换到磁盘上 2.尽量将数据存放在内存中 3.前端使用proxy或persistence hash来实现均衡访问 4.使用master-slave结构，做读写分离 5.大数据量时持久化数据dump时影响服务，应该放在slave端做6.使用pipeline聚合访问7.网卡bonding | 1.索引相关(读多写少时) 2.explain解析查询 3.限定返回条目（limit) 4.只查看指定需要字段，不查询所有字段 5.使用capped collection （特殊业务）6.使用replsets,扩展整体集群能力 |
- 类型——memcacheheredis都是将数据存放在内存，所以是内存数据库。当然，memcache也可用于缓存其他东西，例如图片等等。
- 数据类型——Memcache 在添加数据时就要指定数据的字节长度,而 redis 不需要。
- 虚拟内存——当物理内存用完时，可以将一些很久没用到的 value 交换到磁盘。
- 过期策略——memcache 在 set 时就指定，例如 set key1 0 0 8,即永不过期。Redis 可以通过例如 expire 设定，例如 expire name 10。
- 分布式——设定 memcache 集群，利用 magent 做一主从;redis可以做一主多从。都可以一主一从。
- 存储数据安全——memcache 断电就断了，数据没了；redis 可以定期 save 到磁盘。
- 灾难恢复——memcache 同上，redis 丢了后可以通过 aof 恢复。
