Category: Distributed Architecture

1. 背景 最近在做分布式相关的工作，由于人手不够只能我一个人来怼；看着这段时间的加班表想想就是够惨的。 不过其中也有遇到的不少有意思的事情今后再拿来分享，今天重点来讨论服务的注册与发现。 2. 分布式带来的问题 我的业务比较简单，只是需要知道现在有哪些服务实例可供使用就可以了（并不是做远程调用，只需要拿到信息即可）。 要实现这一功能最简单的方式可以在应用中配置所有的服务节点，这样每次在使用时只需要通过某种算法从配置列表中选择一个就可以了。 但这样会有一个非常严重的问题： 由于应用需要根据应用负载情况来灵活的调整服务节点的数量，这样我的配置就不能写死。 不然就会出现要么新增的节点没有访问或者是已经 down 掉的节点却有请求，这样肯定是不行的。 往往要解决这类分布式问题都需要一个公共的区域来保存这些信息，比如是否可以利用 Redis？ 每个节点启动之后都向 Redis 注册信息，关闭时也删除数据。 其实就是存放节点的 ip + port，然后在需要知道服务节点信息时候只需要去 Redis 中获取即可。 如下图所示： 但这样会导致每次使用时都需要频繁的去查询 Redis，为了避免这个问题我们可以在每次查询之后在本地缓存一份最新的数据。这样优先从本地获取确实可以提高效率。 但同样又会出现新的问题，如果服务提供者的节点新增或者删除消费者这边根本就不知道情况。 要解决这个问题最先想到的应该就是利用定时任务定期去更新服务列表。 以上的方案肯定不完美，并且不优雅。主要有以下几点： 基于定时任务会导致很多无效的更新。 定时任务存在周期性，没法做到实时，这样就可能存在请求异常。 如果服务被强行 kill，没法及时清除 Redis，这样这个看似可用的服务将永远不可用！...

在 2006 年，Google 发表了一篇名为 The Chubby lock service for loosely-coupled distributed systems 的论文，其中描述了一个分布式锁服务 Chubby 的设计理念和实现原理；作为 Google 内部的一个基础服务，虽然 Chubby 与 GFS、Bigtable 和 MapReduce 相比并没有那么大的名气，不过它在 Google 内部也是非常重要的基础设施。 相比于名不见经传的 Chubby，作者相信 Zookeeper 更被广大开发者所熟知，作为非常出名的分布式协调服务，Zookeeper 有非常多的应用，包括发布订阅、命名服务、分数是协调和分布式锁，这篇文章主要会介绍 Zookeeper 的实现原理以及常见的应用，但是在具体介绍 Zookeeper 的功能和原理之前，我们会简单介绍一下分布式锁服务...