at any snapshot in time no two clients think they hold the same lock is based on the following assumptions: bounded network delay, bounded process pauses and bounded clock error.

[client 自己需要主动去检查 lock 的有效性] 这是一个异步操作，发生请求检查锁有效，到接收到锁有效返回，这个是有网络延迟的，你接收的锁有效的消息可能是过期的，锁已经超时释放掉了。

你给的那个 stackoverflow 下面还贴了一个 GC 暂停的案例 https://cwiki.apache.org/confluence/display/CURATOR/TN10

解决不了，记得好像已经证明了没有安全的分布式锁。
分布式锁在异步系统中是一个根本不安全的概念。
分布式锁只能在正确性和活跃性二选一。

通俗来讲，如果进程在持有锁时崩溃，为了不造成死锁，会设置锁失效时间。
但是，如果进程实际上并没有死，而只是暂停或无法访问，那么锁失效会导致它被其他进程持有。暂停的进程恢复运行会以为自己还持有锁。

https://jepsen.io/analyses/etcd-3.4.3

Vitess

被币安收购了

SE2 有电池加密了吧，只能到官方更换了

1. https 解决的是数据加密传输中间人攻击，加签 /验签是业务逻辑需要对接口确认调用者是否有权限。

2. 没看明白，权限是属于业务逻辑。

3. http 是无状态协议请求需要带上状态做鉴权，本质无差别。

4. 服务器验证客户端。

5. 看具体 API 设计，抓包不能解密 https 数据，除非有证书私钥，浏览器 F12 ，请求都是你自己浏览器发的为什么不能看？ https 解决的是你不能看别人发的请求。


加签 /验签 主要是做开发 API 鉴权，是那个开发者调用了 API ，仿制任意人调用。HTTPS 解决数据加密传输，传输过程中不被篡改。

@pythonee 分布式系统需要依赖的不是时间，是确认两台机器处理事情的先后顺序，顺序有全序 偏序关系。

详细介绍可参考 https://vonng.gitbooks.io/ddia-cn/content/ch9.html

Google 的分布式数据库库用原子时钟保证误差

只有逻辑时钟 Lamport

etcd 是用来存 Meta 数据的

但是就像你说的有单点故障问题。通过高可用的 ETCD 来做服务发现，通信双方直接建立连接比较好。
用 MQ 也可以实现 RPC ，性能肯定没直接通信好，MQ 本身高可用，相当于高可用版本 proxy 吧。
https://github.com/nats-rpc/nrpc

游戏和 web 最大区别就是有状态，实时性要求高。不需要 proxy ，proxy 的唯一优点相当于做了服务发现的工作，

不需要中介可信任的价值转移

转 flink 啊

以前总结的

2PC 是多 obj 的同时修改的 atomic commit 问题，consensus 一般是同一个 obj 的不同 replica 的一致问题；

在事务的上下文中，一致性（ Consistency ）的概念是：对数据的一组特定陈述必须始终成立。即不变量（ invariants ）。具体到分布式事务的上下文中这个不变量是：所有参与事务的节点状态保持一致：要么全部成功提交，要么全部失败回滚，不会出现一些节点成功一些节点失败的情况。

在分布式系统的上下文中，线性一致性（ Linearizability ）的概念是：多副本的系统能够对外表现地像只有单个副本一样（系统保证从任何副本读取到的值都是最新的），且所有操作都以原子的方式生效（一旦某个新值被任一客户端读取到，后续任意读取不会再返回旧值）。

分布式事务一致性会因为协调者单点引入可用性问题
为了解决可用性问题，分布式事务的节点需要在协调者故障时就新协调者选取达成共识
解决共识问题等价于实现一个线性一致的存储
解决共识问题等价于实现全序广播（ total order boardcast ）
Paxos/Raft 实现了全序广播

分布式事务本身的一致性是通过协调者内部的原子操作与多阶段提交协议保证的，不需要共识；但解决分布式事务一致性带来的可用性问题需要用到共识。

全序广播要求将消息按照相同的顺序，恰好传递一次，准确传送到所有节点。