Atomic Broadcast 官方文档部分翻译

zookeeper_small.gif

• Atomic Broadcast

At the heart of ZooKeeper is an atomic messaging system that keeps all of the servers in sync.
在ZooKeeper的核心是原子消息系统，它保证所有服务器同步。

Guarantees, Properties, and Definitions
保证、属性、和定义
The specific guarantees provided by the messaging system used by ZooKeeper are the following:
ZooKeeper使用的消息系统提供的特殊保证为：

1. Reliable delivery
   保靠的分发
   If a message, m, is delivered by one server, it will be eventually delivered by all servers.
   一个消息m,如果已经投递给了一个服务器,它最终会被投递到所有服务器。

2. Total order
   总顺序(全局顺序)
   If a message is delivered before message b by one server, a will be delivered before b by all servers. If a and b are delivered messages, either a will be delivered before b or b will be delivered before a.
   （这句话难翻了）

如果在某个服务器上的消息a是在消息b之前投递的(过去式，对方已接受已生成zxid)，那么在其他服务器上，a也会在b之前的顺序被投递。
如果a和b都是要被投递的消息（被动，说明还没投递,并发），那么哪个消息先被投递(过去式说明已接受)不确定。

• Causal order
  因果关系
  If a message b is sent after a message a has been delivered by the sender of b, a must be ordered before b. If a sender sends c after sending b, c must be ordered after b.
  如果一个消息b是在a消息被b的发送者投递（已经生成zxid）之后被发送。
  那么a的顺序一定在b之前,如果一个发送端在发送b之后又发送了c(同步),那么c一定在b之后。

The ZooKeeper messaging system also needs to be efficient, reliable, and easy to implement and maintain. We make heavy use of messaging, so we need the system to be able to handle thousands of requests per second. Although we can require at least k+1 correct servers to send new messages, we must be able to recover from correlated failures such as power outages. When we implemented the system we had little time and few engineering resources, so we needed a protocol that is accessible to engineers and is easy to implement. We found that our protocol satisfied all of these goals.

ZooKeeper 的消息系统也需要高效、可靠、实现简单并且能持久化(保持)。我们使用了大量的消息，所以我们需要系统能够处理每秒上千次请求。虽然我们发送一个消息至少需要k+1台服务器是正确的。我们也必须能够从相关联的失败服务器（比如断电的）中恢复数据。我们实现这个系统的时侯我们花了很少的时间 和很少的工程资源，所以我们需要一个协议，这个协议是能够被工程师接受的并且实现起来不复杂。我们发现我们的协议能够让我们的目的得到满足。

Our protocol assumes that we can construct point-to-point FIFO channels between the servers. While similar services usually assume message delivery that can lose or reorder messages, our assumption of FIFO channels is very practical given that we use TCP for communication. Specifically we rely on the following property of TCP:

我们协议(zab)假设我们构造一个服务器之间的p2p FIFO管道。而类似的服务假设消息可能会丢或消息可能会重排序。我们FIFO管道的假设是非常具有实践性的，我们使用TCP(可靠传输)通信。我们依赖TCP的以下属性：

• Ordered delivery
  顺序投递
  Data is delivered in the same order it is sent and a message m is delivered only after all messages sent before m have been delivered. (The corollary to this is that if message m is lost all messages after m will be lost.)
  数据的投递（对方已接受）顺序和发送顺序（只发了，还未到达对象）是一致的，一个消息m只有在所有在它之前的发送的消息都被投递(已接受)之后才被投递。按这个逻辑，如果m丢失，那么在它之后的所有消息都会丢失。
• No message after close
  Once a FIFO channel is closed, no messages will be received from it.
  一旦FIFO管理被关闭，那么将不会再有消息被接收。

总结：

• zab 通过TCP传输，保证发送与接受的顺序一致。
• 并发消息的顺序，谁先被接受(谁先生成zxid)不一定。