事务锁：
mulit、exec、discard
从输入multi命令开始，输入的命令都会依次进入命令队列中，
但不会执行，直到输入exec后开始依次执行,discard是放弃组队执行
组队阶段报错，提交都会失败，
组队阶段不报错，提交有成功有失败
并行：多个CPU同时执行多个任务，比如:多个人同时做不同的事 并发：一个CPU（采用时间片）同时执行多个任务，比如秒杀平台，多个人做同件事
悲观锁（Pessimistic Lock）：
mysql的可串化，都是在操作之前先上锁让别人无法操作该数据。比较适合写入操作比较频繁的场景，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。
乐观锁（Optimistic Lock）：
每次获取数据的时候，都不会担心数据被修改，所以每次获取数据的时候都不会进行加锁，但是在更新数据库中的数据时需要判断该数据是否被别人修改过。如果数据被其他线程修改，则不进行数据更新，如果数据没有被其他线程修改，则进行数据更新。由于数据没有进行加锁，期间该数据可以被其他线程进行读写操作。
**一般使用版本号机制进行判断。**乐观锁大多数情况是基于数据版本号（version）的机制实现的。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个“version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加1。此时，将提交数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据，不予更新。
比较适合读取操作比较频繁的场景，如果出现大量的写入操作，数据发生冲突的可能性就会增大，为了保证数据的一致性，应用层需要不断的重新获取数据，这样会增加大量的查询操作，降低了系统的吞吐量。
总结：两种所各有优缺点，读取频繁使用乐观锁，写入频繁使用悲观锁。
像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适,之所以用悲观锁就是因为两个用户更新同一条数据的概率高，也就是冲突比较严重的情况下，所以才用悲观锁.
悲观锁比较适合强一致性的场景，但效率比较低，特别是读的并发低。乐观锁则适用于读多写少，并发冲突少的场景。
Redis的watch机制实现乐观锁**watch:**监视一个(或多个) key ，如果在事务exec执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
下面这个例子：我们在观察的时候k1值为1，但是事务执行的时候k1值为2，k1被修改了所以不能执行事务。
**unwatch *取消
