作者回复: 写的非常好👍👍
作者回复: 分析思路很清晰
作者回复: 这里的共享是指同一份数据在多个节点都有,但并不一定在所有节点都有,简单理解有数据复制的系统就是CAP应用的场景。
一份数据在多个节点有但不是所有节点都有,这是非对称集群;例如ES
所有数据在所有节点都有,这是对称集群,例如zookeeper
作者回复: 思路很清晰👍👍
作者回复: 大概思路就是这样,按照业务分析
作者回复: 不算,CAP的应用范围已经明确了:互联,共享数据。
这种情况下的不一致靠对账,人工修复等方式解决
作者回复: 不会的,zk是顺序一致性,保证不了完美cp,raft为了可理解而简化了异常处理,某些场景下会丢失数据
作者回复: 架构设计就是判断和选择😀
作者回复: 考虑P的系统在分区场景下还能提供部分业务
作者回复: 是的👍👍
作者回复: CAP的C是严格意义上的绝对一致性,因为不考虑复制延时。
zk全部走master就不符合CAP的CP定义了,因为CAP是要求各个节点都可以提供读写操作,而不是只做备份复制
Raft论文中对于leader切换时可能覆盖日志给了一个详细的案例,这个案例不常见,发生概率非常小,而且只覆盖一条数据
作者回复: 掌握了理论,看具体各种系统实现就比较容易理解了
作者回复: 断网,网线断也可以,网卡坏也可以,交换机故障也可以
作者回复: 分析思路很好
作者回复: 你说的这个不算,分布式节点通过复制来共享数据才算
作者回复: memcache集群不互联不共享数据,redis集群互联且共享数据
作者回复: 直接不允许写,或者分区节点不提供服务,参考Paxos或者Zookeeper