网站后台管理系统界面百度seo如何优化关键词

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，去压垮数据库