REDIS2.0
string list hash
set 无序集合
声明一个key，键里面的值是元素，元素的类型是string
元素的值是唯一的，不能重复
多个集合类型之间可以进行并集，交集，集查的运算
sadd test1 a b c c d ：添加5个元素（但它不显示重复元素所以结果为4）
smembers test1：查看元素
scard test1 ：查看元素个数
srandmember test1：随机返回该集合中的一个元素
spop test1：随机移除一个元素
smove test1 test2 a：将test1中的元素a，移到test2 中
scorted set zest 有序集合
1、声明一个key，key里面有元素，元素可以有多个，类型也是string，元素都是唯一的不能重复
2、每个元素都会关联double类型的分数，表示的是权重，元素可以通过权重的大小进行排序，元素的权重可以享用
zadd test3 1 one 2 two 3 three：创建有序集合，1、2、3是权重，one，two，three才是值
zrange test3 0 -1 withscores：
返回结果会显示权重，不加withscores就只显示值
zrank test3 one：one在集合当中的索引下标的位置
zcount test3 1 2：统计test3有序集合中，权重>=1,<=2的个数
redis的持久化：
在redis当中，高可用的技术包括持久化，主从复制，哨兵模式，集群
1、持久化是最简单的高可用方式，作用就是备份数据，即 将数据保存到硬盘，防止进程退出导致数据丢失
redis的持久化方式：
1、RDB模式持久化····················>人工或者是定时的把内存当中的数据保存到磁盘，这是一种冷备份的方式（备份的时候不用关闭服务，恢复到时候需要关闭）默认的持久化方式
2、AOF模式持久化···················> 类似于mysql的二进制日志，把所有的redis的操作记录在二进制日志当中，恢复到时候从二进制日志的内容进行回复，全热备份，服务要重启
-
AOF的持久化的实时性更好，进程如果意外丢失，恢复的数据是最多的，AOF是主流的持久化方式
-
RDB持久化：快照持久化，文件的后缀名是 .rdb，redis每次重启时都会读取这个rdb文件进行恢复
save和bgsave：
save可以在配置文件声明，也可以手动
bgsave：向主进程发送一个信号，主进程fork（后台）新建一个子进程，在fork的过程中，主进程阻塞，创建完子进程之后，阻塞解除，子进程来创建rdb文件
vim /etc/redis/redis.cnf
307gg
342gg
340gg：是否开启rdb文件的压缩
cp -a dump.rdb /opt/
rm -rf dump.rdb
cp -a /opt/dump.rdb /var/lib/redis
AOF持久化：一旦开启AOF持久化，redis会默认选择aof作为持久化方式，并且立刻读取二进制文件，开启AOF,一定要在初始化时开启
aof-load-truncated yes
当发现AOF文件被截断时，如果是yes，redis在重启时发现被截断，redis会尽可能的恢复数据，继续运行
no：如果发现AOF文件被截断，redis会拒绝启动
截断：写入过程中出现异常，内存当中有，但是没有完整写入到磁盘
9:10 -9:20
9:15-9:18
AOF的rewrite机制：重写
重写表示的是压缩，当这个二进制日志文件内容越来越多，文件越来越大，于是就有了重写的功能对二进制文件进行压缩
20G===18G
bgrewriteaof进程来进行处理
redis-clibgrewriteaof
rdb和aof之间的优缺点：
1、rdb的文件体积比aof小，适合全量备份，速度也比aof快
2、rdb不能实时持久化，数据如此重要，不能够丢失
3、RDB的兼容性比AOF要差，新老版本之间不能兼容
生产中：redis的版本一定要一致
- APF的优点：实时持久化的策略，兼容性也好，文本格式保存的命令
- 缺点：文件比较大，恢复速度比较慢，对磁盘的I/O性能要求也比较高
redis的性能管理
1、查看redis内存使用的情况：
used_memory:871704 redis数据占用的内存
userd_memory_rss：redis向操作系统申请的内存
userd_memory_peak：redis使用系统内存的峰值
root@redis1:/var/lib/redis# redis-cli info memory | grep ratio allocator_frag_ratio:1.23
分配器的碎片比例，分配器的碎片越多，浪费的内存越多，这个值越小越好
allocator_rss_ratio:2.76
分配器使用多少系统的内存
rss_overhead_ratio:2.74
RSS的开销比例，占用系统的物理内存的额外开销，这个值越低越好，越接近0，redis的实际的使用比就越高。
mem_fragmentation_ratio:13.92
内存的碎皮比例，内存碎片，系统分配之后，但是不能被利用的内存。越低，内存的利用率越高
配置redis的初始化，必须要给redis的内存设置阈值，不设置阈值，只要有需要，redis会占满整个内存，而且会继续占用交换分区的空间★★★★★★
设置阈值后，不会使用交换分区了，到达阈值，系统会自动回收生命周期不足的key
maxmemory-policy noeviction
#设置当达到最大阈值时，如何对键值进行回收，默认情况下是禁止回收的
volatile-lru：根据算法lru从过期时间的数据集合当中淘汰键值，主要是针对设置了ttl的键值对
volatile-ttl：根据算法，淘汰即将过期的数据（也是针对设置生命周期的数据）
allkeys-lru：根据lru算法，淘汰最近很少使用的数据
allkeys-random：淘汰任意的数据
一直删到小于或者等于内存阈值，才不会继续删除
redis的雪崩和redis的击穿，radis的穿透
缓存雪崩：整个作为数据库缓存的键值对，全部失效，redis没有办法处理缓存，所有的请求全部集中到数据库上，数据库很快就崩溃
1、redis集群大面积故障
2.所有的缓存键值对全部被删除（作为数据库缓存的键值对上不会设置生命周期的）
3、大量的redis请求失败，所有的请求直接到了数据库
缓存击穿：热点数据的缓存失效，大量的热点请求全部转发到了数据库
会导致数据库的性能大幅下降
热点数据设置成永不过期
1、我通过mysql的慢查询日志，发现了sql执行的速度突然大幅下降
2、查询redis，发现的缓存的键值对消失了
3、我没有redis的密码，专门负责数据库的人处理
redis穿透：缓存的键值对和数据库当中都没有数据，但是依然有客户端不断在请求，黑客利用漏洞，把大量请求绕过redis，去压垮数据库