luoqeng

游戏服务的特殊性，只是把这个当成通信的 BUS 而已，取代了服务发现，消息量不大情况下还可以。
订阅主题就可以实现 RPC 和其他服务通信，很方便，少了服务发现，服务之间建立连接。

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 解决数据加密传输，传输过程中不被篡改。