做网站app,删除wordpress 后台,网站开发源文件导入,网页编辑软件有哪些?事务特点 Redis 事务可以一次执行多个命令#xff0c; 并且带有以下三个重要的保证#xff1a; 批量操作在发送 EXEC 命令前被放入队列缓存。 收到 EXEC 命令后进入事务执行#xff0c;事务中任意命令执行失败#xff0c;其余的命令依然被执行。不具备原子性。 在事务执…事务特点 Redis 事务可以一次执行多个命令 并且带有以下三个重要的保证 批量操作在发送 EXEC 命令前被放入队列缓存。 收到 EXEC 命令后进入事务执行事务中任意命令执行失败其余的命令依然被执行。不具备原子性。 在事务执行过程其他客户端提交的命令请求不会插入到事务执行命令序列中。 Redis 事务的缺点 不支持回滚 Redis事务在执行EXEC命令之前如果通过WATCH检测到监视的键发生了变化则会拒绝执行整个事务并返回空结果。但请注意这并不是传统数据库中的“回滚”操作因为Redis不会自动撤销已经执行过的命令它仅仅是在事务中止时阻止后续未执行的命令。命令排队一次性执行 在Redis事务中所有命令会被放入一个队列在EXEC命令被执行时按照先进先出的顺序执行期间不能中断或插入新的命令。这意味着事务开始后无法根据中间结果动态调整事务内的操作降低了灵活性。无隔离级别 Redis的事务没有提供如SQL数据库那样的多种事务隔离级别如读已提交、可重复读等。所有事务都是在单线程环境下的串行化执行因此避免了脏读、不可重复读等问题但这也意味着在高并发场景下可能会有性能瓶颈。Watch-Multi-Exec模式的问题 使用WATCH进行乐观锁控制时一旦网络延迟或者客户端异常导致事务未能及时执行监视的数据可能已经被其他客户端修改此时即便事务最终执行也无法保证数据一致性。批量操作不具备完全的原子性 虽然Redis的所有命令在服务器内部是原子执行的但在一个事务中多个命令的组合并不能视为一个原子操作。例如事务中包含对多个key的操作即使其中一个操作失败事务内其它命令也会被执行完毕而不是整体取消。 三个阶段 一个事务从开始到执行会经历以下三个阶段 开始事务。命令入队。执行事务。 案例步骤 从multi 开始一系列操作最后执行 exec 批量执行处理 127.0.0.1:6379 multi OK 127.0.0.1:6379 keys * QUEUED 127.0.0.1:6379 hset person name zhang age 34 QUEUED 127.0.0.1:6379 hdel person age QUEUED 127.0.0.1:6379 hset person email zhangsina.com QUEUED 127.0.0.1:6379 exec 1) 1) listz2) book3) word4) myset5) mydest6) student 2) (integer) 2 3) (integer) 1 4) (integer) 1 127.0.0.1:6379 hgetall person 1) name 2) zhang 下表列出了 redis 事务的相关命令 序号命令及描述1[DISCARD] 取消事务放弃执行事务块内的所有命令。2[EXEC] 执行所有事务块内的命令。3[MULTI] 标记一个事务块的开始。4[UNWATCH] 取消 WATCH 命令对所有 key 的监视。5[WATCH key [key ...]] 监视一个(或多个) key 如果在事务执行之前这个(或这些) key 被其他命令所改动那么事务将被打断。 乐观锁 乐观锁Optimistic Locking是一种在数据库并发控制中的策略它假设多用户同时访问同一数据时发生冲突的概率较低并且在更新数据之前并不立即进行加锁操作。与悲观锁不同的是悲观锁在读取数据时就直接获取并持有锁直到事务结束才释放而乐观锁则是 读取阶段当一个事务想要修改数据时它不会立即锁定该数据行。每个事务在读取数据时都会记录下当时的数据版本号或时间戳等信息。验证阶段在事务提交更新操作前会再次检查当前要更新的数据是否自上次读取以来没有被其他事务修改过。这通常通过比较数据的版本号来实现如果版本号未变则认为可以安全地执行更新。更新阶段如果数据版本验证通过即版本号仍为事务开始读取时的版本则执行更新操作并将数据版本号递增确保后续的并发事务能够识别出这次更新。如果发现版本号已被改变说明存在并发修改此时乐观锁机制会让当前事务回滚并提示并发错误通常需要重新读取数据并尝试更新。 Redis 乐观锁 Redis 乐观锁是一种在分布式系统中实现并发控制的机制它借鉴了数据库领域的乐观并发控制思想并通过Redis提供的命令来实现。在乐观锁策略下假定多个客户端同时访问同一数据时通常不会发生冲突或至少冲突的概率较低。因此在读取数据时不立即加锁而是在更新数据前才去检查在此期间是否有其他客户端修改过该数据。 在Redis中乐观锁主要通过WATCH命令和事务multi/exec来实现 WATCH命令客户端使用WATCH命令监视一个或多个键这些键的数据状态将被记录下来。当执行WATCH后如果任何被监视的键在事务提交前发生了变化则整个事务将会被打断即不会执行EXEC命令内的操作。事务处理客户端可以将一系列命令放入事务中使用MULTI开始一个事务块然后执行一系列的操作指令。最后用EXEC命令尝试提交事务。只有在所有被WATCH的键自WATCH以来未被其他客户端改变的情况下事务中的命令才会被执行。 举例来说 客户端A对一个键进行WATCH。然后客户端A开始一个事务并准备修改这个键的值。在事务提交EXEC之前如果其他客户端改变了该键的值那么客户端A的事务在执行EXEC时会发现数据已经被修改从而导致事务回滚不执行任何操作。 下面具体来举例 主要是 watch 和 multi 两个命令配合使用实现乐观锁 watch 监视某一个可能变化的 key。然后开启事务一系列操作放入队列等待执行如果在exec 执行事务之前其他的客户端对监视的key 做了修改则exec 执行结果为nil 。什么都不执行。 127.0.0.1:6379 watch mm #### 开始监视 mm 变量 OK 127.0.0.1:6379 multi #### 开启事务 OK 127.0.0.1:6379 incrby mm 500 #### 第一次 给 mm 加500 操作放入队列 QUEUED 127.0.0.1:6379 incrby mm 500 #### 第二次 给 mm 加500 操作放入队列 QUEUED ### 此时去另一个客户端执行修改操作另一个客户端的修改操作 127.0.0.1:6379 decrby mm 500 #### 给 mm 减去500 (integer) -500 #### 立即起效结果为 -500 然后再回原来执行事务的客户端执行下面操作 127.0.0.1:6379 exec #### 开始执行事务 (nil) #### 没有任何执行结果 因为乐观锁起作用了 127.0.0.1:6379 get mm #### 再次查看结果 -500 #### 是另一个客户端的执行结果。刚才加的两次500 无效。 127.0.0.1:6379 watch mm #### 再次监控 OK 127.0.0.1:6379 multi #### 开启事务 OK 127.0.0.1:6379 incrby mm 500 #### 加500 QUEUED 127.0.0.1:6379 incrby mm 500 #### 加500 QUEUED 127.0.0.1:6379 exec #### 执行事务 1) (integer) 0 2) (integer) 500 #### 执行成功因为其他客户端没有修改被监视的变量 mm . 127.0.0.1:6379