redis从入门到精通

Redis 简介

开源，使用ANSI C 编写，高性能的Key-Value的NoSQL数据库。内存数据库，读写速度非常快，主要应用方向如缓存、分布式锁(如Redisson)、消息的发布订阅(topic)、数据过滤(布隆过滤器)等。redis 提供5中数据类型(String、Hash、List、Set、ZSet)来支持不同的业务场景。除此之外，redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

 

为什么要用缓存

目标：高并发、高可用、高性能   架构的艺术

 

redis与map/guava的区别

缓存分为本地缓存和分布式缓存，以 Java 为例， map/guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性；redis / memcached 称分布式缓存，在多实例下，各实例共用一份缓存数据，缓存具有一致性。缺点是架构较为复杂。

 

redis 的线程模型

redis 内部使用文件事件处理器 file event handler，文件事件处理器是单线程的，所以 redis 是单线程的模型。

文件事件处理器包含 4 个部分：

• 多个 socket
• IO 多路复用程序
• 文件事件分派器
• 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

并发 可能产生多个socket，每个socket对应不同的文件事件，此时 IO 多路复用程序会监听多个 socket，并将产生的文件事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

 

redis 和 memcached 的区别

1. redis提供String, list，set，zset，hash数据结构； memcache支持简单的数据类型，String。

2. redis支持持久化，重启可再次加载使用； Memecache不支持持久化。

3. redis 支持原生cluster；memcached没有原生的集群模式，需要依靠客户端将数据写入集群的分片中。

4. redis使用单线程的多路 IO 复用模型；memcached是多线程，非阻塞IO复用网络模型

 对比图:

 

 

redis 常见命令与使用场景

1.String   

   简单的key-value类型；常见命令：set,get,decr,incr,mget 等； 应用场景 常规计数：微博数，粉丝数等

2.Hash 

  string 类型的 field 和 value 的映射表;  常见命令: hget,hset,hmset,hgetall,等； 应用场景 适合用于存储对象

3.List

  list 是一个双向链表，支持反向查找和遍历，支持反向查找和遍历； 常见命令: lpush,rpush,lpop,rpop,lrange等；应用场景  如微博的关注列表，粉丝列表，消息列表，高性能分页(lrange)等功能

4.Set

   set是一个可以去重的集合，可以轻易实现交集、并集、差集的操作；常见命令: sadd,spop,smembers,sunion等;  应用场景  可以非常方便的实现如共同关注、共同粉丝、共同喜好等功能

?

1	sinterstore key1 key2 key3     将交集存在key1内

5.ZSet

   sorted set增加了一个权重参数score，集合中元素能够按score进行有序排列； 常见命令:  zadd,zrange,zrem,zcard等； 应用场景   实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息

 

redis是怎么删除已经过期的key

      定期删除+惰性删除

• 定期删除：redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载！
• 惰性删除 ：定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。

 

redis 持久化机制 ：RDB AOF

持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后恢复数据）

快照（snapshotting）持久化（RDB）

通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），还可以将快照留在原地以便重启服务器的时候使用。

?

1 2 3

save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。 save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。 save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

AOF（append only file）持久化

与快照持久化相比，AOF持久化 的实时性更好，因此已成为主流的持久化方案。默认情况下Redis没有开启AOF方式的持久化，可以通过appendonly参数开启：

?

1	appendonly yes

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof。

三种不同的 AOF 持久化方式：

?

1 2 3

appendfsync always    #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度 appendfsync everysec  #每秒钟同步一次，显示地将多个写命令同步到硬盘 appendfsync no        #让操作系统决定何时进行同步