定价策略，显卡 CPU 内存 软件 这些都是做出不同的刀法卖不同价格。

游戏服务的特殊性，只是把这个当成通信的 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 解决数据加密传输，传输过程中不被篡改。

@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 啊