redis介绍&命令&性能数据及监控&缓存穿透_redis监控指标及linux命令

上一章：

linux安装部署redis&配置远程连接_傲娇的喵酱的博客-CSDN博客

一、redis介绍

Redis是C语言写的，官方提供的数据为100000+的QPS（每秒查询率）

Redis是基于内存操作，Redis的数据在内存中，是非持久化的。

CPU不是Redis性能瓶颈，Redis的瓶颈是根据机器的内存和网络带宽。

redis速度快原因：

1、Redis是基于内存操作，内存的存取速度远高于硬盘的存取速度。redis是将所有的数据全部放在内存中的。

2、redis是单线程操作，（多线程会涉及到CPU上下文会切换，上下文切换会消耗性能)，对于内存系统来说，如果没有上下文切换，单线程效率就是最高的。

Redis 与其他 key - value 缓存产品有以下三个特点：

Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
Redis支持数据的备份，即master-slave模式的数据备份。
 

二、redis连接

1.1 redis-cli 客户端连接redis

本地：

./redis-cli

远程连接：

redis-cli -h host -p port -a password

三、常用命令

redis有16个数据库， 默认使用的是第0个，使用select切换数据库。

我们连接redis成功后，默认使用的是第0个库，想要切换库，使用select切换，比如切换第2个库

select 2

查看当前库下，所有的key

keys *

注意： 由于redis是单线程的，因此在redis key数量很多的时候禁用该命令，否则容易引起生产应用夯机现象
如果一定要使用，除非能确定数据量不大，或者在一个没有被使用的集群节点上使用

新增数据

set key value

例如：

set name zhangsan

读取数据

get key

例如：

get name

模糊搜索

模糊搜索包含关键字的所有key

-匹配数据库中所有 key

keys * 

-？匹配

keys h?llo

匹配 hello ， hallo 和 hxllo

-*匹配

keys h*llo 

匹配 hllo 和 heeello 等。

删除单个key

del key

删除当前数据库中的所有Key （慎用删除啊）

flushdb 

删除所有数据库中的key  （慎用删除啊）

flushall

检查key是否存在

exists key

返回key数据类型

type key 

设置过期时间

设置失效时间1:

expire key seconds
如：
 
expire name 5

设置失效时间2:

setex key seconds value
如：
setex sex 5 boy
setex myname 600 zhangsanhahah

seconds 失效时间，单位秒

查看key的剩余失效时间：

语法：

ttl key的名字

返回值：

• 1、不存在的key：返回 -2

• 2、key存在，但没有设置剩余生存时间：返回 -1

• 3、有剩余生存时间的key：返回key的剩余时间（以秒为单位）

举例：

key myname剩余失效时间为232秒。

四、key的五大数据类型

Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。

4.1 String类型

String 是 redis 最基本的类型，一个 key 对应一个 value。

String 类型是二进制安全的，redis 的 string 可以包含任何数据。

String 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。

4.2 List（列表）

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

LPUSH key value [value ...]

从队列的左边入队一个或者多个元素

如，key name_list 作为一个list,插入zhangsan 与 lisi 这两个元素

RPUSH key value [value ...]

从队列的右边入队一个或者多个元素

127.0.0.1:6379> RPUSH name_list xiaoming xiaohong
(integer) 4

查询元素 LRANGE key start stop

返回存储在key的列表里指定范围内的元素。list的下标从0开始。

-1 表示列表的第一个元素，-2表示列表的第二个元素。

举例：

查询 key  list的前2个元素

 
127.0.0.1:6379> LRANGE name_list 0 1
1) "lisi"
2) "zhangsan"

查询key list 的倒数2个元素

127.0.0.1:6379> LRANGE name_list -2 -1
1) "xiaoming"
2) "xiaohong"

LINDEX key index,通过索引查询元素

查询列表的第一个元素

127.0.0.1:6379> LINDEX name_list 1
"zhangsan"

LLEN key,查询列表的长度

127.0.0.1:6379> LLEN name_list
(integer) 4

 

LIST 集合使用场景：

