概述：
1、内部数据结构：sds、字典、redisObject
2、Redis数据类型
3、内部运行机制：数据库结构、数据库建过期及清除、Redis事务
4、持久化：RDB、AOF（Redis协议）
5、性能：慢查询日志、数据淘汰策略
6、Redis高可用发展：主从、哨兵、集群
7、集群方案：
官方集群Redis Cluster：服务端集群
Redis Sharding集群：客户端集群
代理中间件：增加代理层，如twemproxy
8、memcache对比
9、redis数据结构的应用场景：
http://m635674608.iteye.com/blog/2239012
参考：
总览： http://redisbook.readthedocs.io/en/latest/index.html#
持久化： https://redis.io/topics/persistence
集群方案：https://www.zhihu.com/question/21419897/answer/89771396
http://www.jianshu.com/p/dbc62ed27f03
memcache：https://www.qcloud.com/community/article/164816001481011841?fromSource=gwzcw.93414.93414.93414
常见问题：https://my.oschina.net/u/1988057/blog/860310
http://www.jianshu.com/p/9363e5b69c27
持久化
@see https://redis.io/topics/persistence
Redis Persistence
Redis provides a different range of persistence options:
The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
The AOF persistence logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset.
If you wish, you can disable persistence at all, if you want your data to just exist as long as the server is running.
It is possible to combine both AOF and RDB in the same instance. Notice that, in this case, when Redis restarts the AOF file will be used to reconstruct the original dataset since it is guaranteed to be the most complete.
RDB：以指定的时间间隔，持久化该时间点的数据快照。
AOF：为服务器接收到的每个写入操作记录日志，当服务器重启时将会被重新读入，重建原始数据。
在同一个实例中，可采用AOF和RDB结合的方式。在这种情况下，当Redis重启时，将使用AOF文件来重新构建数据，因为AOF更能保证数据的完整性。
另外，Redis 可以完全禁用持久化，仅仅运行在内存中。
RDB优点
1、RDB是Redis数据是在某个时间点上，持久化的单个压缩文件。RDB文件是Redis数据的完美备份。
2、RDB非常适合容灾恢复，可以将单个压缩文件发送至远程数据中心
3、RDB可以最大化Redis持久化性能，主进程只需要持续地fork一个子进程，然后将剩下工作交给子进程去完成。主进程不需要参与硬盘的IO操作。
RDB缺点
1、RDB 当发生Redis突然宕机等突发情况时，数据丢失概率较大。RDB是以固定时间间隔来创建快照的，当Redis突然宕机时，这个时间段内的数据将会丢失。
2、RDB 经常需要fork一个子进程来写磁盘。如果数据很大或CPU性能不佳时，fork将会变得非常耗时，可能造成服务端暂停响应客户端几毫秒甚至一秒。AOF也需要fork，但是可以调整写日志的频率，只要不影响持久化即可。
AOF优点
1、使用AOF，Redis更加可靠。默认的同步策略（AOF的记录日志操作又叫同步）每秒钟同步一次（同步由后台线程执行），最多也仅仅只会丢失一秒钟的数据。
2、AOF日志是追加日志的形式，因此即使发生断电等事故也不会产生腐败问题。即使由于某种原因日志以写入一半的命令结束，也可由redis-check-aof工具轻松修复。
3、当Rdis数据增长的非常大时，Redis可以在后台自动重写AOF。重写是完全安全的，当Redis继续向旧文件写入时，同时会创建一个新文件，一旦新文件准备好，Redis就会切换并将日志追加至新文件中。
4、AOF是一个包含所有操作的日志文件，易于理解和解析。可以轻松的导出一个AOF文件。假设错误的使用了FLUSHALL命令，如果在期间没有发生日志重写，只需要停止服务端并删除最近的命令，然后重启Redis即可。
AOF缺点
1、AOF文件通常比同样数据的RDB文件要大。
2、AOF根据具体的同步策略，可能会比RDB更慢。通常every second同步策略的性能仍然很高，假如不使用同步策略，则在高负载下的性能应该都可以与RDB持平。
不过当在巨大的写入负载的情况下，还是RDB更能保证在某个最大延迟以内。
3、一些特定的命令，曾经发生过很少的BUG，导致AOF在重新加载时不能再现完全相同的数据。而这RDB是几乎不可能发生的。
选择：
1、通常情况下，应该这两种持久化方式并用来达到如同PostgreSQL 这样的数据安全级别。
2、如果你可以承受发灾难时可能造成的若干分钟的数据丢失，那么可以简单的仅仅使用RDB
3、也有许多用户仅仅使用AOF，并不鼓励这种方式。每隔若干时间段的RDB数据快照是个非常的数据库备份策略，如果AOF发生BUG，支持更快的重启。
总结：综上所述，未来我们最终可能会将AOF和RDB统一到单一持久性模型（长期计划）。