我们设计的分布式系统，在正常工作时呈现出网状。服务有层次性。客户的请求会逐步经历各层服务进行处理。当遍历全然部服务后才会完毕一次请求。每层服务会有若干台机器。上游节点的机器能够把输出结果传递到下游节点的随意一台机器上。
当服务所依赖的数据须要更新时。我们须要做好同步工作，并保证在数据更新过程中服务是可用的。这儿介绍两类更新的操作方式，它们都须要用到zookeeper来实现。
第一类更新仅仅局限于一个服务的全部机器。我们须要给它们的更新设定一个顺序，避免出现该服务全部机器同一时候更新这样的极端情况。Zookeeper鼓舞使用异步的api进行编程，在实现过程中至少有两种方式来实现这样的分布式锁。第一种是试图去创建一个既定的结点。假设成功则表示锁已经拿到，能够開始更新，否则创建观察点。等待别的机器完毕更新后释放这个锁（当然仍然可能拿不到）；另外一种则去创建一个顺序节点(sequence)，zookeeper能保证创建节点的唯一性，然后服务仅仅须要监控顺序在自己之前的节点是否完毕了更新（释放锁）。当数据量不大时。两种实现方式的性能应该区别不大。数据量大时推荐使用另外一种方式，由于它能够减少通知时产生的网络流量。第一种方式在抢锁过程中，网络更快的机器更easy抢到，另外一种方式是基于排队机制的。
尽管逻辑简单，但实际编程过程中还是会比較麻烦，须要考虑网络传输等问题等。
第二类更新是多个服务中有数据依赖的情况。
比方服务A和B，它们均有两台机器a1, a2, b1, b2。初始时的数据时间戳同样。即服务A的数据是da_t1, 服务B的数据是db_t1。
假设我们有了新的数据da_t2和db_t2，我们仅仅同意首先同一时候更新A和B的当中一台机器。如a1, b1；这是更新数据后的server也仅仅会把自己的下游数据发送到已经更新数据的下游server中去，即由原先的a1和a2都能够把下游数据发送给b1和b2的随意一台。如今a1仅仅能给b1，a2仅仅能给b2。直到a2, b2均更新为新数据的时候。才干恢复原先的传输方式。
详细的实施方式是首先我们须要知道整个数据更新的总server的情况, 以数据的名来命名（index）。例如以下: /data/index/A/a1, /data/index/A/a2, /data/index/B/b1,/data/index/B/b2, 一旦时间戳为t2的数据包都准备好了，那么改动节点/data/index的值为t2（能够一级一级的更新，即/data/index/A。 /data/index/B的时间戳都改动为t2后。再改动/data/index），而且选取每类服务的若干机器開始更新，即添加/updating/index/A/a1, /updating/index/B/b1。并赋值为t2。
每台server会监控自己所属的结点，即a1会监控/updating/index/A/a1。一旦发现该节点出现，就開始进行数据更新，更新完毕后会删除自己的所属节点。监控服务一旦发现/updating/index/A/a1, /updating/index/B/b1均被删除了。就会又一次赋值/updating/index/A/a2,/updating/index/B/b2。
当时间戳为t2的全部数据均完毕更新后，对/updated/index进行赋值为t2。可是在实际编程过程中，全然依照上面的描写叙述进行会很的麻烦。所以我们还是进行了简化。但其逻辑还是得以保证。
至此，对于我设计的分布式框架系统已经介绍完成。