Redis 作为数据库持久化替代方案的问题分析

目前Redis支持两种持久化模式，一种是 Snapshotting（快照），另一种是Append-only file（aof）。 

Snapshotting（快照）：默认的持久化方式，这种模式就是将内存中数据以快照的方式写入到二进制文件中（默认文件为dump.rdb）。
Append-only file（aof）：这种模式Redis会将每一个收到的写命令都通过写方法追加到文件中（默认文件为 appendonly.aof）。当Redis重启时会通过重新执行文件中保存的写命令在内存中重建整个数据库的内容。
aof模式下有三种方式强制写磁盘：
（1）appendfsync always：每次收到写命令就立即强制写入磁盘，性能最慢，但是保证完全的持久化（不推荐使用）
（2）appendfsync everysec：每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中
（3）appendfsync no：完全依赖OS，性能最好，持久化没保证

快照优点是二进制，大小比aof日志文件小，但会丢失最后一次成功备份时间到宕机时间的数据；aof日志文件较大，但相对快照来讲，不容易丢失文件。目前Redis检查数据文件是否有错对于快照及aof都能够支持，但修复则只对aof文件有效。

因此为了保证数据数据完整性，我们就要使用aof模式，并且采用appendfsync always方式，但是这样性能比使用MySQL还要低；如果我们选择appendfsync everysec方式，Redis定期把内存中的数据Flush到持久化存储当中，这样一旦Redis服务器Crash掉，可能会造成一部分数据无法Flush到持久化存储中。

另外Redis没有官方提供的集群方案，对集群化支持不是很好，对于主从同步也是一主多从。

其他方面的问题：

应用开发问题
（1）需要将应用层关系型数据结构全部转换为 key/value 形式
（2）支持的数据类型较少
（3）对大的数据结构list,sorted set,hash set的批量处理意为着其他请求的等待，故使用Redis的复杂数据结构需要控制其单key-struct的大小。

数据查询问题
（1）查询功能较弱
（2）查询的效率问题

缓存使用的规划设计问题。
在使用前要有详细的规划。比如有多少数据以及哪些数据需要存储在内存中，将直接影响系统相关设计。
再比如历史数据或用户访问量较少的数据不应该放到内存中，以减轻内存压力。

数据恢复问题
数据量较大后故障恢复会带来比较大的系统压力，并占用额外内存，可能导致系统内存不足等线上故障。

因此能否将Redis作为数据库的替代方案，取决于我们能否较好的处理持久化等相关问题。