Deep Water Slow

RabbitMQ集群也会弄丢消息，这个问题在官方文档的教程中也提到过，就是说在消息发送到RabbitMQ之后，默认是没有落地磁盘的，万一RabbitMQ宕机了，这个时候消息就丢失了。在消费消息的时候，如果你连接到的RabbitMQ实例不是存放Queue数据的实例，这个时候RabbitMQ就会从存放Queue数据的实例上拉去数据，然后返回给客户端。RabbitMQ消费端弄丢了数据的情况是这样的：在消费消息的时候，刚拿到消息，结果进程挂了，这个时候RabbitMQ就会认为你已经消费成功了，这条数据就丢了。

当选举结束后，每个节点都需要根据自己的角色更新自己的状态。选举出的Leader更新自己的状态为Leader，其它节点更新自己状态为Follower。（3） COMMIT Leader的zxid比Follower的zxid大，发送Proposal给Follower提交执行。（2）当Leader第二种Follower的状态了，就确定需要做何种方式的数据同步DIFF、TRUNC、SNAP。（2）TRUNC Follower的zxid比Leader的zxid大，所以Follower要回滚。

CAP理论CAP理论告诉我们，一个分布式系统不可能同时满足以下三种这三个基本要求，最多只能同时满足其中的两项，因为P是必须的，因此往往选择就在CP或者AP中。

第1，Node1在填充1号位置的时候，发现1号位置的值被大多数确定了，比如是X=5（node3占领了1号位置，Node2跟从了Node3），则Node1就接受这个事实：1号位置不能用了，也得把自己的1号位置赋值成X=5。（2）假如要做多机之间数据同步，如果直接同步状态，状态本身可能有一个很复杂的数据结构（比如关系数据库的关联表、树、图），并且状态也一直在变化，要保证多个机器数据一致，要做数据比对，就很麻烦；比如第1种情况，三台机器存储的日志顺序都是X=1、X=3、X=5，在最终集群里，X的值肯定等于5。

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、节点删除、子目录节点增加删除）时，ZooKeeper 会通知客户端。1）节点的值变化监听get -w /xx注意：在右边的客户端多次修改/dd0000000007的值，左边不会再收到监听。因为注册一次，只能监听一次。想再次监听，需要再次注册。2）节点的子节点变化监听（路径变化）ls -w /xx3）当某个节点创建或者删除的时候。