Redis简介-CSDN博客

本文链接：https://blog.csdn.net/weixin_46078315/article/details/118153005

文章目录

Redis

Redis

redis是什么

Redis是一个高性能的key-value数据库

Redis是非关系型数据库

继续内存开发的数据库，并且实现持久化

Redis的优点

丰富的数据结构
性能极高读的速度是110000次/s 写的速度是81000次/s
所有操作都是原子性的
支持发布订阅，通知，过期key特性

redis能干嘛

缓存，提升服务器性能，中间件
排行榜 sortset数据功能
好友关系交集并集差集方便搞定一些共同好友共同爱好
计算机/限速器利用原子性的自增操作，统计用户点赞数，用户访问。限速器：限制某个用户访问某个API的频率，比如抢购，防止用户疯狂点击带来的不必要的压力
简单消息队列除了redis的发布订阅模式，也可以利用List来实现一个队列机制，比如到货通知，邮件发送
Session共享默认session是保存在服务器的文件中，当前服务器，如果是集群服务，同一个用户过来可能落在不同的机器上，这就会导致用户的频繁登录，采用redis保存session后，无论用户落在哪台机器上对能获取到对应的session信息
实现分布式锁

为什么是单线程？

因为redis是基于内存操作，cpu不是redis的操作瓶颈，redis的瓶颈是根据机器的内存和网络带宽。

为什么单线程还快？

这里说两种误区

高性能的服务器一定是多线程的? 不是的
多线程一定比单线程效率高？不是，多线程会有cpu上下文切换的损耗，已经并发情况下的加锁问题

所以redis的核心是：redis是将所有数据放入内存中，所以说使用单线程去操作内存效率是最高的，对于内存系统来说，如果没有上下文切换的情况下效率是最高的。

数据结构

五种基本数据类型

String
Hash
List
Set
sort Set

三种特殊类型

geospatial地理位置
HyperLogLog 基数统计
Bitmaps 位存储用二进制0 1记录

事务

redis单条命令是保证其原子性的，但是在事务中不保证其原子性

本质是：一组命令的集合，在操作的过程中，事务会按照顺序执行

所有命令在事务中，并没有直接被执行，只有发起执行命令才会被执行。

事务执行完，该事务生命就会结束

redis事务：

开启事务
命令入队 set入队列填写命令
执行事务

multi 开启事务

exec 执行事务

discard 放弃任务

当事务中出现错误时候会分为

编程期异常：代码有问题，命令有错，那么所有的命令都不会执行

运行期异常：事务队列中存在语法性错误，执行命令时，不会影响其他命令，其他命令可以正常进行，错误命令会抛出异常

#编程器异常
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> getset k3    # 错误的命令 
(error) ERR wrong number of arguments for 'getset' command 
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> set k4 v4 
QUEUED 
127.0.0.1:6379> set k5 v5 
QUEUED 
127.0.0.1:6379> exec  # 执行事务报错！ 
(error) EXECABORT Transaction discarded because of previous errors. 
127.0.0.1:6379> get k5  # 所有的命令都不会被执行！ 
(nil)

#运行期异常
127.0.0.1:6379> set k1 "v1" 
OK 
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr k1  # 会执行的时候失败！
QUEUED 
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> INCR k1 # 这条命令逻辑错误（对字符串进行增量）
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> exec
1)  (error) ERR value is not an integer or out of range  # 虽然第一条命令报错了，但是 依旧正常执行成功了！ 
2) OK
3) ok
4) "v2" # 其他命令正常执行
127.0.0.1:6379> get k2 
"v2" 
127.0.0.1:6379> get k3 
"v3"
# 虽然中间有一条命令报错了，但是后面的指令依旧正常执行成功了。
# 所以说Redis单条指令保证原子性，但是Redis事务不能保证原子性。

监控

watch

分为悲观锁和乐观锁

悲观锁：很悲观，认为什么时候都会出现问题，无论错什么都会加锁

乐观锁：认为什么时候都不会出现问题，所以不会上锁，更新数据的时候去判断一下，在此期间是否有人修改过这个数据。

使用watch key监控指定数据，相当于乐观锁加锁

127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> watch money # 监视money对象
OK
127.0.0.1:6379> multi #事务正常结束，数据期间没有发生变动，这个时候正常进行
OK
127.0.0.1:6379(TX)> DECRBY money 20
QUEUED
127.0.0.1:6379(TX)> INCRBY out 20
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 80
2) (integer) 20

多线程修改值，监视失败

###########################3
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> DECRBY money 10
QUEUED
127.0.0.1:6379(TX)> INCRBY out 10
QUEUED
#在执行事务前，另启动一个客户端修改了money的值，再次执行事务就会失败，采用乐观锁的机制，循环比较money的值，如果不同返回失败
127.0.0.1:6379(TX)> exec
(nil)
#############################
#另起k
127.0.0.1:6379> keys *
1) "out"
2) "money"
127.0.0.1:6379> get money
"80"
127.0.0.1:6379> set money 1000
OK