前言
前段时间，空闲时间在公司调试zookeeper，被同事（也是同学，暂称为小马哥）看到了。他说你还玩这东西？事实上，我们这种小型公司85%的项目中用不到zookeeper，大家接触的都比较少。有的甚至没听说过。
后来，小马哥私下来问我，究竟什么是zookeeper（下文全部用zk来代指zookeeper），当时快速解释道：分布式协调，配置管理，master选举，分布式锁，还可以实现队列。
是的，这样解释好像没几个人懂，百度一大堆都是这样的话。本文中，并不会介绍zk的api和使用，只是让大家明白为什么要有zk。具体使用，我们在下一篇文章中详细说明。
促使我写这篇文章的原因有2个：
1、希望能带给看这篇文章人一定帮助，写完后，首先推送给小马哥看看，增加个阅读量……
2、加深自己的理解。
（纯文字描述的一篇文章，尽量将故事写的让大家有兴趣看看下去）
从集中式到分布式
1、小弟入行较晚，2016年中旬踏入编程行业时已然存在众多武林高手和很牛的系统。但，我相信，10多年前，在中国，应该大多数的项目还是集中式的，所谓集中式，即一个应用集中部署，以网购商城举一个例子，这个应用的功能包含用户注册，商家上架新货，客户搜索商品并下单，订单，仓库，物流更新等等一系列功能。然而中国网上购物的人很少，可能开始每天只有几百几千人用这个系统。并没有什么问题。
2、后来，人们发现网购很爽很便宜啊，互相口头推荐，网上购物吧，听起来，这种方式时髦（依稀记得我妈当年一直提醒说我付款后人家不发货怎么办，哈哈），后来，越多的人开始网购。发现这台服务器顶不住了，于是开始服务器扩容，加到N台做负载均衡，OK，事情好像缓和了。用户体验流畅了一些。
3、又过了一段时间，商城的产品经理提了个需求，商家对我们系统的后台添加新货的功能很不满意，我们要重构此处功能。耗时1个月后，后台重构完成，网站发布公告，今晚停机维护1小时进行系统升级。嗯，1小时升级完成了。这1小时，很多购物迷妹准备买东西，结果维护，去了另一平台买到了。我们的商城这1小时损失了1万用户，每人预计消费100块，丢失了100万的成交额。老板生气了，大骂CTO！
4、为了解决这个困境，CTO想了个办法，我们把后台商家添加新货的这个模块重新开发一个系统吧，这样以后维护的时候，我们只是商家端维护，不影响用户下单。
OK，第一版从集中式过渡到分布式的场景出来了，将商家端和用户端分离成2个项目，我发现了几个非常大的好处：
1、2个端成立2个开发团队，大家互不干涉，商家端功能较少，我们只需要3个人就能维护这个项目。
2、商家端用户较少，我们只需要集群2台机器，而用户端，中国的网购用户太多了，我们部署900台吧。
3、而且公司总部在浙江，团队有3个兄弟是北京的，以后分配这3个兄弟可以回北京的办公区来专门负责商家端了。以后公司成立了北京分部。可以将大批的北京的IT精英纳入自己麾下。例如阿里巴巴的钉钉和阿里云主要就是在北京（没调查过）
后来，介于这种好处，CTO把用户模块，搜索模块，订单模块，仓储物流模块都分开部署了。
分布式后存在的问题
问题1、用户模块，订单，搜索等模块现在都是不同的项目了，现在问题出现了，小马哥登录前台浏览好了一件衣服后，下单跳到了订单模块，（在开发人员的角度讲，这是2个系统啊，session不共享）小马哥再次登录到订单系统，又想查看物流信息（跳到物流模块），提示小马哥未登录，小马哥生气了，这什么傻逼玩意儿，老子不买了，一直提示让我登录。分布式导致的问题，应该我们开发人员来买单，而不是让用户感到不爽。
此种问题解决方案很简单，我们将session共享啊，不要把session放到JVM的HashMap中（java程序员的角度），我们集中缓存session到redis中吧，但是，这样cookie不共享啊，如果1级域名不相同的话，访问A系统返回的cookie并不会带到B系统（cookie域），这个问题，我们也比较好解决。共用1级域名就行，我们叫a.hkmall.com,b.hkmall.com。事实上，资料显示早期的分布式系统就是这样解决会话共享问题的。
但这样，还存在很多问题，比如物流模块这帮兄弟的系统不是用java写的，用的python，人家大骂，你们这cookie里的jessionid是什么东西啊，我们可不认识。是的，这种方式限定了语言。
后来，终于有了企业级解决方案（单点登录SSO）（关于sso的详细描述，建议大家自行查阅相关资料，之后可能会写一篇基于CAS的SSO，个人也是个小菜鸟，只是在个人学习项目hkmall中用到了这些）
BTW、吐槽一个点：个人认为，上述这种情况下有必要SSO，而且也有意义，但我所见过的一些系统的单点登录，小弟愚昧，一直没有意会到SSO的用意是什么，比如我们公司的。一堆互不相干的系统，集成到一起登录，事实上，这些系统之间很多没有联系，A系统的用户压根不可能登录到B系统。徒增了用户登录时的困难性和开发人员的调试和对接的难度。换句话说，假如有天A系统用户要授权为可以使用B系统，B系统要接纳A系统用户的重构工作量也不小（比如有的系统做了用户本地化等等操作……）。当然了，个人只是站在了技术的角度上，高层面的想法我是没有想到的！
问题2、我们拿订单模块与仓储模块来举个例子，假设用户执行下单操作，我们用消息队列将订单消息写到中间件中，此时仓库模块订阅了这个消息，要执行相应的库存 -1操作。但因某种原因（或许是网络原因，仓库模块挂了等）导致仓库没有执行-1这步操作，而这恰好又是最后一件商品，后来又一个用户下单，发现仓库还有商品，又下单成功了！这样出现了一个问题，只有一件商品，却被2个用户买到了。究竟要发货给谁？？（可能这个例子举的不够恰当，事实上没有系统这样设计，只是为了说明情况）
诸如此类情况，我们出现了数据不一致的情况，我们在集中式系统中，很容易的通过锁与数据库的ACID特性可以保证这种情况不发生，但在分布式系统中，好像并没有特别好的解决方案。
问题N、当然了，分布式的诸多问题，并不是在我们这篇文章的讨论范围之内。如果感兴趣，可以详细查阅以下ACP，BASE理论等，个人认为，分布式系统的理论非常重要，如果对理论掌握的很娴熟，在技术选型与代码方面稍加练习后应该没有太大的难度。
没有分布式就不会有zookeeper
引入1、假设我们上边的分布式系统中集群部署了900台机器（假设的原因是实际中我们不会这样的方式部署），这900个节点有900个配置文件，我们数据库地址没有使用域名而使用了ip，现在换ip了，我们要修改900个配置文件，并且重启所有应用系统。相信这一步操作对运维来说是灾难性的。此时肯定要将这个配置写到一个地方，我们这900个应用来引用它。如我们公司使用的NAS文件系统等。但是，万一这个集中存储的系统挂了呢？况且，我不想因为这一处改动而重启900次，我希望ip变了后通知一下我的应用，自动加载新的ip就好了。
需求：可以唯一的帮我保存一份东西，并且你要可靠，别我向你拿东西的时候拿不到了。并且你在把东西修改了的时候告诉我一声。
zookeeper简介：
它很像数据结构当中的树，也很像文件系统的目录。树是由节点所组成，Zookeeper的数据存储也同样是基于节点，这种节点叫做Znode。
/ 地球
/ 地球 /动物园
/ 地球 /动物园 /老虎
/ 地球 /动物园 /狮子
如上，每一级的路径都唯一，且有上下级关系，每一个路径，都是一个Znode。
后续继续更新