• 队列或栈：List 可以作为队列或栈来使用，通过 LPUSH 或 RPUSH 在列表的左侧或右侧插入元素，通过 LPOP 或 RPOP 弹出元素。适用于需要按照先进先出或后进先出顺序处理元素的场景。
• 消息队列：可以使用 List 来实现简单的消息队列，将要处理的消息放入 List 中，消费者从列表中获取并处理消息。

4.3 Set

Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。

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

SADD key member [member ...]

添加一个或者多个元素到set集合里

在set集合CARD_ID里添加三个元素

127.0.0.1:6379> SADD CARD_ID id1 id2 id3
(integer) 3

SMEMBERS key

获取集合里所有的元素

127.0.0.1:6379> SMEMBERS CARD_ID
1) "id3"
2) "id1"
3) "id2"

SISMEMBER key member

判断某个值是否在集合里

127.0.0.1:6379> SISMEMBER CARD_ID id1
(integer) 1
127.0.0.1:6379> SISMEMBER CARD_ID id4
(integer) 0

SCARD key

获取集合元素的数量

SREM key member [member ...]

从集合里，删除一个或者多个元素

Set（集合）应用场景：

• 唯一性的存储：Set 中每个元素都是唯一的，适用于需要存储不重复数据的场景。可以使用 SADD 来添加元素，使用 SISMEMBER 来判断元素是否存在，使用 SMEMBERS 来获取所有元素。
• 好友关系：可以使用 Set 来存储用户的好友关系，每个用户的好友列表是一个 Set。通过 SADD 和 SREM 来添加或移除好友关系，使用 SINTER、SUNION 或 SDIFF 来进行好友关系的交集、并集或差集运算。

4.4 Hash

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

添加元素

HSET key field value

举例，在一个名为person的hash key里添加元素。

添加name 等于 zhangsan

127.0.0.1:6379> HSET person name zhangsan
(integer) 1

在person里继续添加元素，address beijing

127.0.0.1:6379> HSET person address beijing
(integer) 1

HGET key field

根据field读取元素

读取key中filed为name的元素

127.0.0.1:6379> HGET person name
"zhangsan"

hash 应用场景：

1. 对象存储：通过将一个对象的多个属性存储在一个 Hash 中，可以更方便地对对象进行存储和查询，避免了使用多个 key 存储对象属性时的管理问题。 例如，存储用户信息时，可以使用一个 key 作为前缀（如"user:1234"），然后将用户的 id、姓名、邮箱等属性存储在一个 Hash 中，每个属性对应一个字段，这样查询用户信息就只需要使用一个 key。

2. 业务计数器：Hash 可以用来存储计数器的值，每个计数器对应 Hash 中的一个字段，不同计数器对应不同的 Hash。 例如，在一个电商网站中，可以使用 Hash 存储商品页面的访问量、收藏量、加入购物车量等信息，每个商品对应一个 Hash，方便实时查看统计数据。

3. 任务列表：Hash 可以用来存储任务信息，在一个 Hash 中存储任务的各种属性，例如任务类型、创建时间、执行时间等。 例如，存储待执行的定时任务时，可以使用 Hash 来存储任务信息，每个 Hash 对应一个任务，任务的执行时间作为 Hash 中的字段，任务的其他属性作为 Hash 中的其他字段。

4. 缓存转储：Hash 可以用来存储缓存数据，将多个键值对存储在一个 Hash 中，避免了 Redis 中 key 的数量过多导致的内存消耗问题。 例如，将多个用户的缓存数据存储在一个 Hash 中，每个用户对应 Hash 中的一个字段。

Hash 在 Redis 中是非常重要的数据结构之一，使用场景非常广泛，可以通过合理的使用 Hash 更好地发挥 Redis 的性能和功能优势。

4.5 ZSet

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

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

有序集合的成员是唯一的,但分数(score)却可以重复。

ZADD key [NX|XX] [CH] [INCR] score member [score member ...]

添加到有序set的一个或者多个成员（如果已存在，则更新分数）

127.0.0.1:6379> ZADD MyZSET 88.8 zhangsan 90 lisi 66 xiaohong 3 xiaoming
(integer) 4

ZRANGE key start stop [WITHSCORES]

通过以分数的排序，来查询数据

分数越低，排的越靠前

