redis_day_21_redis单节点数据容量问题以及一致性哈希环

redis单节点:容量问题

1.为了持久化的时候时间比较短，redis内存存的数据不要占用太大内存，可以通过一些方法将数据分散在几多个redis实例上面；

（1.）数据交集不多的时候可以分类，分布在不同的redis实例，但是这样不方便聚合操作；redis客户端通过业务逻辑做数据的拆分，放在不同的redis节点上面
（2-1.）数据不能划分拆解，一个业务模块放一起，通过hash取模的方式确定存储的位置，但是取模的数量必须固定，如果扩展实例就要重新对数据进行再hash确定新的模中的存储位置，可扩展性比较差。影响分布式下的扩展性。如果扩展节点，取模运算会从新的节点取数据，但是取不出来就会访问数据库造成压力。
（2-2.）客户端随机选取redis实例储存数据，然后另一个客户端随机从两者中间取数据，只要有数据就取出，可以做类似消息队列的实现，每一个list作为一个topic主题。
（2-3.）一致性哈希算法没有取模运算，因为取模的话你会受限模数，受限那个物理机的个数，取模运算的哈希算法在新增节点的时候会有不能命中的数据造成服务器端压力过大，一致性哈希算法通过不取模运算的方式来避免新增节点时的问题。如果根据key计算的节点没有命中的redis实例可以存储在最近的那个节点上，新增节点从新计算处新增节点在哈希环上面的位置，新位置之前的数据不受影响，之后位置的数据要放在新的节点上，相较于取模运算，重新再hash计算数据位置的操作的数据量小了很多。但是比较传统的 hash取模的方式，一致性hash已经将不命中的数据降到了最低。另外要取得比较好的负载均衡的效果，往往在服务器数量比较少的时候需要增加虚拟节点来保证服务器能均匀的分布在圆环上。因为使用一般的hash方法，服务器的映射地点的分布非常不均匀。使用虚拟节点的思想，为每个物理节点（服务器）在圆上分配100～200个点。这样就能抑制分布不均匀，最大限度地减小服务器增减时的缓存重新分布。
物理机比较少得时候增加虚拟节点:

解决数据倾斜问题

比如现在开始的时候我就两台，两台的话就占了两个物理节点的位置，那么这时候其实有很多数据key他都在这边的数据点上，也就是所有的数据都存在 note2上， note1根本没存，因为所有的算出来之后没有，那么那时候可以做件什么事情，我可以让note1后边，他的Ip地址后边依次拼10个数字，然后 note2后面依次拼10个数字，那么等于曾经拿着IP算hash，现在是拿着IP加1个数字算hash，所以这时候它们一个物理设备会出现在几个点上，本来是一个设备，参与一次hash计算，我现在让设备的IP地址拼10个数字，就是从1~10，然后算10个hash找到10个点，那么这样的话等于其实环上会有20个点是物理点。那么这时候某一个key找到自己的位置之后，找到离它最近那个点，要么它，要么它，那么这样的话会间接解决一个倾斜的问题。像刚才所有的数据都在一边了，另一边根本没数据，所以虚拟节点会间接解决数据倾斜的问题。

一致性hash算法

1、一致性hash算法ketama进行数据存储节点的选择,与常规的hash算法思路不同，只是对我们要存储数据的key进行hash计算，分配到不同节点存储。一致性hash算法是对我们要存储数据的服务器进行hash计算，进而确认每个key的存储位置。
2、常规hash算法的应用以及其弊端
最常规的方式莫过于hash取模的方式。比如集群中可用机器适量为N，那么key值为K的的数据请求很简单的应该路由到hash(K) mod N对应的机器。的确，这种结构是简单的，也是实用的。但是在一些高速发展的web系统中，这样的解决方案仍有些缺陷。随着系统访问压力的增长，缓存系统不得不通过增加机器节点的方式提高集群的相应速度和数据承载量。增加机器意味着按照hash取模的方式，在增加机器节点的这一时刻，大量的缓存命不中，缓存数据需要重新建立，甚至是进行整体的缓存数据迁移，瞬间会给DB带来极高的系统负载，设置导致DB服务器宕机。
3、 分布式缓存设计核心点：在设计分布式cache系统的时候，我们需要让key的分布均衡，并且在增加cache server后，cache的迁移做到最少。
一致性hash算法ketama的做法是：选择具体的机器节点不在只依赖需要缓存数据的key的hash本身了，而是机器节点本身也进行了hash运算。
首先求出机器节点的hash值（怎么算机器节点的hash？ip可以作为hash的参数吧。。当然还有其他的方法了），然后将其分布到0～2^32
的一个圆环上（顺时针分布）。如果有一个写入缓存的请求，其中Key值为K，计算器hash值Hash(K)， Hash(K) 对应于图 – 1环中的某一个点，如果该点对应没有映射到具体的某一个机器节点，那么顺时针查找，直到第一次找到有映射机器的节点，该节点就是确定的目标节点，如果超过了2^32仍然找不到节点，则命中第一个机器节点。

一致性哈希算法

1、一致性hash算法只是帮我们减少cache集群中的机器数量增减的时候，cache的数据能进行最少重建。只要cache集群的server数量有变化，必然产生数据命中的问题
2、对于数据的分布均衡问题，通过虚拟节点的思想来达到均衡分配。当然，我们cache server节点越少就越需要虚拟节点这个方式来均衡负载。
3、我们的cache客户端根本不会维护一个map来记录每个key存储在哪里，都是通过key的hash和cacheserver（也许ip可以作为参数）的hash计算当前的key应该存储在哪个节点上。
4、当我们的cache节点崩溃了。我们必定丢失部分cache数据，并且要根据活着的cache server和key进行新的一致性匹配计算。有可能对部分没有丢失的数据也要做重建…
5、至于正常到达数据存储节点，如何找到key对应的数据，那就是cache server本身的内部算法实现了；

解决redis连接成本高

多个redis客户端连接到redis服务端，会对server端造成很大的压力