差别

这里会显示出您选择的修订版和当前版本之间的差别。

到此差别页面的链接

两侧同时换到之前的修订记录 前一修订版
上一修订版 两侧同时换到之后的修订记录
docs:internals:consensus [2016/12/13 23:18]
bossma [一致性模式]
docs:internals:consensus [2016/12/13 23:18]
bossma [一致性模式]
行 57: 行 57:
 这3种模式如下: 这3种模式如下:
  
-默认 - Raft使用leader租赁,在一个时间窗口内,leader假设的它的角色是稳定的。然而,如果leader被从剩余的节点隔离,一个新的leader将会被选举出来,同时旧的leader仍旧保持租约。这意味着有两个leader节点。因为旧的leader不能提交新的日志,这里没有裂脑的风险。然而,如果旧的leader提供任何读的服务,其结果可能是陈旧的。默认的一致性仅依赖与leader租赁,暴露给Client的可能是陈旧的值。我们做这种权衡,是因为读是快速的,通常强一致型的,并且只在一个很难触发的情形下是陈旧的。陈旧读的时间窗口也是有限的,因为leader由于隔离将会下台。+**默认** - Raft使用leader租赁,在一个时间窗口内,leader假设的它的角色是稳定的。然而,如果leader被从剩余的节点隔离,一个新的leader将会被选举出来,同时旧的leader仍旧保持租约。这意味着有两个leader节点。因为旧的leader不能提交新的日志,这里没有裂脑的风险。然而,如果旧的leader提供任何读的服务,其结果可能是陈旧的。默认的一致性仅依赖与leader租赁,暴露给Client的可能是陈旧的值。我们做这种权衡,是因为读是快速的,通常强一致型的,并且只在一个很难触发的情形下是陈旧的。陈旧读的时间窗口也是有限的,因为leader由于隔离将会下台。
  
-强一致 - 这种模式是没有附加条件的强一致性。它需要leader验证法定数目的对等节点来确定它仍旧是leader。这将附加产生到所有Server节点的往返处理。这种权衡要求总是一致性的读,但是由于额外的往返增加了延迟。+**强一致** - 这种模式是没有附加条件的强一致性。它需要leader验证法定数目的对等节点来确定它仍旧是leader。这将附加产生到所有Server节点的往返处理。这种权衡要求总是一致性的读,但是由于额外的往返增加了延迟。
  
-允许陈旧 - 这种模式允许任何一个Server提供读服务,无论它是不是leader。这意味着读可能是任意的陈旧,但都是leader 50毫秒内产生的。这种权衡考虑非常快速且具备良好伸缩性的读,但允许陈旧的值。这种模式允许在没有leader的情况下读,意味着集群不可用的时候,仍旧可以响应。+**允许陈旧** - 这种模式允许任何一个Server提供读服务,无论它是不是leader。这意味着读可能是任意的陈旧,但都是leader 50毫秒内产生的。这种权衡考虑非常快速且具备良好伸缩性的读,但允许陈旧的值。这种模式允许在没有leader的情况下读,意味着集群不可用的时候,仍旧可以响应。
  
 关于使用这几种模式的更多文档,请看[[/​docs/​agent/​http|HTTP API]]。 关于使用这几种模式的更多文档,请看[[/​docs/​agent/​http|HTTP API]]。