如，查询第0个与第1个之间的数据

127.0.0.1:6379> ZRANGE MyZSET 0 1
1) "xiaoming"
2) "xiaohong"

 Sorted Set（有序集合）：应用场景

• 排行榜：Sorted Set 是一个有序的集合，适用于实现排行榜功能。可以使用 ZADD 来添加带有分数的元素，分数表示排名，使用 ZRANGE 或 ZREVRANGE 来获取指定范围内的排行榜数据。
• 任务调度：可以使用 Sorted Set 来实现按照时间顺序调度任务，将任务的执行时间作为分数存储在 Sorted Set 中，通过 ZRANGEBYSCORE 获取当前时间之前需要执行的任务。

五、redis缓存服务器应用场景

一般把redis用作缓存服务器，将一些常用的数据放到redis上。

其他也有把redis当做数据库来用，mysql定时将数据推送到redis上。

5.1  短信验证码---用作缓存服务器

在短信验证码的流程中，验证码会存储在Redis等内存数据库中。这是因为Redis拥有快速的读写能力和高效的内存存储，非常适合用于缓存和临时数据存储。

在实际应用中，验证码的生成和验证流程通常如下：

1. 生成验证码：当用户请求获取验证码时，服务器会生成一个随机的验证码，并将其存储在Redis中。同时，还会将验证码发送给用户的手机号或者其他通道，如邮箱。

2. 存储验证码：将验证码与用户标识（如手机号）作为键值对存储在Redis中，设置一个过期时间限制，以便验证码在一定时间后自动失效并被清除。

3. 验证验证码：当用户收到验证码后，用户会将验证码输入到应用程序中。此时，应用程序会从Redis中获取之前存储的验证码，并与用户输入进行比较，以验证是否匹配。

4. 清除验证码：一旦验证码被验证通过，或者验证码的过期时间到达，应用程序会从Redis中删除该验证码，以确保验证码只能使用一次且不会再被重复利用。

通过将验证码存储在Redis等内存数据库中，可以实现验证码的快速读取和验证，并能有效防止验证码被恶意利用。此外，Redis还提供了一些功能，如设置验证码的过期时间、自动清除过期数据等，可以更好地管理验证码的生命周期。

5.2 

 我们将数据同时推到redis 和mysql。 用户查询数据时，去redis查询数据，如果能查询到数据，就直接返回了，如果在redis查询不到数据，则去mysql查询数据。

5.3 mysql定时将数据推送到redis

 比如我们在一个拉新活动中，有一个榜单模块，展示拉新人数最多的前10名用户。

这个榜单每隔10分钟刷新一次数据。我们将用户拉新数据存在了mysql里，然后设置redis榜单数据失效时间为10分中，每隔10分钟，mysql向redis推送一下数据。

六、缓存穿透、缓存击穿、缓存雪崩：

6.1 概念介绍

1. 缓存穿透：

   • 定义：缓存穿透指的是请求查询缓存和数据库中都不存在的数据，从而导致每次请求都直接访问数据库。
   • 原因：通常是由于恶意请求、非法输入或系统漏洞导致的。攻击者故意提交无效的查询，绕过缓存直接访问数据库。
   • 影响：频繁的缓存穿透会导致数据库负载增加，消耗额外的资源，并可能引起拒绝服务（Denial of Service）攻击。

2. 缓存击穿：

   • 定义：缓存击穿指的是一个热点数据失效或被删除后，大量并发请求同时到达系统并请求该数据，导致缓存无法命中而直接访问数据库。
   • 原因：通常是由于热点数据过期、手动删除、大量并发请求或非法请求引起的。
   • 影响：缓存击穿会导致数据库负载剧增，大量请求直接访问数据库，降低了系统性能，甚至可能导致数据库崩溃。

3. 缓存雪崩：

   • 定义：缓存雪崩指的是缓存中大量数据同时失效或缓存系统不可用，导致大量请求直接访问数据库，对数据库造成巨大压力。
   • 原因：通常是由于缓存过期时间集中、缓存依赖关系或缓存系统故障引起的。
   • 影响：缓存雪崩会导致系统性能下降、响应延迟增加甚至系统崩溃，严重影响系统的可用性。

