Redis需要掌握的知识点总结，包括Redis适用场景、持久化、集群、分区、哨兵、缓存穿透

什么是redis？

Redis 本质上是一个 Key-Value 类型的内存数据库， 整个数据库加载在内存当中进行操作， 定期通过异步操作把数据库数据 flush 到硬盘上进行保存。

因为是纯内存操作， Redis 的性能非常出色， 每秒可以处理超过 10 万次读写操作， 是已知性能

最快的 Key-Value DB。

Redis 的出色之处不仅仅是性能， Redis 最大的魅力是支持保存多种数据结构， 此外单个

value 的最大限制是 1GB， 不像 memcached 只能保存 1MB 的数据， 因此 Redis 可以用

来实现很多有用的功能，比方说用他的 List 来做 FIFO 双向链表，实现一个轻量级的高性 能

消息队列服务， 用他的 Set 可以做高性能的 tag 系统等等。

另外 Redis 也可以对存入的Key-Value 设置 expire 时间， 因此也可以被当作一 个功能加强版的 memcached 来用。

Redis 的主要缺点是数据库容量受到物理内存的限制， 不能用作海量数据的高性能读写， 因此 Redis 适合的场景主要局限在较小数据量的高性能操作和运算上

相比 memcached 有哪些优势？

1、memcached 所有的值均是简单的字符串， Redis 作为其替代者， 支持更为丰富的数据类
2、Redis 的速度比 memcached 快很多
3、Redis 可以持久化其数据

支持哪几种数据类型？

String、 List、 Set、 Sorted Set、 hashes
String字符串：

格式: set key value

string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。

string类型是Redis最基本的数据类型，一个键最大能存储512MB。

Hash（哈希）

格式: hmset name key1 value1 key2 value2

Redis hash 是一个键值(key=>value)对集合。

Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

List（列表）

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）

格式: lpush name value

在 key 对应 list 的头部添加字符串元素

格式: rpush name value

在 key 对应 list 的尾部添加字符串元素

格式: lrem name index

key 对应 list 中删除 count 个和 value 相同的元素

格式: llen name

返回 key 对应 list 的长度

Set（集合）

格式: sadd name value

Redis的Set是string类型的无序集合。

集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

zset(sorted set：有序集合)

格式: zadd name score value

Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

zset的成员是唯一的,但分数(score)却可以重复。

为什么 Redis 需要把所有数据放到内存中？

Redis 为了达到最快的读写速度将数据都读到内存中， 并通过异步的方式将数据写入磁盘。

所以 Redis 具有快速和数据持久化的特征。 如果不将数据放在内存中， 磁盘 I/O 速度为严重

影响 Redis 的性能。 在内存越来越便宜的今天， Redis 将会越来越受欢迎。

字典是如何实现的？

其实字典这种数据结构也内置在很多高级语言中，但是c语言没有，所以redis自己实现了。

应用也比较广泛，比如redis的数据库就是字典实现的。不仅如此，当一个哈希键包含的键值对比较多，或者都是很长的字符串，redis就会用字典作为哈希键的底层实现。

redis的持久化？

1、RDB持久化可以手动执行，也可以配置定期执行，可以把某个时间的数据状态保存到RDB文件中，反之，我们可以用RDB文件还原数据库状态。
2、AOF持久化是通过保存服务器执行的命令来记录状态的。还原的时候再执行一遍即可。

如何选择合适的持久化方式？

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久

化功能。 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以

只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照

（snapshot） 非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复

的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug。

Redis 集群方案应该怎么做？ 都有哪些方案？

1、twemproxy， 大概概念是， 它类似于一个代理方式， 使用方法和普通 Redis 无任何区别，设 置 好它 下 属的多个Redis实例后，使用时在本需要连接Redis的地方改为连接
twemproxy， 它会以一个代理的身份接收请求并使用一致性 hash 算法， 将请求转接到具体 Redis， 将结果再返回 twemproxy。 使用方式简便(相对 Redis 只需修改连接端口)， 对旧项目扩展的首选。 问题： twemproxy 自身单端口实例的压力， 使用一致性 hash 后， 对Redis 节点数量改变时候的计算值的改变， 数据无法自动移动到新的节点。
2、codis， 目前用的最多的集群方案， 基本和 twemproxy 一致的效果， 但它支持在 节点数量改变情况下， 旧节点数据可恢复到新 hash 节点。
3、Redis cluster3.0 自带的集群， 特点在于他的分布式算法不是一致性 hash， 而是 hash槽的概念， 以及自身支持节点设置从节点。 具体看官方文档介绍。
4、在业务代码层实现， 起几个毫无关联的 Redis 实例， 在代码层， 对 key 进行 hash 计算，然后去对应的 Redis 实例操作数据。 这种方式对 hash 层代码要求比较高， 考虑部分包括，节点失效后的替代算法方案， 数据震荡后的自动脚本恢复， 实例的监控， 等等。MySQL 里有 2000w 数据， Redis 中只存 20w 的数据，如何保证 Redis 中的数据都是热点数据？Redis 内存数据集大小上升到一定大小的时候， 就会施行数据淘汰策略

