Redis 乐观锁的实际使用场景是什么？是不是没用？

如题，redis 通过 watch/multi 事务实现乐观锁，通过 setnx 实现悲观锁，大概看了看介绍感觉乐观锁没啥用啊，因为 redis 的事务只保证连续执行而不保证原子执行，事务里的操作可以有若干步成功加若干步失败同时存在，那还有啥用呢？

个人看法下乐观锁的使用场景是，首先需要是分布节点同步状态，单节点下无需使用 redis 同步。其次该需求需要上锁，且乐观锁能解决，且乐观锁方案效率比悲观锁高。想了一圈没想出来啥场景符合上述要求。

A. 比如一个普通的多进程同步状态需求，比如对以账号为单位对接口进行流量限制，那么统计一个账号访问过一个接口，只需要给该账号对应的 key 执行 incr 就可以表示访问次数+1 ，由于本身是原子的， 多个节点同时执行也不存在需不需要锁的问题。

B. 再比如网上常见举例的秒杀需求，比如 10000 个线程选出 10 个秒杀成功的。只需要将 token 设为 10 ，然后每个线程里 decr 不就行了，由于 decr 返回的是执行成功后的结果，10000 个线程分别获取的值将会是 10 到-9990 ，只需要业务线程判断自己的回文是否大于 0 不就可以判断自己是否成功抢到了秒杀，同样也不需要锁。

所以 redis 的乐观锁有啥用？

=========================

顺便吐槽一下 redis 在 py 的支持，官方支持搞了个同步库，既然用 redis 了肯定是注重效率的应用，搞同步是不是完全没人用。。。异步版本最近才加入，我试了半天也没试明白异步下如何成功调用 watch+multi 事务。。。