综上所述，缓存穿透是指访问缓存和数据库都不存在的数据，缓存击穿是指热点数据失效导致请求直接访问数据库，而缓存雪崩是指大量缓存数据同时失效或缓存系统不可用，导致大量请求直接访问数据库。这些问题都会对系统性能、可用性和安全性造成负面影响。

6.2 缓存击穿

6.2.1 定义

缓存击穿：缓存击穿是指在使用缓存的场景下，当某个热点数据失效或不存在时，大量并发请求同时访问该数据，导致请求都穿透缓存直接访问后端数据库，造成数据库负载过大。解决方案通常包括加锁、互斥锁、预加载等方法。

6.2.1 缓存击穿通常发生在以下情况下：

1. 热点数据失效：当某个热点数据的缓存失效，并且有大量请求同时访问该数据时，会导致缓存击穿。

2. 冷启动问题：当系统刚启动或者缓存被清空时，大量请求同时访问未缓存的数据，也会引发缓存击穿。

6.2.2 缓存击穿解决方案

1. 加锁机制：在请求缓存失效时，只允许一个请求去查询数据库，其他请求等待。当第一个请求完成数据库查询后，将结果回写到缓存中，其他请求再从缓存获取数据。这样可以避免大量请求同时访问数据库。

2. 互斥锁（Mutex）：在缓存失效时，利用互斥锁机制阻止并发请求查询数据库。通过在代码层面加锁，保证只有一个线程执行查询操作，其他线程等待并直接从缓存获取数据。

3. 预加载（Cache Pre-warming）：在系统启动或空闲期间，预先将热点数据加载到缓存中。这样可以避免冷启动时大量请求直接访问数据库。

4. 设置短暂的缓存过期时间：当缓存失效后，设定较短的过期时间，避免大量请求在同一时间窗口内访问数据库。

5. 响应穿透检测：在缓存层对请求进行合法性检测，如果请求的数据在数据库中不存在，可以将该键对应的缓存值设置为空值或者特殊标记，避免反复查询数据库。

6.3 缓存穿透

6.3.1 定义

缓存穿透：缓存穿透是指查询一个不存在于缓存和数据库中的数据，导致每次请求都必须查询数据库，而且该数据永远不存在于缓存中，从而浪费了大量的数据库资源。缓存穿透可能因为恶意攻击、非法请求或者系统错误等原因引起。解决方案通常包括设置空值缓存、布隆过滤器、热点数据预加载等方法。

6.3.2 发生场景

1. 恶意请求：攻击者故意发送无效的查询或非法输入，以绕过缓存直接访问数据库。

2. 数据库中不存在的数据：频繁查询缓存和数据库中都不存在的数据。

6.3.3 解决方案

1. 布隆过滤器（Bloom Filter）：使用布隆过滤器来过滤掉那些明显不存在于数据库中的请求。布隆过滤器是一种高效的数据结构，它可以快速判断某个元素是否存在于集合中。

2. 缓存空对象（Cache null objects）：当查询数据库后发现数据不存在时，将结果也缓存下来，但设置一个较短的过期时间。这样，在下一次请求相同数据时就可以从缓存中获取结果，而不需要再次访问数据库。

3. 异常请求拦截（Request filtering）：对于异常请求或频繁请求的IP地址，可以采取一定的限流或封禁策略，以减轻对数据库的负载。

4. 缓存预热（Cache warming）：在系统启动或低峰期，提前将一些热门数据加载到缓存中，避免冷启动时大量请求直接访问数据库。

5. 数据合法性校验：在接收到请求后，进行合法性校验，例如检查参数的有效性、鉴权等，避免非法请求绕过缓存直接访问数据库。

6. 异步加载数据：对于不存在于缓存中的数据，可以通过异步方式加载数据，并将其缓存起来。这样，在下一次请求相同数据时就可以从缓存中获取结果，而不需要再次访问数据库。

6.4 缓存雪崩

6.4.1 定义

缓存雪崩是指在缓存中的大量数据同时失效或者缓存系统不可用导致大量请求直接访问数据库，从而对数据库造成巨大压力。这种情况下，数据库可能会无法承受如此大的并发请求负载，导致系统性能下降甚至崩溃。

