Redis：事务（transaction） - 版本历史

Eijux：Eijux移动页面Redis：事务至Redis：事务（transaction），不留重定向

2021-11-02T17:10:32Z

Eijux移动页面Redis：事务至Redis：事务（transaction），不留重定向

←上一版本	2021年11月3日 (三) 01:10的版本
（没有差异）

Eijux：/* Redis事务复杂情况实现 */

2021-11-02T14:43:24Z

Redis事务复杂情况实现

←上一版本		2021年11月2日 (二) 22:43的版本
第148行：		第148行：
	</syntaxhighlight>		</syntaxhighlight>

	== ~~Redis事务复杂情况实现~~ ==		== WATCH ==
			WATCH 使得 EXEC 命令需要有条件地执行：事务只能在所有被监视键都没有被修改的前提下执行，如果这个前提不能满足的话，事务就不会被执行。

	~~=== 悲观锁 ===~~
	悲观锁（Pessimistic Lock）：每次去拿数据的时候都认为别人会修改该数据，所以每次在拿数据的时候都会先上锁，这样别人想拿这个数据就会 block 阻塞直到它拿到锁。
	* 传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，让别人无法操作该数据。

	~~=== 乐观锁 ===~~		监视的使用'''【注意】'''：
	乐观锁（Optimistic Lock）：每次去取数据的时候都认为别人不会修改该数据，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这条数据，一般使用'''~~版本号机制~~'''~~（类比于MySQL的“MVCC”）进行判断。~~		* WATCH 命令可以被调用多次。对键的监视从 WATCH 执行之后开始生效，直到调用 EXEC 为止。
	* ~~乐观锁适用于多读的应用类型，这样可以提高吞吐量。~~		* 还可以在单个 WATCH 命令中监视任意多个键：
	* ~~乐观锁大多数情况是基于数据版本号（version）的机制实现的：为数据增加一个版本标识。~~		*: <syntaxhighlight lang="bash" highlight="">
	*: 在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个“version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加 1。此时，将提交数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据，不予更新。		redis> WATCH key1 key2 key3
			OK
			</syntaxhighlight>
			* 如果使用 WATCH 监视了一个带过期时间的键，那么即使这个键过期了，事务仍然可以正常执行。


	~~乐观锁实现举例：~~		监视的取消'''【注意】'''：
	~~: [[File:乐观锁实现举例.png\|600px]]~~		* 当 EXEC 被调用时，不管事务是否成功执行，对所有键的监视都会被取消。
			* 使用无参数的 UNWATCH 命令可以手动取消对所有键的监视。
			* 当客户端断开连接时，该客户端对键的监视也会被取消。

	~~=== '''watch 机制'''实现乐观锁 ===~~
	~~监视一个（或多个）key ，'''如果在事务exec执行之前这个（或这些）key 被其他命令所改动，那么事务将被打断'''。~~

			=== 使用 Watch 实现 ZPOP ===
			WATCH 可以用于创建 Redis 没有内置的原子操作。

	~~示例：~~
	~~# set k1 1：设置 k1 值为 1；~~		示例：以下代码实现了原创的 ZPOP 命令，它可以原子地弹出有序集合中分值（score）最小的元素：
	~~# watch k1：监视 k1；【开始监视 k1，则其他客户端或事务不能修改 k1 的值】~~		<syntaxhighlight lang="bash" highlight="">
	~~# set k1 2：设置 k1 值为 2；~~		WATCH zset
	~~# multi：开始事务；~~		element = ZRANGE zset 0 0
	~~# set k1 3：修改 k1 值为 3；~~		MULTI
	~~# exec：提交事务；~~		ZREM zset element
	~~如上，k1 的值仍然是 2，而不会被修改为 3，因为在事务开启之前 k1 的值被修改了；~~		EXEC
			</syntaxhighlight>
			程序只要重复执行这段代码，直到 EXEC 的返回值不是多条空回复（null multi-bulk reply）即可。

			=== 使用 Watch 操作实现乐观锁（check-and-set） ===
			WATCH 命令可以为 Redis 事务提供 check-and-set（CAS）行为：
			被 WATCH 的键会被监视，并会发觉这些键是否被改动过了：
			如果有至少一个被监视的键在 EXEC 执行之前被修改了，那么整个事务都会被取消，EXEC 返回空多条批量回复（null multi-bulk reply）来表示事务已经失败。


			举个例子，假设我们需要原子性地为某个值进行增 1 操作（假设 INCR 不存在）。
			: 首先我们可能会这样做：
			: <syntaxhighlight lang="bash" highlight="">
			val = GET mykey
			val = val + 1
			SET mykey $val
			</syntaxhighlight>
			: 上面的这个实现在只有一个客户端的时候可以执行得很好。但是，当多个客户端同时对同一个键进行这样的操作时，就会产生竞争条件：
			:: 比如：客户端 A 和 B 都读取了键原来的值，比如 10，那么两个客户端都会将键的值设为 11，但正确的结果应该是 12 才对。


			有了 WATCH，我们就可以轻松地解决这类问题了：
			: <syntaxhighlight lang="bash" highlight="">
			WATCH mykey

			val = GET mykey
			val = val + 1

			MULTI
			SET mykey $val
			EXEC
			</syntaxhighlight>
			: 使用上面的代码，如果在 WATCH 执行之后， EXEC 执行之前，有其他客户端修改了 mykey 的值，那么当前客户端的事务就会失败。程序需要做的，就是不断重试这个操作，直到没有发生碰撞为止。


			这种形式的锁被称作乐观锁，它是一种非常强大的锁机制。并且因为大多数情况下，不同的客户端会访问不同的键，碰撞的情况一般都很少，所以通常并不需要进行重试。

			== Redis 脚本和事务 ==
			从定义上来说， '''Redis 中的脚本本身就是一种事务'''，所以任'''何在事务里可以完成的事，在脚本里面也能完成'''。并且一般来说，使用脚本要来得更简单，并且速度更快。

			因为脚本功能是 Redis 2.6 才引入的，而事务功能则更早之前就存在了，所以 Redis 才会同时存在两种处理事务的方法。

	== FAQ ==		== FAQ ==

2021年11月2日 (二) 13:10 Eijux

2021-11-02T13:10:27Z

@@ 第16行： / 第16行： @@
   从 2.2 版本开始，Redis 还可以通过'''乐观锁'''（optimistic lock）实现 '''CAS''' （check-and-set）操作。
 == 事务命令 ==
@@ 第210行： / 第178行： @@
 == FAQ ==

Eijux：/* 事务中的错误 */

2021-11-02T13:04:01Z

事务中的错误

←上一版本		2021年11月2日 (二) 21:04的版本
第124行：		第124行：

	== 事务中的错误 ==		== 事务中的错误 ==
	~~=== 事务情况【？？？】 ===~~		使用事务时可能会遇上两种错误：
	~~Redis 事务不支持回滚，'''如果遇到问题，会继续执行余下的命令'''。~~		# 在执行 EXEC 之前，命令入队出错。
	* '''只有语法错误，Redis 才会执行失败'''。		#: 比如：命令可能会产生语法错误（参数数量错误，参数名错误，等等）；或者其他更严重的错误，比如内存不足（如果服务器使用 maxmemory 设置了最大内存限制的话）。
			# 在执行 EXEC 之后，命令执行出错。
			#: 比如：事务中的命令可能处理了错误类型的键，比如将列表命令用在了字符串键上面，诸如此类。

			=== 在执行 EXEC 之前，命令入队出错 ===
			命令入队时出错，将会导致'''放弃事务'''：
			<pre>
			对于发生在 EXEC 执行之前的错误，客户端以前的做法是检查命令入队所得的返回值：如果命令入队时返回 QUEUED ，那么入队成功；否则，就是入队失败。

	~~正常情况：~~		如果有命令在入队时失败，那么大部分客户端都会停止并取消这个事务。
	~~# MULTI：用MULTI命令告诉Redis，接下来要执行的命令你先不要执行，而是把它们暂时存起来【开启事务】~~
	~~# SADD "user1" 2：第一条命令进入等待队列【命令入队】~~
	~~# SADD "user2" 1：第二条命令进入等待队列【命令入队】~~
	~~# EXEC：告知redis执行前面发送的两条命令【提交事务】~~


	~~异常情况：【？？？】~~		1、在 Redis 2.6.5 以前， Redis 只执行事务中那些入队成功的命令，而忽略那些入队失败的命令。而新的处理方式则使得在流水线（pipeline）中包含事务变得简单，因为发送事务和读取事务的回复都只需要和服务器进行一次通讯。
	~~# MULTI：正常命令~~		2、从 Redis 2.6.5 开始，服务器会对命令入队失败的情况进行记录，并在客户端调用 EXEC 命令时，拒绝执行并自动放弃这个事务。
	~~# SET key value：正常命令~~		</pre>
	~~# SET key：命令语法错误~~
	~~# EXEC：无法执行事务，那么第一条正确的命令也不会执行，所以key的值不会设置成功~~


	~~例外情况：~~		示例：
	~~# MULTI：正常命令~~		: 因为调用 INCR 命令的参数格式不正确，所以这个 INCR 命令入队失败：
	~~# SET key v1：正常命令~~		: <syntaxhighlight lang="bash" highlight="">
	# INCR ~~key：此命令错误，字符串不能自增~~		MULTI
	~~# EXEC：~~		+OK
	~~## 事务依然提交了，key的值被设置为v1，自增操作执行失败，但整个事务没有回滚~~
	~~## 可以放弃事务：discard~~

			INCR a b c
			-ERR wrong number of arguments for 'incr' command
			</syntaxhighlight>

	~~放弃情况：~~		=== 在执行 EXEC 之后，命令执行出错 ===
	~~# MULTI：开启事务~~		命令执行期间出错，'''事务队列中的其他命令将会继续执行'''：
	~~# SET age 25：命令入队~~		<pre>
	~~# SET age 30：命令入队~~		至于那些在 EXEC 命令执行之后所产生的错误，并没有对它们进行特别处理：即使事务中有某个/某些命令在执行时产生了错误，事务中的其他命令仍然会继续执行。
	~~# DISCARD：放弃事务，则命令队列不会被执行~~		</pre>


			示例：
			: LPOP 命令的执行将出错，尽管调用它的语法是正确的：
			: <syntaxhighlight lang="bash" highlight="">
			MULTI
			+OK

			SET a 3
			abc

			+QUEUED
			LPOP a

			+QUEUED
			EXEC

			*2
			+OK
			-ERR Operation against a key holding the wrong kind of value
			</syntaxhighlight>

	== Redis事务复杂情况实现 ==		== Redis事务复杂情况实现 ==