Redis 有哪些适合的场景？

1、会话缓存（Session Cache）
最常用的一种使用 Redis 的情景是会话缓存（session cache）。 用 Redis 缓存会话比其他存储（如 Memcached） 的优势在于： Redis 提供持久化。 当维护一个不是严格要求一致性的缓存时， 如果用户的购物车信息全部丢失， 大部分人都会不高兴的， 现在， 他们还会这样吗？幸运的是， 随着 Redis 这些年的改进， 很容易找到怎么恰当的使用 Redis 来缓存会话的文档。 甚至广为人知的商业平台 Magento 也提供 Redis 的插件。
2、 全页缓存（FPC）
除基本的会话 token 之外， Redis 还提供很简便的 FPC 平台。 回到一致性问题， 即使重启了 Redis 实例， 因为有磁盘的持久化， 用户也不会看到页面加载速度的下降， 这是一个极大改进， 类似 PHP 本地 FPC。再次以 Magento 为例， Magento 提供一个插件来使用 Redis 作为全页缓存后端。此外， 对 WordPress 的用户来说， Pantheon 有一个非常好的插件 wp-Redis， 这个插件能帮助你以最快速度加载你曾浏览过的页面。
3、队列
Reids 在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得 Redis 能作为一个很好的消息队列平台来使用。 Redis 作为队列使用的操作， 就类似于本地程序语言（如Python） 对 list 的 push/pop 操作。如果你快速的在 Google 中搜索“Redis queues”， 你马上就能找到大量的开源项目， 这些项目的目的就是利用 Redis 创建非常好的后端工具， 以满足各种队列需求。 例如， Celery有一个后台就是使用 Redis 作为 broker， 你可以从这里去查看。
4、排行榜/计数器
Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（SortedSet） 也使得我们在执行这些操作的时候变的非常简单， Redis 只是正好提供了这两种数据结构。 所以， 我们要从排序集合中获取到排名最靠前的 10 个用户–我们称之为user_scores”， 我们只需要像下面一样执行即可：当然， 这是假定你是根据你用户的分数做递增的排序。 如果你想返回用户及用户的分数， 你需要这样执行：ZRANGE user_scores 0 10 WITHSCORESAgora Games 就是一个很好的例子， 用 Ruby 实现的， 它的排行榜就是使用 Redis 来存储数据的， 你可以在这里看到。
5、发布/订阅
最后 是 Redis 的发布/订阅功能。 发布/订阅的使用场景确实非常多。 我已看见人们在社交网络连接中使用， 还可作为基于发布/订阅的脚本触发器， 甚至用 Redis 的发布/订阅功能来建立聊天系统。说说 Redis 哈希槽的概念？Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念， Redis 集群有 16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽， 集群的每个节点负责一部分hash 槽

Redis 集群方案应该怎么做？都有哪些方案？

1、twemproxy，大概概念是，它类似于一个代理方式， 使用时在本需要连接 redis 的地方改为连接 twemproxy， 它会以一个代理的身份接收请求并使用一致性 hash 算法，将请求转接到具体 redis，将结果再返回 twemproxy。
缺点： twemproxy 自身单端口实例的压力，使用一致性 hash 后，对 redis 节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。
2、codis，目前用的最多的集群方案，基本和 twemproxy 一致的效果，但它支持在 节点数量改变情况下，旧节点数据可恢复到新 hash 节点
3、redis cluster3.0 自带的集群，特点在于他的分布式算法不是一致性 hash，而是 hash 槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍。

为什么要做 Redis 分区？

分区可以让 Redis 管理更大的内存， Redis 将可以使用所有机器的内存。 如果没有分区， 你最多只能使用一台机器的内存。 分区使 Redis 的计算能力通过简单地增加计算机得到成倍提升,Redis 的网络带宽也会随着计算机和网卡的增加而成倍增长。

Redis 分区有什么缺点？

涉及多个 key 的操作通常不会被支持。 例如你不能对两个集合求交集， 因为他们可能被存储到不同的 Redis 实例（实际上这种情况也有办法， 但是不能直接使用交集指令）。同时操作多个 key,则不能使用 Redis 事务.分区使用的粒度是key，不能使用一个非常长的排序key存储一个数据集（The partitioninggranularity is the key, so it is not possible to shard a dataset with a single hugekey like a very big sorted set） .当使用分区的时候， 数据处理会非常复杂， 例如为了备份你必须从不同的 Redis 实例和主机同时收集 RDB / AOF 文件。分区时动态扩容或缩容可能非常复杂。 Redis 集群在运行时增加或者删除 Redis 节点， 能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。 然而， 有一种预分片的技术也可以较好的解决这个问题。

哨兵

Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：
1、监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
2、提醒（Notification）： 被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3、自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。
特点：
1、保证高可用
2、监控各个节点
3、自动故障迁移
缺点：主从模式，切换需要时间丢数据，没有解决 master 写的压力