不就是解决冲突嘛！出现冲突我就不往数组中去放了，我用一个链表把同一个数组下标位置的元素连接起来，这样不就可以充分利用空间了嘛，啊哈哈哈哈~~
嘿嘿嘿嘿，完美△△。
真的完美嘛，我是一名黑客，我一直往里面放*%8=4的元素，然后你就会发现几乎所有的元素都跑到同一个链表中去了，MD，最后的结果就是你的哈希表退化成了单链表，查询插入元素的效率都变成了O(n)。
此时，当然有办法，扩容因子干啥滴？
比如扩容因子设置为1，当元素个数达到8个时，扩容成两倍，一半的元素还在4号位置，一半的元素去到了12号位置，缓解了哈希表的压力。
然鹅，依旧不是很完美，本文来源于工从号彤哥读源码。
聪明的程序员哥哥们这次开启了一次长大9127的头脑风暴，终于搞出了一种新的结构——链表树法（当然，这个名字是彤哥起的）。
链表树法虽然上面的扩容在元素个数比较少的时候能解决一部分问题，整体的查找插入效率也不会太低，因为元素个数少嘛。
但是，黑客还在攻击，元素个数还在持续增加，当增加到一定程度的时候，总会导致查找插入效率特别低。
所以，换个思路，既然链表的效率低，我把它升级一下，当链表长的时候升级成红黑树怎么样？
嗯，神舟行，我看行，说干就干。
嗯，不错不错，妈妈再也不怕我遭到黑客攻击了。
所以，到这就结束了吗？
你想多了，NM，每次扩容都要移动一半的元素好么，这样真的好么好么好么？
程序员哥哥们太难了，这次经过了12127的头脑风暴，终于想出个新玩意——一致性Hash。
一致性Hash一致性Hash更多地是运用在分布式系统中，比如说Redis集群部署了四个节点，我们把所有的hash值定义为0~2^32个，每个节点上放置四分之一的元素。
此处只为举例，实际Redis集群的原理是这样的，具体数值不是这样的。
此时，假设需要给Redis增加一个节点，比如node5，放在node3和node4中间，这样只需要把node3到node4中间的元素从node4移动到node5上面就行了，其它的元素保持不变。
这样，就增加了扩容的速度，而且影响的元素比较少，大部分请求几乎无感知。
怎么样，是不是很精彩？
想系统地学习更多编程姿势嘛，来我的工从号“彤哥读源码”一起浪啊~