可能是 tempdb 空间用尽或某个系统表不一致_分布式协同系统的选择

分布式系统中一个绕不过去的问题是如何协同系统中各个分布的模块，确保系统状态的一致性并完成预期的功能。这里面包括以下几个问题：

• 状态管理：系统应该有一个一致的状态，比如某个模块将某个状态设置为特定值后系统的其它部分能及时（最终）看到一致的状态值
• 分布式锁：在系统需要进行特殊操作室提供锁的语义，保证特殊操作对系统状态改变的一致性
• 服务发现：在大型分布式系统中涉及到如何发现特定服务和资源，这个就牵涉到至少两个问题了
  • 如何注册服务或资源（比如端口号）
  • 如何发现已经注册的服务和资源：这儿需要特别指出的是，所谓的发现不仅仅是拿到相关服务或资源的访问入口，还包括如何验证这些访问入口的有效性（即如果提供者取消了注册的服务或资源或已经崩溃，这些服务或资源的使用者能有效的发现或收到通知）

现在比较流行的（接触过的）方案是

• zookeeper - 应该是最早的也是使用最广泛的方案了
• etcd - 这个应该是随着kubernetes的流行目前最被关注的方案
• consul - 和etcd一样算是后起之秀，如果说etcd的目的是实现一个更简单的（更好的）zookeeper，consul的野心则要大得多：它尝试提供一个解决分布式系统中常碰到的诸如服务发现，配置管理等等问题的完整解决方案，当然其中也包括基本的分布式状态管理等问题。

（此外还有一些比如由Netflix开发的Eureka等方案，但我并没有接触过）

这几个方案的核心其实都是通过提供了一个一致性的存储来实现上述功能，不同的是

• zookeeper提供的这个存储借鉴了linux 文件系统的组织形式，通过节点+数据的方式来提供灵活的数据管理和实现各种功能（毕竟文件系统是到目前为止最成功的系统之一，借用它的语义最大程度保证zookeeper的灵活度从而实现各种可能的操作，这个也是为什么zookeeper到现在还老而弥坚的原因吧）
• etcd和consul则是走了K/V的路，直接提供了一个更简单更符合云潮流的存储方式；和zookeeper不同，这个K/V存储逻辑上是个扁平的存储空间，如果需要实现存储数据的层次概念，需要借助命名约定等方式实现（比如为key的名字空间定义特定的格式）

在多节点（集群）模式下，zookeepr和etcd与consul使用的一致性算法也有所不同

• zookeeper使用的是自由的ZAB协议（ZooKeeper Automatic Broadcast），这个协议可以理解为一个PAXOS的简化。由于ZooKeeper对节点通讯模型的进行了适度简化（强化了基于FIFO有序队列的语义并使用超时控制机制），ZAB协议比Paxos更简单，当错误发生时它依赖所选领导节点的激活过程（Leader Activation Phase）来恢复错误从而避免了复杂的协议层面的处理
• Etcd和Consul则是基于更简单直观的Raft协议，具体可以参看 Raft Consensus Algorithm

下面这片文章从性能的角度分析了上面三种方案，可以作为大家的参考：

从这个文章的结果来看，etcd作为后起之秀，在性能上具有很大的优势；但是在选择时需要注意性能只是一个方面，往往限制选择的还有其它更实际和重要的因素，比如系统的规模，开发工具的选择等等。几个方案都能达到最终的目的，但如何选择一定要根据自身的需要和能接受的代价来做理性选择。