6.4.2 发生场景

1. 缓存过期时间集中：当大量缓存的过期时间设置在相近的时刻，或者由于缓存系统异常导致所有缓存同时失效，会导致大量请求在同一时间窗口内穿透缓存去查询数据库。

2. 缓存依赖关系：如果缓存之间存在依赖关系，并且其中一个缓存失效后，其他缓存也无法得到有效更新，会导致相关依赖的数据请求直接访问数据库。

3. 缓存系统故障：当缓存系统发生故障且无法提供服务时，所有的请求都无法命中缓存，只能直接请求数据库，使得数据库承受巨大的负载压力。

6.4.3 解决方案

1. 使用多级缓存和热点数据预加载，减少缓存失效的风险。

2. 合理设置缓存过期时间，避免过多缓存同时失效。

3. 设置随机的缓存过期时间，避免大量缓存在同一时间失效。

4. 实施缓存的容灾备份，确保即使一个缓存节点故障，整个系统仍能正常运行。

5. 在关键路径上增加限流措施，避免过多请求同时访问数据库。

举个例子，就类似于百度这种搜索场景。 如果每天大量的人搜索数据，然后去mysql等这种数据库的磁盘中，查询数据。在磁盘中读取数据，比较慢，会对数据库造成很大压力。

所以 将一些很多人访问的数据（称为热点数据），缓存到redis中。 用户进行搜索的时候，是先去redis 查询数据，如果有数据，则直接返回，如果在redis中查不到数据，然后再去查mysql这种数据库。（这样是比较消耗性能的）

热点数据就是某一段时间内，用户大量访问数据。比如设置某条数据如果十分钟被访问超过5次，则称为热点数据，存在redis中。某条热点数据，在十分钟内被访问没有超过5次，则会被释放掉。

redis缓存穿透：
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求。由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

先查redis缓存，查不到，再去查存储层 这样是非常消耗性能的。

在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
 

缓存击穿：
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。

利用缓存击穿攻击：
还是举搜索的例子，redis存的是热点数据。普通用户进行搜索时，先读取redis缓存，如果读不到，才去mysql数据中读。

当别人攻击时，它会利用大量的生僻词去进行搜索，这些数据在redis里没有，会去读取mysql磁盘，消耗大量的性能。 并且使用 这些生僻的词变成热点数据，存贮在redis缓存中。

此时，正常用户，再去访问时，在redis缓存中，存贮的都是生僻的词，查不到他们的数据，则会再次去mysql中查询数据。造成性能的消耗。

七、redis性能数据及监控

影响redis的性能，包括内存的大小。

key的命中次数，和未命中次数。

7.1 使用info命令查看数据

在命令行，输入info

info主要有以下几项，因版本不同可能略有差别

Server：有关redis服务器的常规信息
Clients：客户端连接部分
Memory：内存消耗相关信息
Persistence：RDB和AOF相关信息
Stats：一般统计
Replication：主从同步信息
CPU：CPU消耗统计
Cluster：集群部分
Keyspace：数据库相关统计

server段一般是配置以及系统项不用特别的关注。

Server部分记录了Redis服务器的信息：

redis_version : 2.8.19                             # Redis服务器版本
redis_git_sha1：00000000                           #Git  SHA1
redis_git_dirty: 0                                 #Git dirty flag
os:  Linux 3.2.0-23-generic x86_64                 #Redis服务器的宿主操作系统
arch_bits: 64                                      #服务器系统架构（32位或64位）
multiplexing_api: epoll                            #Redis使用的事件处理机制
gcc_version:4.6.3                                  #编译Redis时所使用的GCC版本
process_id:7573                                    #Redis服务的进程PID
run_id:f1c233c4194cba88616c5bfff2d97fc3074865c1    #Redis服务器的随机标识符（用于Sentinel和集群）
tcp_port:6379                                      #Redis服务监听的TCP端口
uptime_in_seconds:7976                             #自Redis服务器启动以来，经过的秒数
uptime_in_days:0                                   #自Redis服务器启动以来，经过的天数. 这里还不到1天，故显示为0
hz:10                                              # Redis调用内部函数来执行许多后台任务的频率为每秒10次
lru_clock:1133773                                  #以分钟为单位进行自增的时钟，用于LRU管理
config_file:/data/redis_6379/redis.conf            #redis.conf配置文件所在路径

