1.Redis支持的数据类型？
1. String字符串：
格式: set key value
string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。
string类型是Redis最基本的数据类型，一个键最大能存储512MB。
2. Hash（哈希）
Redis hash 是一个键值(key=>value)对集合。特别可以存储Java中的对象。因为Java对象有若干个实体属性。
格式: hmset name key1 value1 key2 value2
Redis hash 是一个键值(key=>value)对集合。
Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
3. List（列表）
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）
格式: lpush name value
在 key 对应 list 的头部添加字符串元素
格式: rpush name value
在 key 对应 list 的尾部添加字符串元素
格式: lrem name index
key 对应 list 中删除 count 个和 value 相同的元素
格式: llen name
返回 key 对应 list 的长度
4. Set（集合）
格式: sadd name value
Redis的Set是string类型的无序集合。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。
5. zset(sorted set：有序集合)
格式: zadd name score value
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
zset的成员是唯一的,但分数(score)却可以重复。
2.什么是Redis持久化？Redis有哪几种持久化方式？优缺点是什么？
Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
- RDB（快照）
有两种保存的方式：bgsave和save 与save不同bgsave命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。可以通过last save查询bgsave是否执行成功，而对于save命令，整个过程都会阻塞服务器；因此save已基本被废弃，线上环境要杜绝save的使用 )
格式：save n m
RDB是一个紧凑压缩的二进制文件 ，表示在n秒内，如果redis发生了M次的修改，则redis的数据会被存储到内存中。不难看出这是一个周期性的持久化
缺点：
（1）.因为是周期性的，那么当系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
优点：
（1）对 redis 对外提供的读写服务，影响非常小，可以让 redis 保持高性能，
（2） 相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。
- AOF（存储整个数据库）
持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。 在恢复数据时，可以直接读取该文件进行数据恢复
Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。
缺点：
（1）由于AOF一般每秒都在存储，可能对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
优点：
（1）保存的数据额更加完整，能够更好的通过文件完成数据的重建
AOF更加倾向于数据的完整性，而RDB系统的性能会比AOF好一点
3.Redis 有哪些架构模式？讲讲各自的特点
（1）单机版
特点
a、架构简单，只要一个redis实例。
b、内存容量有限
c、处理能力有限
d、无法高可用（单机存在单点故障）
（2）主从复制
Redis 的复制（replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制品则为从服务器（slave）。 只要主从服务器之间的网络连接正常，主从服务器两者会具有相同的数据，主服务器就会一直将发生在自己身上的数据更新同步 给从服务器，从而一直保证主从服务器的数据相同。
特点
a、无法保证高可用（master仍然是单击，仍然存在单点故障）
b、没有降低master写压力，仅仅降低了master的读压力
c、无法高可用
（3）哨兵模式
Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。
特点
a、主从切换需要时间，可能会造成数据丢失
b、仍然没有降低master的读压力，仅仅降低了master的读压力
c、主从模式，切换需要时间丢数据(没解决master的压力)
（4）集群（proxy 型）
Twemproxy 是一个 Twitter 开源的一个 redis 和 memcache 快速/轻量级代理服务器； Twemproxy 是一个快速的单线程代理程序，支持 Memcached ASCII 协议和 redis 协议。
特点
a、多种 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins 。
b、支持失败节点自动删除。
c、后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致。
d、增加了新的 proxy，需要维护其高可用
e、failover 逻辑需要自己实现，其本身不能支持故障的自动转移可扩展性差，进行扩缩容都需要手动干预
（5）集群（直连型）
从redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。
特点
a、无中心架构（不存在哪个节点影响性能瓶颈），少了 proxy 层。
b、数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。
c、可扩展性，可线性扩展到 1000 个节点，节点可动态添加或删除。
d、高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本
e、实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave到 Master 的角色提升。
f、资源隔离性较差，容易出现相互影响的情况。
g、数据通过异步复制,不保证数据的强一致性
参考：
4.使用过Redis分布式锁么，它是怎么实现的？
set key value px milliseconds nx
//释放锁（lua脚本中，一定要比较value，防止误解锁）
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end分布式有3中锁：
- 数据库乐观锁；
- 基于Redis的分布式锁；
- 基于ZooKeeper的分布式锁。
Redis要实现分布式锁，以下条件应该得到满足
互斥性：在任意时刻，只有一个客户端能持有锁。
不能死锁：客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
容错性：只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。
加锁
解锁：
参考：
先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。
如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？
set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的！
5.使用过Redis做异步队列么，你是怎么用的？有什么缺点？
一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。
缺点：
在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。
能不能生产一次消费多次呢？
使用pub/sub主题订阅者模式，可以实现1:N的消息队列。
6.什么是缓存穿透？如何避免？什么是缓存雪崩？何如避免？
缓存穿透
一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。一些恶意的请求会故意查询不存在的key,请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。
如何避免？
1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。
2：对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中，查询时通过该bitmap过滤。
缓存雪崩
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给后端系统带来很大压力。导致系统崩溃。
如何避免？
1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
2：做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期
3：不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。
7.Redis常用命令
Keys pattern：*表示区配所有，以bit开头的，查看Exists key是否存在
Set：设置 key 对应的值为 string 类型的 value。
setnx：设置value时如果 key 已经存在，返回 0，nx 是 not exist 的意思。删除某个key，第一次返回1 删除了 第二次返回0
Expire ：设置过期时间（单位秒），TTL查看剩下多少时间，返回负数则key失效，key不存在了
Setex：设置 key 对应的值为 string 类型的 value，并指定此键值对应的有效期。
Mset：一次设置多个 key 的值，成功返回 ok 表示所有的值都设置了，失败返回 0 表示没有任何值被设置。
Getset：设置 key 的值，并返回 key 的旧值。
Mget：一次获取多个 key 的值，如果对应 key 不存在，则对应返回 nil。
Incr：对 key 的值做加操作,并返回新的值。注意 incr 一个不是 int 的 value 会返回错误，incr 一个不存在的 key，则设置 key 为 1
incrby：同 incr 类似，加指定值 ，key 不存在时候会设置 key，并认为原来的 value 是 0
Decr：对 key 的值做的是减减操作，decr 一个不存在 key，则设置 key 为-1
Decrby：同 decr，减指定值。
Append：给指定 key 的字符串值追加 value,返回新字符串值的长度。
Strlen：取指定 key 的 value 值的长度。
persist xxx(取消过期时间)：选择数据库（0-15库）
Select 0： //选择数据库
move age 1：//把age 移动到1库
Randomkey：随机返回一个key
Rename：重命名
Type ：返回数据类型
8.为什么Redis 单线程却能支撑高并发？
- 纯内存操作
- 核心是基于非阻塞的 IO 多路复用机制
- 单线程反而避免了多线程的频繁上下文切换问题
I/O多路复用原理：https://www.jianshu.com/p/1ae7d15d17ca
9.说说Redis的内存淘汰策略
可以设置Redis最大占用内存大小，那么配置的内存就有用完的时候。那在内存用完的时候，还继续往Redis里面添加数据不就没内存可用了吗？
实际上Redis定义了几种策略用来处理这种情况：（6种redis内存淘汰策略方案）
- noeviction(默认策略)：对于写请求不再提供服务，直接返回错误（DEL请求和部分特殊请求除外）
- allkeys-lru：从所有key中使用LRU算法进行淘汰
- volatile-lru：从设置了过期时间的key中使用LRU算法进行淘汰
- allkeys-random：从所有key中随机淘汰数据
- volatile-random：从设置了过期时间的key中随机淘汰
- volatile-ttl：在设置了过期时间的key中，根据key的过期时间进行淘汰，越早过期的越优先被淘汰
参考：
10.Redis的并发竞争问题如何解决?
redis自己就有天然解决这个问题的CAS类的乐观锁方案
乐观锁：
适用于大家一起抢着改同一个key，对修改顺序没有要求的场景。
watch 命令可以方便的实现乐观锁。
需要注意的是，如果你的 redis 使用了数据分片的方式，那么这个方法就不适用了。
watch 命令会监视给定的每一个key，当 exec 时如果监视的任一个key自从调用watch后发生过变化，则整个事务会回滚，不执行任何动作。
分布式锁：
适合分布式环境，不用关心 redis 是否为分片集群模式。
在业务层进行控制，操作 redis 之前，先去申请一个分布式锁，拿到锁的才能操作。
分布式锁的实现方式很多，比如 ZooKeeper、Redis 等。
时间戳：
适合有序需求场景，例如 A 需要把 key 设置为 a，然后 B 设置为 b，C 再设置为 c，最后的值应该是 c。
这时就可以考虑使用时间戳的方式：
A => set key1 {a 11:01} B => set key1 {b 11:02} C => set key1 {c 11:03}
就是在写入时保存一个时间戳，写入前先比较自己的时间戳是不是早于现有记录的时间戳，如果早于，就不写入了。
假设 B 先执行了，key1 的值为 {b 11:02}，当A执行时，发现自己的时间戳11:01早于现有值，就不执行 set 操作了。
消息队列：
在并发量很大的情况下，可以通过消息队列进行串行化处理。这在高并发场景中是一种很常见的解决方案。
“Redis 并发竞争” 问题就是高并发写同一个key时导致的值错误。
常用的解决方法：
- 乐观锁，注意不要在分片集群中使用
- 分布式锁，适合分布式系统环境
- 时间戳，适合有序场景
- 消息队列，串行化处理
