至于为什么不使用redis的muti，expire，watch等机制

至于为什么不使用redis的muti，expire，watch等机制

1、Redis事物通过MULTI命令开始。 这条命令总是返回OK。
2、然后用户可以执行多条指令，redis不会马上执行这些指令，还只是放入到队列中。
3、当执行exec指令时，所有的指令执行。
4、调用discard指令，将会flush事物队列，并且退出事物。
如下:redis 127.0.0.1:6379 multiOKredis 127.0.0.1:6379 set foo 1QUEUEDredis 127.0.0.1:6379 incr fooQUEUEDredis 127.0.0.1:6379 incr fooQUEUEDredis 127.0.0.1:6379 exec1) OK2) (integer) 2
3) (integer) 3
如以下：redis 127.0.0.1:6379 multiOKredis 127.0.0.1:6379 set t 13QUEUEDredis 127.0.0.1:6379 lpop tQUEUEDredis 127.0.0.1:6379 exec1) OK2) (error) ERR Operation against a keyholding the wrong kind of value
对于这种err，需要客户端给予合理的提示。
需要注意的是，所有在队列中的指令都会被执行，redis不会终止指令的执行(
事物中有指令失败事物不会终止在这条失败的指令上
)。
三、mutil总是返回OK，然后调用get，set写数据，这些指令会被提交到队列，discard取消命令队列，不执行事物：
Discard为取消命令队列。可以终断一个事物。不会有命令会被执行，并且连接的状态是正常的。
如:SET foo 1OKMULTIOKINCR fooQUEUEDDISCARDOKGET foo"1"
四、redis的optimistic locking using check-and-set(乐观锁)，实现get，set命令序列数据的原子性：
watch指令在redis事物中提供了CAS的行为。
为了检测被watch的keys在是否有多个clients改变时引起冲突，这些keys将会被监控。
例如:一个key自增长(假设redis不提供incr的功能)
val = GET mykey
val = val + 1
SET mykey $val
以上指令执行，如果是单一的client，整个操作是没问题的。如果多个client在同一时间操作。如client A与 client B读取了老的值，假如是10，这个值在两个client将会被增长到11，最后set这个key值时，这个key最终是11还不是12.
watch能够很好的处理这种问题:
WATCH mykey
val = GET mykey
val = val + 1MULTISET mykey $valEXEC使用以上代码，
如果在执行watch与exec指令这段时间里有其它客户端修改此key值，此事物将执行失败。
以上形式的锁被称为乐观锁。

事务操作会锁表,锁库.
不仔细写 容易有坑. 对研发人员的要求较高
不然在大并发情况下 会把DB拖死
所以互联网项目除了电商和金融,基本都是吧事务放在业务层写

不会利用db提供的事务机制

如以上回答内容为低俗、色情、不良、暴力、侵权、涉及违法等信息，可以点下面链接进行举报！

点此我要举报以上问答信息