Eijux：/* 事务命令 */

2021-11-02T12:48:26Z

事务命令

←上一版本		2021年11月2日 (二) 20:48的版本
第66行：		第66行：
	** 这些命令被放到一个'''队列'''中，当 EXEC 命令被调用时，队列中的所有命令才会被按序执行。		** 这些命令被放到一个'''队列'''中，当 EXEC 命令被调用时，队列中的所有命令才会被按序执行。
	\|-		\|-
	\| EXEC \|\| ~~执行所有事务块内的命令。~~		\| EXEC \|\| 执行事务内所有的命令。
	* 如果没有成功执行 EXEC（因为断线等），那么事务中的所有命令都不会被执行；如果成功执行 EXEC，那么事务中的所有命令都会被执行。		* 如果没有成功执行 EXEC（因为断线等），那么事务中的所有命令都不会被执行；如果成功执行 EXEC，那么事务中的所有命令都会被执行。
	* 其回复是一个数组，数组中的每个元素都是执行事务中的命令所产生的回复（回复元素的先后顺序和命令发送的先后顺序一致）。		* 其回复是一个数组，数组中的每个元素都是执行事务中的命令所产生的回复（回复元素的先后顺序和命令发送的先后顺序一致）。
	\|-		\|-
	\| DISCARD \|\| ~~取消事务，放弃执行事务块内的所有命令。~~		\| DISCARD \|\| 取消事务。
	* ~~事务队列会被清空，并且客户端会从事务状态中退出。~~		* 事务会被放弃，事务队列会被清空，并且客户端会从事务状态中退出。
	\|-		\|-
	\| WATCH key [key ...] \|\| 监视一个（或多个) ~~key ，如果在事务执行之前这个（或这些~~) key ~~被其他命令所改动，那么事务将被打断。~~		\| WATCH key [key ...] \|\| 监视一个（或多个) key。
	* 事务只能在所有被监视键都没有被修改的前提下执行，如果这个前提不能满足的话，事务就不会被执行。		* 如果在事务执行之前这个（或这些) key 被其他命令所改动，那么事务就不会被执行。
	\|-		\|-
	\| UNWATCH \|\| 取消 WATCH 命令对所有 key 的监视。		\| UNWATCH \|\| 取消 WATCH 命令对所有 key 的监视。

