Skip to content

修改两处表述 Update Redis transaction explanation in documentation - #2925

Open
StayHungryPlease wants to merge 1 commit into
Snailclimb:mainfrom
StayHungryPlease:patch-2
Open

StayHungryPlease wants to merge 1 commit into
Snailclimb:mainfrom
StayHungryPlease:patch-2

Conversation

@StayHungryPlease

Copy link
Copy Markdown

第一个点:“不满足原子性和持久性”太绝对,建议改成“不提供传统关系型数据库意义上的完整事务原子性和持久性保障”。 Redis官方文档明确表示,事务中的所有命令会被序列化并顺序执行,其他客户端的请求不会在事务执行中间被处理。这确保了命令作为一个隔离的单元连续执行。 即redis具有原子性但没有关系型数据库那种完整的 ACID 原子性。

第二个点:“每条命令都会与 Redis 服务器进行网络交互”——这个说法不准确。
这很容易误导让人理解为:

客户端 → SET
服务器 → 执行
客户端 → SET
服务器 → 执行
客户端 → INCR
服务器 → 执行

实际上,事务是:

客户端 → MULTI
客户端 → SET
客户端 → SET
客户端 → INCR
客户端 → EXEC

MULTI 后面的命令并不会立即执行,而是在 Redis 服务端排队。

真正执行是在 EXEC。

所以网络上确实涉及多条命令请求,但不能理解成:

每条命令都经历一次“发送 → 执行 → 返回 → 再发送下一条”的完整交互。

第一个点:“不满足原子性和持久性”太绝对,建议改成“不提供传统关系型数据库意义上的完整事务原子性和持久性保障”。
Redis官方文档明确表示,事务中的所有命令会被序列化并顺序执行,其他客户端的请求不会在事务执行中间被处理。这确保了命令作为一个隔离的单元连续执行。
即redis具有原子性但没有关系型数据库那种完整的 ACID 原子性。


第二个点:“每条命令都会与 Redis 服务器进行网络交互”——这个说法不准确。
这很容易误导让人理解为:

客户端 → SET
服务器 → 执行
客户端 → SET
服务器 → 执行
客户端 → INCR
服务器 → 执行

实际上,事务是:

客户端 → MULTI
客户端 → SET
客户端 → SET
客户端 → INCR
客户端 → EXEC

MULTI 后面的命令并不会立即执行,而是在 Redis 服务端排队。

真正执行是在 EXEC。

所以网络上确实涉及多条命令请求,但不能理解成:

每条命令都经历一次“发送 → 执行 → 返回 → 再发送下一条”的完整交互。

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant