对资源修改，用cas而不是分布式锁，我反对
1:前提是共享资源的修改得提供cas,比如我要更新hdfs,然后再在hbase上更新meta,为了保证一致性，要用分布式锁
2，资源一存储在hbase,支持cas,资源二redis上，二者都支持cas,服务更新数据时要更新二者，服务是多个进城并发干，为了保证一致性，得有分布式锁，单个数据库的cas不行

cas和分布式锁是两个完全不同的东西，cas像是单机的乐观锁，能用cas的话，不用分布式式锁，那不废话吗？能单机干的，谁会上分布式
你跨多个服务，搞一个cas,试试？

文中的令牌和cas，他们间确实类似。但是分布式锁中带令牌，就是为了解决，客户端认为占有锁，到实际锁过期的问题，此时没必要对比cas

文中说的RedLock应该是单节点的lock的实现吧？分布式的应该如下吧？
1. It gets the current time in milliseconds.
2. It tries to acquire the lock in all the N instances sequentially, using the same key name and random value in all the instances. During step 2, when setting the lock in each instance, the client uses a timeout which is small compared to the total lock auto-release time in order to acquire it. For example if the auto-release time is 10 seconds, the timeout could be in the ~ 5-50 milliseconds range. This prevents the client from remaining blocked for a long time trying to talk with a Redis node which is down: if an instance is not available, we should try to talk with the next instance ASAP.
3. The client computes how much time elapsed in order to acquire the lock, by subtracting from the current time the timestamp obtained in step 1. If and only if the client was able to acquire the lock in the majority of the instances (at least 3), and the total time elapsed to acquire the lock is less than lock validity time, the lock is considered to be acquired.
4. If the lock was acquired, its validity time is considered to be the initial validity time minus the time elapsed, as computed in step 3.
5. If the client failed to acquire the lock for some reason (either it was not able to lock N/2+1 instances or the validity time is negative), it will try to unlock all the instances (even the instances it believed it was not able to lock).