2021年11月2日 (二) 12:44 Eijux

2021-11-02T12:44:46Z

显示更改

2021年10月16日 (六) 09:36 Eijux

2021-10-16T09:36:59Z

←上一版本		2021年10月16日 (六) 17:36的版本
第2行：		第2行：

	== 什么是事务？ ==		== 什么是事务？ ==
	事务：是指一系列操作步骤，要么完全地执行，要么完全地不执行。 <br/>		<pre>
			事务：是指一系列操作步骤，要么完全地执行，要么完全地不执行。
			</pre>
			事务可以一次执行多个命令，并且带有以下两个重要的保证：
			# 事务是一个单独的'''隔离操作'''：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
			# 事务是一个'''原子操作'''：事务中的命令要么全部被执行，要么全部都不执行。


	Redis 中的事务（transaction）是一组命令的集合，至少是两个或两个以上的命令，redis 事务保证这些命令被执行时中间不会被任何其他操作打断。<br/>		Redis 中的事务（transaction）是一组命令的集合，至少是两个或两个以上的命令，redis 事务保证这些命令被执行时中间不会被任何其他操作打断。<br/>


	~~示例：微博中，A 用户关注了 B 用户，那么 A 的关注人列表里面就会有 B 用户，B 的粉丝列表里面就会有 A 用户。~~
	~~: 这个关注与被关注的过程是由一系列操作步骤构成：~~
	~~# A 用户添加到 B 的粉丝列表里面；~~
	~~# B 用户添加到 A 的关注列表里面；~~
	~~这两个步骤必须全部执行成功，整个逻辑才是正确的，否则就会产生数据的错误，比如A用户的关注列表有B用户，但B的粉丝列表里没有A用户；~~

	== Redis事务控制 ==		== Redis事务控制 ==

Eijux：/* 事务命令 */

2021-10-16T07:26:38Z

事务命令

←上一版本		2021年10月16日 (六) 15:26的版本
第31行：		第31行：

	=== 事务命令 ===		=== 事务命令 ===
	~~'''MULTI''' 、 '''EXEC''' 、 '''DISCARD''' 和 '''WATCH''' 是 Redis 事务的基础。~~
	{\| class="wikitable"		{\| class="wikitable"
	! 命令 !! 描述		! 命令 !! 描述

Eijux：/* 事务命令 */

2021-10-16T07:25:57Z

事务命令

@@ 第31行： / 第31行： @@
 === 事务命令 ===
 {| class="wikitable"
 ! 命令 !! 描述
@@ 第44行： / 第45行： @@
 | UNWATCH || 取消 WATCH 命令对所有 key 的监视。
 |}
 === 事务示例 ===

Eijux：/* Redis事务控制 */

2021-05-11T18:36:52Z

Redis事务控制

←上一版本		2021年5月12日 (三) 02:36的版本
第17行：		第17行：
	# 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。		# 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
	# 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。		# 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。


			注意：
			* '''Redis 事务不支持回滚'''。（支持回滚的复杂操作会使 Redis 放弃其简单高效的特性）
			* '''Redis 事务不保证原子性'''。（该成功的成功，该失败的失败）


第24行：		第29行：
	# 执行事务。		# 执行事务。


	~~注意：~~
	* '''Redis 事务不支持回滚'''。（支持回滚的复杂操作会使 Redis 放弃其简单高效的特性）
	* '''Redis 事务不保证原子性'''。（该成功的成功，该失败的失败）

	=== 事务命令 ===		=== 事务命令 ===

Redis：事务（transaction） - 版本历史

Eijux：​Eijux移动页面Redis：事务至Redis：事务（transaction），不留重定向

Eijux：​/* Redis事务复杂情况实现 */

2021年11月2日 (二) 13:10 Eijux

Eijux：​/* 事务中的错误 */

Eijux：​/* 事务命令 */

2021年11月2日 (二) 12:44 Eijux

2021年10月16日 (六) 09:36 Eijux

Eijux：​/* 事务命令 */

Eijux：​/* 事务命令 */

Eijux：​/* Redis事务控制 */

Eijux：Eijux移动页面Redis：事务至Redis：事务（transaction），不留重定向

Eijux：/* Redis事务复杂情况实现 */

Eijux：/* 事务中的错误 */

Eijux：/* 事务命令 */

Eijux：/* 事务命令 */

Eijux：/* 事务命令 */

Eijux：/* Redis事务控制 */