Sinclairs2020-02-10CP模型的KV存储，适合用于提供基础服务，保存少量数据，作用类似zookeeper。 AP模型的KV存储，适合查询量大的场景，不要求数据的强一致性，目前广泛应用于分布式缓存系统。 一点思考，不知道对不对？作者回复: 加一颗星:)，能否容忍的可能的短暂的一致性延迟，是关键。
共 3 条评论61
大漠胡萝卜2020-02-11网络分区，怎么理解？作者回复: 网络分区是指因为网络故障导致网络不连通，不同节点分布在不同的子网络中，各个子网络内网络正常。其实，你可以这么理解，节点之间的网络通讯出现了消息丢失、高延迟的问题。
共 2 条评论36
陈2020-02-14cp模型适合要求acid场景，比如银行转账。ap模型适合只要求base的场景，比如网页cdn场景，不知道理解得对不对。作者回复: 加一颗星:)
26
enjoylearning2020-02-11还是不太明白分区容错性P和可用性A的区别，不都是随时可以提供服务吗？作者回复: 可以这么理解，分布式系统是必须要考虑分区容错性的，也就是说，出现分区错误时，比如节点间通讯丢消息了，系统要能运行，那么，这时候如何运行呢？是选择一致性呢，还是选择可用性呢。
共 28 条评论21
iron_man2020-02-23知乎上看到的，与各位分享 一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。 作者：邬江 链接：https://www.zhihu.com/question/54105974/answer/139037688 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。展开作者回复: 前半部分的容忍性，其实指的的是可用性，做法是分区部署、增加数据缓存，提升可用性。分区容错性是一种行为，指的是分区错误发生时，系统依然能提高服务，这时可以提供的服务，有两种，一致性和可用性，需要注意的是，有些服务是要求一致性的，也就是说，增加集群副本数，是不能解决问题的。可用性，就比较好理解了，但在实际中，仅仅增加副本数或缓存是不够的，还需要全方位的监控能力、高灵敏的故障检测能力、全网的调度能力，等等。
共 4 条评论19
zjm_tmac2020-02-10这里的节点1同步给节点2指的是日志复制还是等待节点2的事务提交完成？ 如果是日志复制的话，会不会两边提交事务的时间不一致，造成读取不一致。 如果是等待事务提交的话，是不是变成了完全阻塞的，性能很低还有各种各样问题。作者回复: 加一颗星:)。这里是简化表示，比如你可以理解成二阶段提交的事务。关于第一个“如果”，多节点的副本是无法做到完全同时完成提交的，但能保证写完成后，读取都是一致的；如果需要实现读取的严格一致性，比如，可以通过实现“Master-Slave”模型，读写只访问Master节点，实现读取的严格一致性；第二个“如果”，就是常见事务型系统的缺点。
共 2 条评论19
霹雳大仙pp2020-03-09以阿里nacos来说，配置中心是cp，保证各节点配置强一致；注册中心是ap，保证了可用性，牺牲了强一致性。作者回复: 加一颗星:)
16
NICK2020-02-23可不可以理解成在分布式场景下: 1. 如果业务需要强一致性，则只能牺牲可用性而选择CP模型。 2. 如果业务需要最终一致性即可，则优先满足可用性，选择AP模型？作者回复: 加一颗星:)
11
longyi2020-02-19受限于 Raft 的强领导者模型。所有请求都在领导者节点上处理，整个集群的性能等于单机性能。这样会造成集群接入性能低下，无法支撑海量或大数据量的时序数据。 //老师，这里应该是所有的写请求都在领导者节点上处理吧？ //另外，如果采用multi-raft，每个raft分片都有自己的leader，这样请求将不限于节点，而是在分片的leader上，这样性能也没那么差，老师觉得呢？作者回复: 加一颗星:)，是写请求，相比Raft，Multi-Raft是有改进的，但和最终一致性的方案相比，还是有差距。其实，Raft不适合时序数据场景，比如，如果即使采用multi-raft，因为时序数据，有时需要拉取一批数据，这时需要在外围，再实现分布式迭代器，工作量，还是蛮大的；另外，在Raft中，uncommitted的log，可能被丢弃了，也可能在后面被提交了，也就是说，当Raft返回给客户端超时错误时，数据是否会被提交，是个不确定状态，如果这时，客户端不重试，可能会丢数据，如果客户端重试，对于没有带时间戳的时序数据，会导致数据重复，当然，我们可以通过重新约定InfluxDB行为、实现冥等操作等，来解决这个问题，但这样做，不仅增加工作量和系统复杂度，还影响用户的体验；还有最后一点，也就是最最重要的，高性能的背后，是成本，是钱，这个经济效益，会在海量数据场景，被放大，性能是最核心的一个考虑因素。
共 2 条评论8
小跑2020-02-14怎么觉得etcd-raft不是严格意义上的一致性，是线性的，只要满足大多数的情况下，哪怕个别节点挂掉，也能对外提供读写服务，所以从这个角度看，它其实一种ap模型吧。作者回复: Raft是具有容错能力的共识算法，可以用来实现一致性，比如，类似Google Chubby，读写操作都在领导者节点上执行。 可以这么理解，分布式事务实现的是一致性，不能容忍任何节点出问题；只要集群中有一个节点，都能继续提供服务，可以把这个理解为可用性。而Raft等共识算法，能容忍少数节点的故障，但通过读写操作都在领导者节点上执行，也能为业务提供一致性的数据服务，可以将共识算法理解为对分布式事务型算法的改进，既有容错能力，又能提供一致性。
7