redis一致性hash php,关于redis的分布式架构的哪些事？一致性hash？hash取模？其他？...

一点php分享关于redis分布式架构理念的一些总结并不涉及实际部署方式以及代码，无论是redis还是其他软件所有的架构理念是一样的，个人认为理念更为重要，代码是死的理念是活的，没有一种架构可以解决一切问题，只有遇到不同的问题采用不同的架构根据实际场景调整架构方案。

分布式算法无非是运维开发者手动实现或者是软件自身支持某种算法实现。搭建分布式的目的就在于将不同的请求压力以及读写io分散开，关键在于如何分散请求以及后续如何可以精确的命中请求。

一致性hash算法：

redis存储采用一致性hash方式命中节点，将所有缓存以及节点都放入hash空间中，数据进来后 通过hash计算得出自己的位置然后顺时针寻找就近节点，如果节点宕机则寻找下一个。如果分布不均匀，导致某一节点压力过大，可以采用虚拟节点。

hash取模方式：

数据进来后通过hash取模的方式算出节点位置，从而进行读写操作，这种算法实现简单也有一定的作用，但是server总数不能轻易变化。因为如果增加/减少server的数量，对原先存储的所有key的后续查询都将定位到别的server上，导致所有的cache都不能被命中而失效。

区别：

为了解决这个问题，需要采用一致性hash算法

相对于取模的算法，一致性hash算法除了计算key的hash值外，还会计算每个server对应的hash值，然后将这些hash值映射到一个有限的值域上(比如0~2^32)。通过寻找hash值大于hash(key)的最小server作为存储该key数据的目标server。如果找不到，则直接把具有最小hash值的server作为目标server。

在redis3.0版本之后推出redis自身的实现方式：

生产通过hash槽将0~16383范围分片给不同节点存储数据，最少6台redis才能将这个架构跑起来，3台master以及3台slave分别为主各自的主从，并且将16383个hash槽位置分散在3台master节点中。好处是显而易见的主挂从上，同时主从数据基本同步当然也不是强一致性的，并不能100%的认为数据一致。当master数量少于一定程度或者某个节点的主从同时宕机，这个集群将停止工作。

总结：

以上只是博主分享的一部分关于redis的架构理念，只是让大家有个概念，具体细节一篇文章也讲不完。同时并不是说只有这些方式，例如某些大厂中会有自身的一套算法，还有redis中也有哨兵算法等，本文主要作为抛砖引玉的作用。

一点php一点技术分享