二、开启事务
- 单独的隔离操作：事务中的所有命令都会序列化。按顺序地执行。事务在执行的过程中不会被其他客户端发送过来的命令请求所打断
- 没有隔离级别的概念：队列中的命令没有提交执行都不会被执行，因为事务提交前任何指令都不会被执行
- 不保证原子性：事务中如果有一条命令执行失败，气候的命令仍然会被执行，没有回滚
Multi：开启一个事务，将之后的命令加入队列中，但并不会执行这些命令
Exec ：执行该命令时，提交队列中的命令，队列中的所有命令按顺序执 行，如果执行过程中出现错误，也不会进行回滚。redis 事务不具备原子性
discard：取消队列中的命令，或者说取消事务
示例：
Multi set key1 val1 set key2 val2 Exec
1、组队过程中如果出现错误，则取消组队，队列中的命令没有被提交
如下 set key2 在组队过程中出现语法错误，执行 exec 命令时由于语法错误无法提交，导致事务被丢弃（注意这个不是回滚）
Multi set key1 val1 set key2 set key3 val3 Exec
2、如果组队成功，但执行过程有失败的，则只有失败的执行不超过，其他执行成功
如下 incr key1 在组队过程中没有出现语法错误，执行 exec 命令时可以正常提交事务,执行过程中由于 key1 不是数值，所以 incr key1 执行失败，但不会影响后面命令的正常执行；
执行每一条命令时都是独立操作，即使其中的某个命令出错也不影响其他命令的正常执行
Multi set key1 val1 incr key1 set key2 val2 Exec三、乐观锁和悲观锁
乐观锁：
每次获取数据的时候，都不会担心数据被修改，所以每次获取数据的时候都不会进行加锁，但是在更新数据库中的数据时需要判断该数据是否被别人修改过。如果数据被其他线程修改，则不进行数据更新，如果数据没有被其他线程修改，则进行数据更新。由于数据没有进行加锁，期间该数据可以被其他线程进行读写操作
悲观锁：
每次获取数据的时候，都会担心数据被修改，所以每次获取数据的时候都会进行加锁，确保在自己使用的过程中数据不会被别人修改，使用完成后进行数据解锁。由于数据进行加锁，期间对该数据进行读写的其他线程都会进行等待。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁、表锁、读锁、写锁等。都是在操作之前先上锁让别人无法操作该数据
redis 中通过 watch 实现乐观锁
- 在执行multi之前，执行 watch key1 [key2],可以监视一个（或多个）key,如果在事务执行之前这个（或这些）key被其他命令所改动，那么整个事务将会执行失败
- watch原理：给key加一个version,在watch期间当有其他命令修改key值时，key的version就会发生改变，那么在 multi + exec 过程中由于version不一致导致 multi + exec 失败
示例：
watch key1 Multi set key1 val1 set key2 val2 Exec
测试：
当修改 key1 的值时,set key1 val1 失效，set key2 val2 正常执行
没有监听key2,但当修改 key2 的值时,set key1 val1 正常执行，set key2 val2 失效
