那些关于分布式（一）

关于分布式的今天学习了两个相关知识点，一致性hash以及分布式抢主，下面将总结下今天的学习感悟。。。

关于一致性hash：

概述：

一致性hash的核心思想为解决在分布式数据系统环境下服务器扩容、说缩容操作下导致的机器数据重新分布的问题。这里面一致性hash的核心思想里面扩容和缩容导致的数据重新分布问题是不可避免的，但是可以做到尽可能地减少数据重新分布的机器数量（最佳情况为只影响一台机器的数据重新分布）。

大致思想：

将机器挂载到一个圆上（圆上有2的32次方个点供挂载）。当一台新机器需要加入时先将其机器信息进行A计算，并将该机器挂载到计算值的节点上。当有数据需求访问节点时也进行A计算并将该数据传输到离该值最近的节点上（顺时针寻找节点，若寻找到最后都没有找到节点则从编号0开始继续寻找）。在这个思想的指导下，每次扩容/缩容就只会影响到一个节点数据的迁移，大大减少了扩容/缩容导致影响。

关于数据均衡性问题：

在节点数较少的时候可能会出现节点间距离很近的情况，在这种情况下就会把大部分数据到定向到一个节点上导致数据不均衡。因此作者也提出了虚拟节点的概念。将节点A计算的结果在计算N次得到N个节点值作为虚拟节点，这样节点的间距就会更加打散从而让数据分布更加均衡。不过凡事都有好有坏，好的方面是确实数据分布更加均衡了，坏的方面的是扩容/缩容影响到的节点数等于虚拟节点数。

*A计算：将数值进行hash的结果进行取模2的32次方

 

关于分布式选主：

概述：

主/从模式是互联网开发中必不可小的情景之一，为防止主/从可能导致的脑裂问题，就需用依赖分布式系统的选主方案。其大概思想为在一个时间段里只能有个主，如运行期间主服务器出现问题（如：挂死、网络失联）都会进行切主逻辑，以便让整个服务能正常运行。

zookeeper实现选主：

使用zookeeper的全局临时节点以及节点删除通知来实现选主。本事例用节点名monkey来进行说明（服务有A、B两节点），假设zookeeper中不存在临时节点monkey，当服务器A向zookeeper申请monkey节点的建立，zookeeper由于当前不存在该节点所以立刻批准并且服务器A立刻知道自己为主。而由于zookeeper已经存在monkey节点了所以服务器B的申请会被拒绝而认知到自己为从，但是服务器B会订阅monkey节点的删除事件。因为服务器A总是会有挂的时候，当服务器A挂了服务器B当家做主的机会就来了。至于zookeeper怎样判断主挂了呢？一般还是依据心跳，若心跳在规定时间内没有回复则认为主挂，上述就是zookeeper的选主逻辑。