RESTful分布式锁

设计上，HttpProxy提供了一种新的接入方式，本身是无持久化状态的，它与传统C++ SDK看到的后端是同一个，也就是说后端数据是共享的。设有两个客户端争抢同一把锁（Lock），每个客户端创建一个Lease，然后以Lease作为Owner去创建锁，藉由锁的唯一性确保了同一时间只有一个客户端能抢到锁。锁是一种临时节点，它的生命期与Owner Lease绑定，当持有锁的客户端与Lease的心跳停止后，Lease会在预定时间内超时终结掉自己，其占有的锁也会随之被自动释放掉，以便其他存活的客户端抢占，进而锁的存活性得以确保。

![锁代理请求]](https://s2.ax1x.com/2019/09/26/ueN5uD.png)

Proxy Failover

引入Proxy之后，故障转移（Failover）与先前有所不同。当一台Proxy发生故障之后，客户端只需要将请求转到另外一台Proxy即可。当后端节点发生故障之后，Proxy会与新的后端节点重连并重建会话，这个过程对客户端几乎无感。

Failover时长是衡量Failover性能的重要指标。Proxy引入前，Failover时长主要取决于后端的选举时间和客户端请求超时时长，在引入Proxy之后，Proxy与后端的Failover切换时间也需要考虑在内。一般的停机故障发生时，Proxy能在秒级甚至毫秒级完成Failover，在大多数情况下是客户端无感的。然而，在所有故障类型中，断网是对Failover时长影响最极端的场景。

引入Proxy后对Failover带来的另外一个影响是“写漂移”的问题，我们所谓的“写漂移”是指这样一种情况，客户端发起的请求经过很长时间后到达服务端，与客户端后来重试发起的请求之间产生冲突的问题。引入Proxy之前，“写漂移”的问题是通过TCP耦合的会话机制来防护的。具体地，TCP的顺序性保证了在一个TCP连接的周期内不会出现漂移的乱序问题，当Failover发生的时候，会话的重建过程确保了先前TCP连接上的请求被丢弃，从而避免了“写漂移”问题。在引入Proxy之后，从客户端端到后端拉通了看，有序性被打破了，所以“写漂移”发生是存在可能性的。对于分布式锁而言，无论是Lease的创建和心跳，还是锁的创建和删除，都是满足幂等性条件的，“写漂移”不对此构成正确性问题。