【Redis】redis基础知识

开心星人

已于 2024-06-14 15:07:22 修改

阅读量1k

点赞数 23

分类专栏： Redis 文章标签： redis 数据库缓存

于 2023-12-27 14:57:11 首次发布

本文链接：https://blog.csdn.net/qq_55675216/article/details/135185804

版权

Redis 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

学一点，整一点，基本都是综合别人的，弄成我能理解的内容
https://blog.csdn.net/liqingtx/article/details/60330555
https://blog.csdn.net/u014723137/article/details/125658176
https://redis.io/commands/ 官方命令

Redis，英文全称是Remote Dictionary Server（远程字典服务），是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
与MySQL数据库不同的是，Redis的数据是存在内存中的。它的读写速度非常快，每秒可以处理超过10万次读写操作。因此redis被广泛应用于缓存，另外，Redis也经常用来做分布式锁。除此之外，Redis支持事务、持久化、LUA 脚本、LRU 驱动事件、多种集群方案。

数据结构

Redis有以下这五种基本类型：
String（字符串）、Hash（哈希）、List（列表）、Set（集合）、zset（有序集合）

它还有三种特殊的数据结构类型
Geospatial、Hyperloglog、Bitmap

在这里插入图片描述

通用指令

help @generic
help @string
help keys
KEYS:查看符合模板的所有key,不建议在生产环境设备上使用
DEL:删除一个指定的key
EXISTS:判断key是否存在
EXPIRE:给一个key设置有效期，有效期到期时该key会被自动删除
TTL:查看一个KEY的剩余有效期

key的层级结构

Redis没有类似MySQL中的Table的概念，我们该如何区分不同类型的key呢？例如，需要存储用户、商品信息到redis，有一个用户id是1，有一个商品id恰好也是1
Redis的key允许有多个单词形成层级结构，多个单词之间用:隔开，格式如下： 项目名:业务名:类型:id

String（字符串）

简介:String是Redis最基础的数据结构类型，它是二进制安全的，可以存储图片或者序列化的对象，值最大存储为512M
应用场景：共享session、分布式锁，计数器、限流。
内部编码有3种，int（8字节长整型）/embstr（小于等于39字节字符串）/raw（大于39个字节字符串）

