@kqz901002 他显然是在通过反讽表达国内 SaaS 市场的现状

手持暗 9plus ，4080 版本，对比之前的 16MBP pro ，除了 ui 可能没那么好看，要吵一点，其他方面全是秒了。我就说一句，24 年了谁 tm 还花一万多去买一个 16g+256Gssd ，纯纯怨种。

“如果在 2016 年，暴雪总部被陨石砸了，那么暴雪会变成本世纪最传奇的游戏公司。
如果在 2018 年，暴雪的总部被陨石砸了，它将是一家值得怀念的游戏公司。
如果在 2020 年被陨石砸了，它将是一家令人惋惜的游戏公司。
如果今年被陨石砸了，那这块陨石将是一颗传奇的陨石”

这两年很多地方 local 自己都找不到工作，还指望当地公司给你做 offshore ？

后悔是这世界上最没 b 用的东西，不如想想怎么把今天用好。
如果你能从过去找到点教训，或许它还有那么一点点用，但就我个人的认知而言，这种案例是极其少的。

mark 一下，感谢 lz

天下无双的自适应能力

@liuhan907 Raft source paper 可没让走 follower ，论文里就是让走 leader 可提供线性一致性读，后续的各类系统实现的时候走 follower 显然是为了性能的妥协，不能怪到 Raft 算法本身上去

MySQL 的这种做法不就是典型的 2PC ？ 2PC 的缺陷不想在这里赘述了，几个知名的分布式数据系统（ Spanner ，CRDB ，yugaByteDB ）都采用了 paxos 或者 multi paxos 的方式来尽量解决 2PC 的缺陷，比如改进后的 2PC 不需要全局共识了而只需要 quorum 共识，以及 coordinator 可以根据 paxos 算法自动 failover ，这都是很大的改进了。

@liuhan907 你搞错了，Raft 读数据走 leader 即提供全局 linearizable read ，怎么可能不解决 data consistency ？只是想要线性一致性读必须走 leader ，这对于分布式系统的服务可用性和性能是个头疼的问题，所以即便是采用了 Raft 作为 data replication 共识算法的分布式数据系统一样要提供 follower read 提供给用户，典型如 CRDB 和 yugabyteDB

@xiyy02 想强一致就 follower 转发 leader ，想一定程度牺牲一致性来换取性能和可用性就 follower read ，总是有取舍的。

索尼捏着；正常的 3A 开发者都对 PC 盗版深恶痛绝。

这点报酬兼职我都懒得考虑还全职

@Leee 你们看清楚再回啊，内推他的人是 principal ，他面的不是 principal 的 jd

《 clean code 》《 refactor 》这几本书真的每个搞软工的都该看看。而且 OO 也要多找好的资料看看，接口，虚拟类，继承多态，设计模式这些也不是前人为了搞玄学搞出来的，是真的管用。