Clients部分记录了已连接客户端的信息：

connected_clients:2                    #已连接客户端的数量（不包括通过从服务器连接的客户端）
client_longest_output_list:0           #当前的客户端连接中，最长的输出列表
client_biggest_input_buf:0             #当前连接的客户端中，最大的输入缓存
blocked_clients:0                      #正在等待阻塞命令（BLOP、BRPOP、BRPOPLPUSH）的客户端的数量

因为Redis是单线程模型(只能使用单核)，来处理所有客户端的请求， 但由于客户端连接数的增长，处理请求的线程资源开始降低分配给单个客户端连接的处理时间，这时每个客户端需要花费更多的时间去等待Redis共享服务的响应。

因为Redis是单线程模型(只能使用单核)，来处理所有客户端的请求，且Redis默认允许客户端连接的最大数量是10000。若是看到连接数超过5000以上，那可能会影响Redis的性能。因此监控客户端连接数是非常重要的，因为客户端创建连接数的数量可能超出预期的数量，也可能是客户端端没有有效的释放连接。

相关配置项：

maxclients 10000
tcp-backlog 10240  #TCP 监听的最大容纳数量 默认511

Memory部分记录了服务器的内存信息：

used_memory:894216               #Redis分配器分配给Redis的内存。例如，当Redis增加了存储数据时，需要的内存直接从分配器分配给它的内存里面取就可以了，也就是直接从used_memory取。而Redis分配器分配给Redis的内存，是从操作系统分配给Redis的内存里面取的（单位是字节）
used_memory_human:873.26K        #以人类可读格式显示Redis消耗的内存
used_memory_rss:2691072          #操作系统分配给Redis的内存。也就是Redis占用的内存大小。这个值和top指令输出的RES列结果是一样的。RES列结果就表示Redis进程真正使用的物理内存（单位是字节）
used_memory_peak:914160          #Redis的内存消耗峰值（单位是字节）
used_memory_peak_human:892.73K   #以人类可读的格式返回Redis的内存消耗峰值
used_memory_lua:35840            #Lua引擎所使用的内存大小（单位是字节）
mem_fragmentation_ratio:3.01     # used_memory_rss和used_memory之间的比率
mem_allocator:jemalloc-3.6.0     #在编译时指定的，Redis所使用的内存分配器。可以是libc、jemalloc或者tcmalloc
            理想情况下，used_memory_rss的值应该只比used_memory稍微高一点。
            当rss >used，且两者的值相差较大时，表示存在（内部或者外部的）内存碎片。内存碎片的比率可以通过mem_fragmentation_ratio的值看出；
            当used>rss时，表示Redis的部分内存被操作系统换出到交换空间，在这种情况下，操作可能会产生明显的延迟。
used_memory                      #是你的Redis实例中所有key及其value占用的内存大小；
used_memory_rss                  #是操作系统实际分配给Redis进程的内存。这个值一般是大于used_memory的，因为Redis的内存分配策略会产生内存碎片。
used_fragmentation_ratio         #就是内存碎片的比率，正常情况下是1左右，如果大于1比如1.8说明内存碎片很严重了

在使用redis经常会因为memory引发一些列的问题。像因为内存交换产生的性能问题以及延迟问题等。

1、使用Hash Redis在储存小于100个字段的Hash结构上，其存储效率是非常高的

2、设置key的过期时间

3、回收key

另外一定要配置/proc/sys/vm/min_free_kbytes 让系统及时回收内存
echo 102400 >　/proc/sys/vm/min_free_kbytes 设置100m开始回收内存

Persistence部分记录了RDB持久化和AOF持久化有关的信息：

