为什么分布式服务需要Zookeeper、ectd这样的服务
我觉得要回答这个问题很简单也很困难，不知道该以一个什么样的方式去说，
但既然用到这样的技术了，还是要说为什么，才能用起来不模糊；
首先我们知道mysql有主备机，redis有主从复制，一切这样做是因为有一个主机，而这个主机是一个协调者，我们又称它为leader，就像生活中的leader一样，如果越过leader去做任何事，那么最终结果就是一团乱麻，变成数据的话就是许许多多的脏数据；
就像我之前文章说的，我们项目会把必要的东西放入缓存里，可是当你有多台服务的时候，你如果修改数据，你是没办法保证数据在每台机器上都是刷新成功的，都近乎实时的，所以我们的系统在上线之初就不保证数据一致性，具体原因可以看我之前文章；
好，现在的我们是有多个服务的，之所以不能单台服务，是因为单台一旦坏了，那整个项目就停了，那既然多个服务，我们又如何来管理这些服务呢，就像人一样，人多了总得立规则，有领导，各自分工，才是和谐社会一样
那服务自然也一样，毕竟技术源于生活；那谁来管理这些服务，谁又来保证需要同步的数据阻塞住查询请求，等到同步完成再对外提供服务？
我们都知道在分布式中遵循cap原则（a:高可用，c:强一致性，p:分区容错性），（这玩意就像现实中的货币的蒙代尔“不可能三角”理论，货币独立、固定汇率、资本自由，三者只能取其二一样），我们是分布式项目，所以必须满足p，a/c根据实际业务场景选择，
比如常见的已经停更的eureka（AP），风头正盛的Zookeeper（CP），阿里的Nacos(AP/CP)，Consul（CP），etcd（CP）；我们该选用什么是业务场景限制的，只不过nacos切换更随心，我从网上找了一张对比图
nacos的标志我们经常看到，我们再来看看ZK和etcd的标志
我看了一下，ZK上一次更新还是三月，而etcd的维护是六月底，从这点可以看出etcd社区更加活跃，，好了言归正传，我们现在已经知道有什么服务可以来管理实例了，那么接下来就是在管理过程中的方便快捷程度，我不会过多深入，我只能顺着技术发展的路线说raft算法更胜一筹，且在云服务大背景下主机掉线是大概率事，如何更快恢复主机（领导）才是重中之重，我知道可能有人看到最后会说，他好像没有回答题目问题，其实不然，我回答的是大概，而更深入的逻辑、算法是很吃力的过程，我need时间，只是想说为什么要用这东西，他解决了我们服务发现，服务注册，以及分布式锁的问题，会让我们数据更好的完成同步；因为他们天生支持分布式锁，不像redis还得用lua;
抛开业务谈技术就是耍流氓，比如我们的配置文件就有两个这玩意，一个Nacos，一个ZK；用哪个或者其他的得根据实际场景；如果你想你的项目即使报错也要响应，那就高可用，如果你想你的项目稳健结果正确那就强一致，千万别说把分区去掉，去掉那就是单机游戏，那还说个啥；；；