C语言的字符串是char[]实现的，而Redis使用SDS（simple dynamic string）封装，sds源码如下：
struct sdshdr{ unsigned int len; // 标记buf的长度 unsigned int free; //标记buf中未使用的元素个数 char buf[]; // 存放元素的坑 }
SDS 结构图如下：
在这里插入图片描述

可以通过字符串类型进行数值操作：

127.0.0.1:6379> set mynum "2"
OK
127.0.0.1:6379> get mynum
"2"
127.0.0.1:6379> incr mynum
(integer) 3
127.0.0.1:6379> get mynum
"3"

在遇到数值操作时，redis会将字符串类型转换成数值。

由于INCR等指令本身就具有原子操作的特性，所以我们完全可以利用redis的INCR、INCRBY、DECR、DECRBY等指令来实现原子计数的效果，假如，在某种场景下有3个客户端同时读取了mynum的值（值为2），然后对其同时进行了加1的操作，那么，最后mynum的值一定是5。不少网站都利用redis的这个特性来实现业务上的统计计数需求。

在这里插入图片描述

Hash（哈希）

简介：在Redis中，哈希类型是指v（值）本身又是一个键值对（k-v）结构
简单使用举例：hset key field value 、hget key field
内部编码：ziplist（压缩列表）、hashtable（哈希表）（当field-value长度较短且个数较少时使用ziplist，否则使用hashtable）
应用场景：缓存用户信息等。
注意点：如果开发使用hgetall，哈希元素比较多的话，可能导致Redis阻塞，可以使用hscan。而如果只是获取部分field，建议使用hmget。

<key>都是具体的某个表

hset <key> <field> <value>	给<key>集合中的 <field>键赋值<value>
hget <key1> <field>	从key1中取出指定的field对应的value
hmset <key1> <filed1> <value1> <filed3> <value2> ..	批量插入key1的filed-value对
hexists <key1> <field> 	查看哈希表key1中，给定的field是否存在
hkeys <key>	列出该key的所有field
hvals <key> 	列出该hash集合的所有value
hincrby <key> <field> <incerment>	为哈希表key中的域field的值加上<incerment>
hsetnx <key><field> <value>	给哈希表key添加field-value对，当且仅当域field不存在

在这里插入图片描述
注意，这里的<user:001>整体是一个key，":"不是一定要存在的

在这里插入图片描述

List（列表）

https://blog.csdn.net/m0_60867520/article/details/132327698

简介：列表（list）类型是用来存储多个有序的字符串，一个列表最多可以存储2^32-1个元素。
简单实用举例：lpush key value [value …] 、lrange key start end
内部编码：ziplist（压缩列表）、linkedlist（链表）
应用场景：消息队列，文章列表,

redis中的lists在底层实现上并不是数组，而是链表

在这里插入图片描述

ist应用场景

lpush+lpop=Stack（栈）
lpush+rpop=Queue（队列）
lpsh+ltrim=Capped Collection（有限集合）
lpush+brpop=Message Queue（消息队列）

lpushx 当key不存在，用法和lpush一致，当key存在，则插入失败，返回0
lindex 获取到指定位置的元素，时间复杂度为O（N），如果下标非法则返回nil
linsert 在list的指定处插入元素，如果是before就插入在基准值前面，如果是after就插入到基准值后面，基准值是在list中存在的值而非下标，时间复杂度是O（N）。如果存在多个相同的基准值，那么只插入到第一个基准值处
在这里插入图片描述
llen 获取列表的长度，如果key不存在则返回0
lrem key count value 删除指定的值，count为要删除的个数
ltrim key start end 保留列表中start和stop之间的元素，删除两边的元素
lset key index value 根据指定的下标，修改元素，如果下标越界，则报错
blpop/brpop 类似于阻塞队列，如果队列为空，尝试出队列，阻塞队列根据阻塞时间产生阻塞，期间Redis可以执行其他命令，直到队列不空，返回元素（如果超时了就返回nil）

Set（集合）

简介：集合（set）类型也是用来保存多个的字符串元素，但是不允许重复元素
简单使用举例：sadd key element [element …]、smembers key
内部编码：intset（整数集合）、hashtable（哈希表）
注意点：smembers和lrange、hgetall都属于比较重的命令，如果元素过多存在阻塞Redis的可能性，可以使用sscan来完成。
应用场景：用户标签,生成随机数抽奖、社交需求。

SADD key member1 [member2]	向集合中添加一个或者多个元素，并且自动去重。
SCARD key	返回集合中元素的个数。
SDIFF key1 [key2]	求两个或多个集合的差集。
SDIFFSTORE destination key1 [key2]	求两个集合或多个集合的差集，并将结果保存到指定的集合中。
SINTER key1 [key2]	求两个或多个集合的交集。
SINTERSTORE destination key1 [key2]	求两个或多个集合的交集，并将结果保存到指定的集合中。
SISMEMBER key member	s is member查看指定元素是否存在于集合中,存在为1、不存在为0。
SMEMBERS key	查看集合中所有元素。
SMOVE source destination member	将集合中的元素移动到指定的集合中。
SPOP key [count]	弹出指定数量的元素。
SRANDMEMBER key [count]	随机从集合中返回指定数量的元素，默认返回 1个。
SREM key member1 [member2]	删除一个或者多个元素，若元素不存在则自动忽略。
SUNION key1 [key2]	求两个或者多个集合的并集。
SUNIONSTORE destination key1 [key2]	求两个或者多个集合的并集，并将结果保存到指定的集合中。
SSCAN key cursor [match pattern] [count count]	该命令用来迭代的集合中的元素。

zset （有序集合）

简介：已排序的字符串集合，同时元素不能重复
简单格式举例：zadd key score member [score member …]，zrank key member
底层内部编码：ziplist（压缩列表）、skiplist（跳跃表）
应用场景：排行榜，社交需求（如用户点赞）。

zadd <key> <score1> <value1> <score2> <value2>...	 将一个或多个member元素及其score值加入到有序集key当中。
zrange <key> <start> <stop>[WITHSCORES] 	 返回有序集key中，下标在<start><stop>之间的元素
zrangebyscore key min max [withscores] [limit offset count]	返回有序集 key 中，所有score值介于min和max 之间(包括等于min或max )的成员
zincrby <key> <increment><value>	为元素的score加上增量
zrem <key> <value> 删除该集合下，指定值的元素v
zcount <key> <min> <max>	统计该集合，分数区间内的元素个数。
zrank <key> <value>	返回该值在集合中的排名，从0开始。

Redis 的三种特殊数据类型

Geo：Redis3.2推出的，地理位置定位，用于存储地理位置信息，并对存储的信息进行操作。
HyperLogLog：用来做基数统计算法的数据结构，如统计网站的UV。
Bitmaps ：用一个比特位来映射某个元素的状态，在Redis中，它的底层是基于字符串类型实现的，可以把bitmaps成作一个以比特位为单位的数组

redis持久化

redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

RDB，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。
如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。

RDB
redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。
对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是AOF。

AOF
AOF，英文是Append Only File，即只允许追加不允许改写的文件。
通过配置redis.conf中的appendonly yes就可以打开AOF功能
默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。

因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。

在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。

AOF重写：
在重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。
当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。

主从同步

https://blog.csdn.net/Mr_VK/article/details/132353177

像MySQL一样，redis是支持主从同步的，而且也支持一主多从以及多级从结构。
主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的SORT就可以由从服务器来承担。
redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低redis的处理性能。
主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。
在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。但是从服务器仍然可以接受CONFIG等指令，所以还是不应该将从服务器直接暴露到不安全的网络环境中。如果必须如此，那可以考虑给重要指令进行重命名，来避免命令被外人误执行。

很多企业都没有使用 Redis 的集群，但是至少都做了主从。有了主从，当主节点(Master) 挂掉的时候，运维让从节点 (Slave) 过来接管，服务就可以继续，否则主节点需要经过数据恢复和重启的过程，这就可能会拖延很长的时间，从而影响线上业务的持续服务。

互联网系统一般以主从架构为基础，所谓主从架构设计的思路大概如下。

在多台数据服务器中，只有一台主服务器，而主服务器只负责写入数据，不负责让外部程序读取数据。
存在多台从服务器，从服务器不写入数据，只负责同步主服务器的数据，并让外部程序读取数据。
主服务器在写入数据后，即刻将写入数据的命令发送给从服务器，从而使得主从数据同步。
应用程序可以随机读取某一台从服务器的数据，这样就分摊了读数据的压力。
当从服务器不能工作的时候，整个系统将不受影响;当主服务器不能工作的时候，可以方便地从从服务器中选取一台来当主服务器。

cap理论
C：Consistent，一致性
A：Availability，可用性
P：Partition tolerance ，分区容忍性

分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然会有网络断开的风险，这个网络断开的场景的专业词汇叫作网络分区。
在网络分区发生时，两个分布式节点之间无法进行通信，我们对一个节点进行的修改操作将无法同步到另外一个节点，所以数据的一致性将无法满足，因为两个分布式节点的数据不再保持一致。除非我们牺牲可用性，也就是暂停分布式节点服务，在网络分区发生时，不再提供修改数据的功能，直到网络状况完全恢复正常再继续对外提供服务。
用一句话概括 CAP 原理就是: 当网络分区发生时，一致性和可用性两难全

最终一致
Redis的主从数据是异步同步的，所以分布式的 Redis系统并不满足一致性要求当客户端在 Redis的主节点修改了数据后，立即返回，即使在主从网络断开的情况下主节点依旧可以正常对外提供修改服务，所以 Redis 满足可用性。
Redis 保证最终一致性，从节点会努力追赶主节点，最终从节点的状态会和主节点的状态保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，但一旦网络恢复，从节点会采用多种策略努力追赶，继续尽力保持和主节点一致。

主从同步过程
在这里插入图片描述

事务

MULTI、EXEC、DISCARD、WATCH
1.MULTI用来组装一个事务；
2.EXEC用来执行一个事务；
3.DISCARD用来取消一个事务；
4.WATCH WATCH key [key …] 监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。则取消事务的执行。

watch乐观锁：添加watch关键字，监测redis相应的值，如key1，开启事务（MULTI），然后对key1执行相应的操作指令，操作命令首先存入事务的队列，此时在另一个线程同时操作key1，然后我们这边执行（EXEC）这个对key1操作的事务就会失败，保证了数据的完整性，类似于数据库事务的回滚操作；如果没有watch乐观锁，即使有另一个线程同时操作了key1，正常的事务执行是直接可以执行成功的，就会出现脏数据等情况；

redis> MULTI //标记事务开始
OK
redis> INCR user_id //多条命令按顺序入队
QUEUED
redis> INCR user_id
QUEUED
redis> INCR user_id
QUEUED
redis> PING
QUEUED
redis> EXEC //执行
1) (integer) 1
2) (integer) 2
3) (integer) 3
4) PONG

如果redis开启了AOF持久化的话，那么一旦事务被成功执行，事务中的命令就会通过write命令一次性写到磁盘中去，如果在向磁盘中写的过程中恰好出现断电、硬件故障等问题，那么就可能出现只有部分命令进行了AOF持久化，这时AOF文件就会出现不完整的情况，这时，我们可以使用redis-check-aof工具来修复这一问题，这个工具会将AOF文件中不完整的信息移除，确保AOF文件完整可用。