标签：缓存 hash 三台 算法 聊一聊 哈希 一致性 服务器

为什么会用到哈希？

假如有3GB缓存数据，想要分摊到三台服务器上，如果直接1GB放一台这样做，那么当以后需要查询数据时，是需要遍历三台服务器的所有缓存数据，这样很慢。

我们不妨在分摊的时候，使用哈希进行散列分摊，在查询的时候，进行的同样的操作，就能很快的达到我们想要的效果。

很多类似的场景，都是需要哈希O(1)的查找时间复杂度的。

我们可以设置哈希函数hash = 文件编号%3，给三台服务器分别编号0，1，2 根据哈希结果分别放到这三台服务器上。

上述有什么缺陷？进一步改善

思考一下，上面这样做有什么问题？

• 假如公司预算增加、业务需求扩展，服务器决定增加到5台，如果还想接着用上面的哈希方法，那么原来三台上的数据都是需要去再次hash的。
• 再比如，某台服务器挂掉，那么三台服务器的哈希查找特性都会丢失，缓存全部失效，对系统的影响巨大。

怎么解决？

采用一致性哈希算法。

一致性哈希算法本质也是使用哈希表取模的思想，不同的是，前面是对服务器的数量进行取模，一致性哈希算法是对2^32进行取模。

哈希函数为：hash（服务器A的IP地址） % 2^32

第一步：

将三台服务器的IP地址按照上面的哈希函数分别进行计算，计算结果一定是在0-2^32之间的数，考虑到“取模”运算的性质，完全可以把哈希结果看成是一个环，因为线是由点组成的嘛

第二步:

将缓存通过新的哈希函数：hash（文件名称） % 2^32，映射一下

假如某缓存映射后如下图左下角的红色标记所示，那么代表该文件是需要放到B服务器缓存的，因为它沿顺时针方向遇到的第一个服务器就是B服务器的。

第三步：

当下次想要访问该缓存时，再次使用相同的算法进行计算，便可以找到该缓存是在哪个服务器。

前面说了一致性哈希算法是怎么用的？

言归正传，为什么能解决我们刚才说的场景问题？

首先我们要注意，一致性哈希算法，哈希结果看作是一个环，这是理解问题的关键。

再重述下刚才的情景：
1.三台服务器=》五台服务器，导致之前hash处理过的三台服务器上的文件数据全都丧失哈希查找的特性，需要重新hash

对于这种情况，可以看成环多了几个服务器结点，原有的并不会变，而新缓存则会逐步分摊到五台服务器上。

2.三台服务器=>两台服务器，即有一台服务器B宕机，缓存全部失效。

对于这种情况，原本属于B的缓存会被缓存到其他的缓存服务器，而其他没问题的则与以前一样，不需要rehash

标签：缓存,hash,三台,算法,聊一聊,哈希,一致性,服务器
来源： https://blog.csdn.net/weixin_43889841/article/details/118698447

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。