loading:0                           #一个标志值，记录了服务器是否正在载入持久化文件
rdb_changes_since_last_save:0       #距离最后一次成功创建持久化文件之后，改变了多少个键值
rdb_bgsave_in_progress:0            #一个标志值，记录服务器是否正在创建RDB文件
rdb_last_save_time:1427189587       #最近一次成功创建RDB文件的UNIX时间戳
rdb_last_bgsave_status:ok           #一个标志值，记录了最后一次创建RDB文件的结果是成功还是失败
rdb_last_bgsave_time_sec:0          #记录最后一次创建RDB文件耗费的秒数
rdb_current_bgsave_time_sec:-1      #如果服务器正在创建RDB文件，那么这个值记录的就是当前的创建RDB操作已经耗费了多长时间（单位为秒）
aof_enabled:0                       #一个标志值，记录了AOF是否处于打开状态
aof_rewrite_in_progress:0           #一个标志值，记录了服务器是否正在创建AOF文件
aof_rewrite_scheduled:0             #一个标志值，记录了RDB文件创建完之后，是否需要执行预约的AOF重写操作
aof_last_rewrite_time_sec:-1        #记录了最后一次AOF重写操作的耗时
aof_current_rewrite_time_sec:-1     #如果服务器正在进行AOF重写操作，那么这个值记录的就是当前重写操作已经耗费的时间（单位是秒）
aof_last_bgrewrite_status:ok        #一个标志值，记录了最后一次重写AOF文件的结果是成功还是失败

如果AOF持久化功能处于开启状态，那么在Persistence部分还会加上以下域：

aof_current_size:14301           #AOF文件目前的大小
aof_base_size:14301              #服务器启动时或者最近一次执行AOF重写之后，AOF文件的大小
aof_pending_rewrite:0            #一个标志值，记录了是否有AOF重写操作在等待RDB文件创建完之后执行
aof_buffer_length:0              # AOF缓冲区的大小
aof_rewrite_buffer_length:0      #AOF重写缓冲区的大小
aof_pending_bio_fsync:0          #在后台I/0队列里面，等待执行的fsync数量
aof_delayed_fsync:0              #被延迟执行的fsync数量

Stats部分记录了一般的统计信息：

total_connections_received:8     #服务器已经接受的连接请求数量
total_commands_processed:10673   #服务器已经执行的命令数量
instantaneous_ops_per_sec:0      #服务器每秒中执行的命令数量
rejected_connections:0           #因为最大客户端数量限制而被拒绝的连接请求数量
expired_keys:0                   #因为过期而被自动删除的数据库键数量
evicted_keys:0                   #因为最大内存容量限制而被驱逐（evict）的键数量
keyspace_hits:1                  #查找数据库键成功的次数
keyspace_misses:0                #查找数据库键失败的次数
pubsub_channels:0                #目前被订阅的频道数量
pubsub_patterns:0                #目前被订阅的模式数量
latest_fork_usec:159             #最近一次fork()操作耗费的时间(毫秒)

因为Redis是个单线程模型，客户端过来的命令是按照顺序执行的。因此网络问题、慢命令会造成阻塞导致redis性能下降。

如果发生命令阻塞就可以看到每秒命令处理数在明显下降。要分析解决这个性能问题，需要跟踪命令处理数的数量和延迟时间。

cpu部分记录了CPU的计算量统计信息：

used_cpu_sys:75.46               #Redis服务器耗费的系统CPU
used_cpu_user:90.12              #Redis服务器耗费的用户CPU
used_cpu_sys_children:0.00       #Redis后台进程耗费的系统CPU
used_cpu_user_children:0.00      #Redis后台进程耗费的用户CPU

Keyspace部分记录了数据库相关的统计信息

如数据库的键数量、数据库已经被删除的过期键数量。对于每个数据库，这个部分会添加一行以下格式的信息：

db0:keys=25,expires=0,avg_ttl=0   #0号数据库有25个键、已经被删除的过期键数量为0个

7.2 使用工具lepus 监控redis

搭建 lepus 监控redis

lepus官网：发布主题 – 第53页 – Lepus天兔开源企业级数据库监控系统

参考：

Redis入门——Key、五大数据类型图文详解_Code皮皮虾的博客-CSDN博客_redis的key是什么类型

Redis info详解_奋斗永不止步的博客-CSDN博客_redisinfo

redis info 详解 - 西红柿圆 - 博客园