timethinker

补充一下，什么时候使用悲观锁，什么时候使用乐观锁，取决于当前业务的更新频率。如果更新频率不高，使用乐观锁有助于提升读取性能（读多写少）。反之，如果乐观更新大概率会失败的情况下，使用悲观锁的性能可能比重试乐观锁要好得多，但是要注意死锁等问题。

本质原因就在于数据竞争。数据竞争就是同时有多个写入者对同一个状态进行修改，就会造成覆盖，想要得到预期的结果，避免错误的覆盖，前提就需要 CompareAndSet 这种语义操作（ SET value = newValue WHERE value = oldValue ），这样就可以根据操作结果（影响行数）来决定下一步该做什么（回滚事务、取消订单 balabala ），这就是乐观锁。

至于悲观锁，本质上它不是解决并发问题，而是避免/阻止并发问题。

观察者模式，通过事件订阅和发布来解耦对象之间的引用关系。

在 Java 中，受检(checked)异常指的是必须要用 try..catch 来调用一个可能会抛出受检异常的方法。python 中应该所有的都是非受检异常，也就是不强迫你使用 try..catch 。

言归正传，不要把异常跟传输搞混了，RPC 本质上也是通过网络传递数据，至于怎么处理这个数据，你可以参考一下 HTTP 协议，返回不同的状态码来表示协议级别的成功与否。或者不需要状态码，不管成功与否永远返回一个就像你发的那样的数据结构，然后再进一步根据数据里面的 code 再决定是否要抛出异常。

机场给你分流是什么意思？

由于不知道编码前的数据到底是字符串还是二进制数据，逆向结果不可知，所以最好是先确定一下编码前的数据是啥。

看完了，我也不知道怎么看完的，哥们表达能力不错的，写小说这些估计也不是什么问题，我已经开始崇拜八单大神在江湖中的地位了。

以接口接收实例，就可以根据构造函数（ NewXXX ）的参数不同，从而返回不同的结构，接口一般是稳定的，具体实现可以根据侧重不同实现不同的需求策略。

LAN 的 DNS 有设置么？