22yune

感觉我跟楼主一类人。。。有类似的想法，但没有清晰完整的架构实现方案，所以没楼主自信。
但是从这个帖子来看，我并不看好楼主。
最后！加油！真弄出来了就牛掰了

首先，楼主文章写的蛮好的；

其次，下面喷的也有道理。

希望大家发言都能尽量友善点。

对于被评论的人，可以想一下，没有人针对谁，大家评论的是言论展示出的观点、态度或什么特质。不需要有被冒犯的感觉。

@zcbenz 我觉得更痛苦的是，别人乱改自己的设计。为抢功改一些他以为‘’没关系’的点，然后他还是领导，要你按他的设计实现。

@hyrepo 谢谢!英语不好，这个没用过。去看看。

@letitbesqzr 首先营养跟不上。政治的偏向太明显，看不进去。其他有推荐的吗？

@Foxkeh 我们也是 从 4 月份开始 第一次实行大小周。。。 感觉今年部门管理上越来越大胆，不怎么考虑员工的意愿了。
ps：周六有下午茶（弥补措施），这次 51 加班也有，刚刚参加。。一些水果、切块盒装，还有泡面、几样零食。pps 吃泡面的不少。。。

我的理解就是#7 说的：最终一致性就是没有一致性。
首先，最终一致性是基于一致性概念衍生的。本来一致是一个原子的概念，一致=没有分歧，没有说部分一致的。
在分布式场景下，一致代价太大。基于 cap，为了 a，只能放弃 c，但业务场景又不能完全放弃。然后就想办法把 c 分级了，就是一致性模型。然后把一致 改名为强一致了。其它的一致性模型都是部分一致的（就是不一致）甚至完全没有一致性保证。其中“如果经过一段时间后要求能访问到更新后的数据，则是最终一致性”（引用自 http://www.blogjava.net/hello-yun/archive/2012/04/16/376744.html ）。
一致性模型中，基于读写及它们的开始时间结束时间，及它们的进程关系这些要素来定义约束，命名一致性模型。非强一致性的模型都只能保证部分一致。无保证的场景就说是最终一致的（可以基于超时额外增加验证补偿机制）。
最终一致性只是部分一致性的一个美化的名字。把不一致说的好像是一致的。不知道是为了忽悠谁。

分布式事务的一致性还是事务的一致性，即业务层面定义的一致性。分布式事务相对与单机事务的难点是：因通信不稳定，参与事务的各个‘进程’如何对状态达成一致。这是个共识问题。
至于 CAP，通常网络 P 很可能发生，无法避免（看到有人说谷歌自建网络非常稳定，不会出现 P ）。所以只能在 CA 上做权衡，C 强一点，A 就弱一点。CA 好像是某个概念（延迟？）的一体两面。建议参考 jepsen.io/consistency，https://www.zhihu.com/people/zhangshuai89/posts

@hengyunabc
‘具备强烈的技术好奇心，专注微服务、服务网格、分布式消息队列、NewSQL 、大数据、流计算等领域至少 3 年’

楼主经历没有这个也可以吗？非 985 也没有这个经历的有机会吗？