1 Redis 事务
redis的事务是一个单独隔离的操作，它会将一系列指令按需排队并顺序执行，期间不会被其他客户端的指令插队。
1 三大指令：
- mutil：开启事务
- exec：执行事务
- discard：取消事务
127.0.0.1:6379> set name1 zhangsan
QUEUED
127.0.0.1:6379> set name2 lisi
QUEUED
127.0.0.1:6379> exec
\1) OK
\2) OK
127.0.0.1:6379> get name1
"zhangsan"
127.0.0.1:6379> get name2
"lisi"
2 事务的错误与回滚
事物的错误与回滚分别有组队时错误和执行命令时错误两种情况
1 组队时错误
我们在组队时输入错误的指令，redis会之间将所有指令都会失效。
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name1 zhangsan
QUEUED
127.0.0.1:6379> set name2 lisi
QUEUED
127.0.0.1:6379> set name3
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> set name4 wangwu
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get name1
(nil)
127.0.0.1:6379> get name2
(nil)
127.0.0.1:6379> get name3
(nil)
127.0.0.1:6379> get name4
(nil)
2 执行时错误
他在按序处理所有指令，遇到错误就按正常流程处理继续执行下去。
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name1 zhangsan
QUEUED
127.0.0.1:6379> incr name1
QUEUED
127.0.0.1:6379> set name2 lisi
QUEUED
127.0.0.1:6379> exec
\1) OK
\2) (error) ERR value is not an integer or out of range
\3) OK
127.0.0.1:6379> get name1
"zhangsan"
127.0.0.1:6379> get name2
"lisi"
2 Redis的乐观锁
Redis就是通过CAS(check and set)/Compare and Swap实现乐观锁的，通过watch指令监听一个或者多个key值，当用户提交修改key值的事务时，会检查监听的key是否发生变化。若没有发生变化，则提交成功。
CAS（Compare and Swap）是一种乐观锁机制，经常在并发控制中使用，以确保数据的一致性。下面是一种使用Redis实现CAS操作的例子，以一个简单的计数器为例：
目标：多个并发客户端尝试增加名为counter的整数计数器。
步骤：
-
WATCH命令
客户端使用WATCH命令监视counter键，以便在事务执行前检查它是否被其他客户端修改。WATCH counter这将使得客户端在事务执行前监视
counter键，如果该键被其他客户端修改，事务将被取消。 -
MULTI命令
使用MULTI命令开启一个Redis事务。MULTI这个命令表示开始一个事务，之后的所有命令将被添加到事务队列中，不会立即执行，直到
EXEC命令被调用。 -
读取旧值
在事务中，客户端读取counter的当前值，作为旧值。GET counter如果此时
counter的值是5，那么客户端获取到的旧值就是5。 -
计算新值
客户端在本地计算出新的计数器值，例如将旧值加1。old_value = 5 new_value = old_value + 1 # 新值为6 -
尝试更新
客户端将计算得到的新值放入SET命令中，准备执行CAS操作。SET counter new_value这个命令将在事务中设置
counter的新值为6。 -
EXEC命令
使用EXEC命令提交事务。如果在WATCH和EXEC之间被监视的counter键没有被其他客户端修改，事务将成功执行，新值将被写入counter。EXEC
WATCH counter监视counter，确保在事务期间没有其他客户端修改它。MULTI开始事务。GET counter再次检查counter的当前值，确保在事务开始前没有其他客户端修改。SET counter new_value尝试更新counter的值。EXEC提交事务。如果counter在WATCH与EXEC之间未被修改，更新将成功，否则事务将失败。
结果：
- 成功：如果
counter在CAS操作期间未被其他客户端修改，该操作会成功，counter将更新为新值（例如6）。 - 失败：如果
counter在CAS操作期间被其他客户端修改，该操作会失败。此时，客户端可以选择重试整个流程或采取其他措施。
通过这种方式，即使多个客户端并发尝试修改counter，每次只有一个客户端可以成功。这确保了counter的数据一致性和并发安全性。
3 Redis的hahs槽
Redis哈希槽是Redis集群的核心概念之一。在Redis集群中，数据会被分布在不同的节点上，而哈希槽则是用来划分数据所在节点的逻辑单位。哈希槽的数量是固定的，Redis默认将其划分为16384个槽位。
当一个新的节点加入Redis集群时，集群会将部分哈希槽从已有节点上迁移至新节点上，直到集群中所有节点的哈希槽数量都比较平均。当有数据需要存储时，Redis会根据数据的键值对应的哈希值，将其映射到一个哈希槽中，并根据哈希槽的分布情况，将数据存储到相应的节点上。哈希槽的使用使得Redis集群可以更加高效地进行数据存储和访问，同时还能够实现数据的分布式存储和负载均衡。
4 Redis是否支持事务? redis操作是否是原子操作？
🌟Redis 支持事务。Redis 的事务是通过 MULTI/EXEC 命令来实现的。
可以使用 MULTI 命令来开始一个事务，然后在事务中执行多个命令，最后通过 EXEC 命令来执行这些命令并将结果返回。
事务可以保证在执行期间不会被其他客户端的命令所打断
🌟Redis 的操作是原子的，Redis 中的每个命令都是原子执行的，要么全部执行成功，要么全部失败，中间不会被其他命令所影响。
但是要注意的是**，在使用 Redis 事务时，事务中的多个命令并不保证原子性，只有在执行 EXEC 命令后才会被作为一个原子操作来执行**。
5 Redis开发中使用流程
1 基本流程
2 Redis分布式缓存、分布式锁、布隆过滤器基本流程
✨✨Redis做分布式缓存存在的问题、缓存击穿、缓存穿透、缓存雪崩、数据一致性问题见之前的文章：一窥：分布式、分布式缓存、分布式锁及其延申_NIIMP的博客-CSDN博客
6 Redis主从复制
单节点Redis的并发能力是有限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。在Redis中，集群中的Redis实例多是以主从关系存在。通常只有一个主机，多个从机。那么Redis为什么要做成这种主从的集群？而不是负载均衡的集群呢？这是因为Redis中一般都是读操作多于写操作。主机（master）负责写操作，从机（slave）负责读操作，这样大大的提高的Redis的读写性能。
7 开发中Redis加了分布式锁为啥还需要使用lua保持原子性?
🌟防止多个线程获取到同一个分布式锁而导致数据不一致
在使用 Redis 的分布式锁时，通常会将锁的获取和释放操作分别作为两个 Redis 命令执行。
但是，这种方式可能存在并发问题，因为在执行获取锁和释放锁的两个命令之间，其他线程或进程可能会获取到同一个锁而导致竞争条件。
为了解决这个问题，可以使用 Redis 的 Lua 脚本来确保获取和释放锁的操作是原子性的。Lua 脚本是 Redis 内置的脚本语言，并且在执行期间会被 Redis 以单线
程的方式执行，因此可以保证在脚本执行期间不会被其他操作打断。
假设有两个线程A和B同时执行一段代码，并且这段代码需要获取一个名为"counter"的锁来对一个计数器进行操作。代码如下所示：
lock.acquire() # 获取锁
# 临界区
counter += 1
lock.release() # 释放锁
线程A执行到lock.acquire()时获取到了锁，并且进入了临界区，执行counter += 1。但是在执行lock.release()之前，线程调度器可能会切换到线程B上，
此时线程B也执行到了lock.acquire()。
如果不处理竞争条件，线程B也能够获取到同一个锁，并且进入临界区修改计数器。然后线程A继续执行lock.release()来释放锁，接着线程B也执行
lock.release()来释放锁。
这样一来，计数器只增加了1，而不是2。因为在两个线程之间没有保证同步，它们对于共享资源的修改发生了竞争。
为了解决这个问题，可以使用锁机制来确保在同一时间只有一个线程可以访问临界区。当一个线程获取到锁后，其他线程将被阻塞，直到该线程释放锁。这样可以
保证每个线程在执行临界区代码时是互斥的，避免了竞争条件的出现。
扫一扫
972
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
