其实锁这种东西，都能能不加就不加，锁会导致程序一定程度上退回到串行化，进而降低效率。
首先，看一个案例，如果要实现一个计数器，并且是多个协程共同进行的，就会出现以下的情况：
每次执行后的计数器结果都是不同的，这是因为计数器本身是被不同的协程抢着+1，会产生多个协程同时拿到numberFlag=N的情况。为了避免这种资源竞争，要对资源进行加锁，使得同一时刻只有一个协程能对资源进行操控。
但是这种锁只能用于你自己的本地服务，一旦出现多服务，比如分布式，微服务，这样的场景，这个锁就没啥用了，这就需要分布式锁。
关于分布式锁，一般的实现就是用redis或者zookeeper实现。redis比较方便的就是大部分的服务都会使用redis，无需额外安装依赖，而zookeeper普通服务用的并不多，即使是kafka也在新版放弃了zookeeper。
zookeeper最大的好处就是可以通过心跳检测客户端的情况，进而避免重复得锁的问题。
但是同时也产生了一些问题，这个心跳检测多久一次，在心跳检测的间隔如果出现了锁超时的问题怎么办，等等。
所以一些服务还是倾向于使用redis来实现分布式锁。
但是这个锁明显有问题:
第一，当A服务（本案例中其实是协程模拟的）拿到锁之后，处理超时了，锁还没有释放，就已经过期，过期后B服务就抢到了锁，此时AB均认为自己拿到了锁
第二，A服务按理说只能去掉自己的服务加上的锁，如果不止是有AB两个服务，有更多的服务，那么A如果出现处理较慢，锁超时后，B服务抢到锁，A又处理完成所有的事释放了锁，那其实是释放掉了B的锁。也就是说，释放锁的时候也必须判断是否是自己的锁
那么就得用redis的lua来保证原子性