Redis 扩展：事务和并发竞争 Key 问题

Redis 事务

Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务 (Transaction) 功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的可靠性和安全性。在 Redis 中，事务总是具有原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation），并且当 Redis 运行在某种特定的持久化模式下时，事务也具有持久性（Durability）。

如何解决 Redis 的并发竞争 Key 问题

所谓 Redis 的并发竞争 Key 问题，也就是多个系统同时对一个 key 进行操作，但是最后执行的顺序和期望的顺序不同，这样也就导致了结果的不同！

主流解决方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。（如果不存在 Redis 的并发竞争 Key 问题，尽量不要使用分布式锁，这样会影响性能）

基于 zookeeper 临时有序节点可以实现分布式锁。大致思路为：每个客户端对某个方法加锁时，在 zookeeper 上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取到锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流程后，删除对应的子节点，即释放锁。