解决redis连接成本高
多个redis客户端连接到redis服务端，会对server端造成很大的压力，每一个客户端都可能连接两个redis节点实例上面。为了解决这个问题可以用nginx做反向代理，客户端连接访问请求nginx服务器，nginx分发请求，可以实现负载均衡，为了提升性能可以使用nginx做集群，每一个集群中的nginx单机处理一部分请求。nginx前面可以加上一个LVS，所有的客户端访问VIP，只要数据中心能让连接过去，那么LVS就能处理请求。只要你这个数据中心能够让那么多流量进来，那么相对应的LVS服务器应该能让这些流量流过去。
可以用个keepalived给LVS做一个主备，keepalived可以干三件事，一是可以监控他俩的东西，也可以间接去考究俩个nginx的健康状态，如果发现其中有一个挂了，脚本一触发，就在前面剔除他，然后走另一个，所以不受影响。redis作者强调过redis他连多线程都没有去触碰，它就是单向、单实力。所以他其实更期望企业当中就是拿redis单个去使用，不要引入太多的技术。
代理层里边有了逻辑实现，这个逻辑实现就分为比如说我们的 modula ，然后还有我们的random，还有我们的 kemata，这点很重要，那么也就是间接代表你的客户端变得简单轻盈了，不需要染指很多的微代码，这点很重要，你不要说代理层就是非得一个代理事，他其实里边有这些逻辑算法的，它身上并不需要数据库，并不需要记录每一个客户端到底怎么着，更多的数据其实它是不管，数据在redis里存的，所以这时候其实只有达到无状态的代理，像nginx，像我们这种经常讲的这些代理，他们是无状态的。满足之后，只有他们满足了无状态，所以这时候你才可以把它一变多，很容易的变成一变多，谁挂谁起来了。随便的加四五台，这样很灵活。上面几种方式只能做缓存不能做分布式数据库使用，一致性哈希会有时间窗数据丢失。
新的节点一出现的话，一加入到你集群里边的话，那么就会对你的代理或者客户端，也就是对你的算法有一个挑战。如果你是客户端模式的，或者是代理层，因为算法在这里，那么算法里边一致性哈希或者是直接取模那种方式的话，要么取模的方式，新加一点会造成所有数据从新哈希，要么是一致性哈希里边的，然后你加几点之后，会造成它其中有一部分数据被拦截到，只能从这取，然后结果还没有，还是空的。
预分区
预分区：redis实例和客户端之间加一个mapping映射，取模运算的时候直接取模数设置的多一点，中间加上mapping，让多的映射在mapping，mapping在和每一个redis实例对接，如果有新增的节点，直接将原来的模数放在新增的实例redis对应的mapping就行，原来映射对应的数据再重新放到redis实例。不影响重新rehash，影响你曾经有的数据再也找不到。要把槽位一让出去，那么直接在库里边定位槽位一，把那些东西、数据直接落到磁盘，发给你，你load。在迁移着的时候， k1在前面，我要迁给后面，那么我迁移的时候 k1还能不能修改？我再问你一个问题，如果你在做主从的时候，前面这是master，后面这是slave，他数据同步的时候先把10点数据通过rdp给你后面，然后他并且会做一个缓冲，就约等于 rdb和增量日志，我先给你全量的
数据，然后再把缓冲的那些个记录再发给你，然后大家一直对着实时发生的纪录，大家数据是不是可以追平？追平一刹那，那么就修改，未来的请求直接到新的这了，就不到原来那了。
上面类似于代理关系的映射，要么是客户端里边发生的事情，要么是加一个代理层来实现这个算法以及mapping的过程。redis集群不需要代理实现，每一个服务端都有一个取模计算功能，并且有所有redis服务端的槽位信息，拿K取模，如果对应的槽位在当前节点就从当前节点取出数据，如果不在当前节点就去别的节点对应的槽位取出数据，各个redis服务端都有所有节点的槽位信息来实现这个查找功能.Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。无主模型，都是master。
客户端通过方法将key放在同一节点，也可以实现事务，只要在一个节点存储数据就行。