说到分布式缓存，我们不得不说到两个数据库--memcache、redis，曾经我们使用缓存一般使用memcache，现在我们一般使用redis。那为啥我们从memcache迁移到redis呢？因为redis比memcache更加优秀。memcache支持的类型比较单一，redis支持多种类型。

数据库	支持数据类型
memcache	仅支持简单数据类型，比如string、int等，复杂数据类型需要转换成简单类型再存储（本人没用过，也不知道存啥类型）。
redis	String（字符串）、List（列表）、set（无序集合）、zset（sorted set：有序集合）、hash（哈希）。

        同时，redis也是一个单线程模型，处理业务比较方便。

        我们为什么要用缓存？

        我们现在做的很多项目都是B/S架构，如下图。客户端发请求给Tomcat，Tomcat会开辟一个线程处理你的请求（Tomcat默认最大200线程），处理请求时，有可能向数据库中读写数据。

         那如果访问量很大的时候，后端的服务需要接受考验了。接受考验的有两处：Tomcat

web服务器、数据库。当并发量增加的时候，其实最先达到瓶颈的是数据库，当数据库达到瓶颈的时候，客户端的访问速率就会降低，系统响应时间变长。

 

         那如何解决呢，这时候就要加缓存了，比如我们用redis做一个缓存。

        加了缓存，如何去解决数据库的瓶颈问题呢？我们可以把经常查询的数据作为一个热点数据，存到redis中，当Tomcat要查询这些数据的时候，先从redis中查询一下，如果redis中有直接返回。这样redis就可以阻挡一部分接触mysql的请求，减轻mysql压力。

当然此时又存在几个问题，

• 如果数据库中的热点数据变化怎么办？

需要在变化的同时，去更新redis中的热点数据。

• 如果热点的数据很大怎么办？

特别是在batj这些大公司里面，热点数据很多，一台数据库存不了，我们可以使用多台数据库。

这就涉及到了redis的集群了，即分布式缓存。

        redis集群常见的两种模式：主从模式和切片模式。

主从模式：

        主从模式又称为主从副本模式，一般由一个master和一堆的slave构成，master是主节点，slave是从节点，master管理这堆的slave。客户端去读数据时，找的是slave，写数据的话，找的是master，master写完之后，会把数据同步给这一堆的slave，所以 无论是master还是slave，里面的数据都是一模一样的。

        但这种情况很明显不能解决海量热点数据的问题，因为它的存储量是由单台redis存储量决定的，只要有一台达到了瓶颈，这个集群就算是达到瓶颈了。那么这时候就该切片模式上场了，那么什么是切片模式呢？

        我们看下图。

        比如我们有大量的热点数据，我们的redis集群的每台服务器只存储一部分，那么我们的集群就能够存储大量的数据。那么如何才能做到均匀分布在每台redis上呢？

        

         比如，我们可以使用这种切片规则。

        由于redis中存储的数据都是以key、value存储的，我们可以计算一下key的hash值，上述是三个数据库，那我们用key的hash值%3，即hash(key)%3=[0,1,2]，那这个值肯定是一个0~2的某一个整数，当等于0时，我们存第一个，等于1存第二个，等于2存第三个，这样我们就把大量的热点数据分开且均匀的存储了。

        对应的查询时，先计算key的hash值，0——reids1,1——redis2,2——redis3，这样就找到对应值了。

         但这个切片规则有个弊端，非常不利于集群的扩展。

        如果我们要增加一台redis数据库，那么我们需要从redis123三台数据库中取数据，存到redis4中，算法也要对应的改变，造成大量的网络io。同时，redis123之间也会相互数据迁移。删除也类似，由于redis是单线程模型，当redis发生大量的网络io时，就不能够对外提供存储查询的服务，导致系统缓慢。

         这时候，一致性hash算法就派上用场了。那什么是一致性hash算法呢？看下图：

我们现在有一个环，叫hash环，有2^32个点，三台redis数据库（ip+编号），现在基于每台服务器的ip和编号进行一个hash取余：hash（ip+编号）%2^32=[0,2^32-1]，取余后产生的值一定在0~2^32-1之间。假如我们的三台服务器映射位置如下图，热点数据也进行取余hash(key)%2^32=num，那么num一定也在hash环的某一个点位，num的存储位置则按顺时针的方向存储在最近的数据库中。

         当我们进行添加一个数据库redis4的时候，比如我们计算的hash值取余后，在redis2和redis3中间，则只需要把redis2到redis4之间的，原本存储在redis3里面的值迁移到redis4中即可，其他不变。删除不多说了，一样的。

         现在是不是很完美？

         这样还可能会出现一个问题，数据倾斜问题。插播一个概念：

【数据倾斜】：

• 存储框架：大部分数据存储在少量服务器
• 计算框架：大部分数据由少量服务器计算

如果redis服务器的hash值最后分布的很近，就会导致大量数据存储在一台redis上，比如这种，这样大多数数据就会存储在redis1当中，即数据倾斜。

 那如何解决数据倾斜问题？

我们可以多虚拟几个redis节点，比如每一台redis服务器虚拟10个点，那么就会产生30个节点分布在hash环上，那么产生数据倾斜的概率就会小一些。现实中，可以虚拟n个，n根据实际情况而定，这样就避免了数据倾斜问题。数据迁移的时候也很方便，自行思考。