差别

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

到此差别页面的链接

两侧同时换到之前的修订记录 前一修订版
后一修订版
前一修订版
docs:internals:consensus [2016/12/13 23:18]
bossma [一致性模式]
docs:internals:consensus [2016/12/13 23:22]
bossma [Consul中的Raft]
行 45: 行 45:
 只有Consul Server节点参与Raft,并作为对等节点集的部分。所有的Client节点转发请求到Server节点。这样设计的部分原因是,随着更多的成员加入对等节点集,法定数目的大小也会随之增长。这会产生性能问题,因为相比少数机器,你可能需要等待上百个机器对日志记录达成一致。 只有Consul Server节点参与Raft,并作为对等节点集的部分。所有的Client节点转发请求到Server节点。这样设计的部分原因是,随着更多的成员加入对等节点集,法定数目的大小也会随之增长。这会产生性能问题,因为相比少数机器,你可能需要等待上百个机器对日志记录达成一致。
  
-在入门指南开始,一个单独的Consul Server被设置为“bootstrap”模式。这个模式允许它选择自己作为leader。一旦leader被选举出来,其它的Server可以在保持一致性和安全性的方式下添加到这个对等节点集中。最终,只要第一批Server节点被加入,bootstrap模式就可以被禁用了。看[[/​docs/​guides/​bootstrapping这里]]了解详细。+在入门指南开始,一个单独的Consul Server被设置为“bootstrap”模式。这个模式允许它选择自己作为leader。一旦leader被选举出来,其它的Server可以在保持一致性和安全性的方式下添加到这个对等节点集中。最终,只要第一批Server节点被加入,bootstrap模式就可以被禁用了。看[[/​docs/​guides/​bootstrapping|这里]]了解详细。
  
 因为所有的Server都参与并作为对等节点集的部分,他们都知道当前的leader。当一个RPC请求到达某个非leader Server,这个请求会被转发到leader。如果这个RPC是一个查询,意味着它是只读的,leader基于有限状态机的当前状态产生这个结果。如果这个RPC是个事务类型,意味着它会修改状态,leader将产生一个新的日志记录,并使用Raft应用它。一旦日志记录被提交,且应用到有限状态机,则事务完成。 因为所有的Server都参与并作为对等节点集的部分,他们都知道当前的leader。当一个RPC请求到达某个非leader Server,这个请求会被转发到leader。如果这个RPC是一个查询,意味着它是只读的,leader基于有限状态机的当前状态产生这个结果。如果这个RPC是个事务类型,意味着它会修改状态,leader将产生一个新的日志记录,并使用Raft应用它。一旦日志记录被提交,且应用到有限状态机,则事务完成。
行 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]]。