Redis学习记录

参考资料：

http://www.dengshenyu.com/%E5%90%8E%E7%AB%AF%E6%8A%80%E6%9C%AF/2016/01/09/redis-reactor-pattern.html
http://www.redis.cn/topics/data-types.html
http://www.syyong.com/db/Redis-why-the-use-of-single-process-and-single-threaded-way-so-fast.html
https://toutiao.io/posts/546542/app_preview
http://ifeve.com/redis-persistence/

0. 环境

Redis server: 3.0.3

1. 数据类型

• 字符串(Strings)

字符串是一种最基本的Redis值类型。Redis字符串是二进制安全的，这意味着一个Redis字符串能包含任意类型的数据。一个字符串类型的值最多能存储512M字节的内容。

• 列表(Lists)

Redis列表是简单的字符串列表，按照插入顺序排序。

• 集合(Sets)

Redis集合是一个无序的字符串合集。添加、删除以及测试元素是否存在操作的时间复杂度为O(1)。

• 哈希(Hashes)

Redis Hashes是字符串字段和字符串值之间的映射，所以它们是完美的表示对象的数据类型。

• 有序集合(Sorted sets)

Redis有序集合和Redis集合类似，是不包含相同字符串的合集。但每个有序集合的成员都关联着一个评分，这个评分用于把有序集合中的成员按最低分到最高分排列。

• Bitmaps 和 HyperLogLogs

Redis同样支持Bitmaps和HyperLogLogs数据类型，实际上是基于字符串的基本类型的数据类型，但有自己的语义。

2. Redis为什么速度快？

• 完全基于内存
• 单线程：CPU无需在多个线程之间来回切换
• I/O多路复用技术：异步非阻塞IO，既不会因为线程过多导致CPU频繁切换，又能充分利用服务器资源

3. Redis超时可能的原因及应对方法？

• 慢查询：确认是否使用慢查询，可以使用slowlog get num(例如slowlog get 10)查看相应的慢命令
• 内存不足：由于Redis完全基于内存，故内存使用率指标需要关注
• 连接客户端数量过多：连接客户端数量超过默认值容易导致超时
• 若redis主机为虚拟机，可能会有内存延迟：./redis-cli --intrinsic-latency 100这个命令可以在server端判断redis是否有延迟，在客户端通过-h -p 参数可以对比是否为网络导致的延迟
• 大量的删除、过期以及淘汰(由maxmemory-policy控制的)的大对象操作，需要释放相应的RAM，可能会造成redis阻塞，进而造成相应的延迟：若经常有比较大的对象进行删除、过期和淘汰，建议将这些对象分割成一些小对象。
• 持久化可能导致延迟，若数据集大的话，Redis启动持久化子进程很耗时，其间Redis可能短暂停止服务客户端：选择更合理的持久化方案，例如AOF + fsync every second

4. Redis持久化及其优缺点

• RDB持久化：可以在指定的时间间隔内生成数据集的时间点快照
• AOF持久化：记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集

	优点	缺点
RDB	RDB是一种表示某个即时点的Redis数据的紧凑文件。RDB文件适合用于备份。 RDB非常适合于灾难恢复，作为一个紧凑的单一文件，可以被传输到远程的数据中心。 RDB最大化了Redis的性能，因为Redis父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。 RDB在重启保存了大数据集的实例时比AOF要快。	当你需要在Redis停止工作(例如停电)时最小化数据丢失，RDB可能不太好。你可以配置不同的保存点(save point)来保存RDB文件(例如，至少5分钟和对数据集100次写之后，但是你可以有多个保存点)。然而，你通常每隔5分钟或更久创建一个RDB快照，所以一旦Redis因为任何原因没有正确关闭而停止工作，你就得做好最近几分钟数据丢失的准备了。 RDB需要经常调用fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且CPU性能不够强大的话，Redis会停止服务客户端几毫秒甚至一秒。AOF也需要fork()，但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。
AOF	使用AOF Redis会更具有可持久性(durable)：你可以有很多不同的fsync策略：没有fsync，每秒fsync，每次请求时fsync。使用默认的每秒fsync策略，写性能也仍然很不错(fsync是由后台线程完成的，主线程继续努力地执行写请求)，即便你也就仅仅只损失一秒钟的写数据。 AOF日志是一个追加文件，所以不需要定位，在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令(磁盘满或者其他原因),redis-check-aof工具也可以很轻易的修复。 当AOF文件变得很大时，Redis会自动在后台进行重写。重写是绝对安全的，因为Redis继续往旧的文件中追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦第二个文件创建完毕，Redis就会切换这两个文件，并开始往新文件追加。 AOF文件里面包含一个接一个的操作，以易于理解和解析的格式存储。你也可以轻易的导出一个AOF文件。例如，即使你不小心错误地使用FLUSHALL命令清空一切，如果此时并没有执行重写，你仍然可以保存你的数据集，你只要停止服务器，删除最后一条命令，然后重启Redis就可以。	对同样的数据集，AOF文件通常要大于等价的RDB文件。 AOF可能比RDB慢，这取决于准确的fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭fsync，即使在很高的负载下也和RDB一样的快。不过，即使在很大的写负载情况下，RDB还是能提供能好的最大延迟保证。 在过去，我们经历了一些针对特殊命令(例如，像BRPOPLPUSH这样的阻塞命令)的罕见bug，导致在数据加载时无法恢复到保存时的样子。

5. Redis与Memcached的区别

• 实现机制不同：Redis单进程单线程，Memcached单进程多线程
• 持久化策略不同：Redis支持持久化，Memcached必须借助外部工具才能实现持久化
• Redis功能比Memcached更强大，Redis不仅仅是内存数据库(例如可利用Pub/Sub实现发布订阅的消息中间件)，而Memcached仅仅是内存数据库