redis安装使用-终极篇（分布式、集群配置）

zjxhx

　　前文http://haiziwoainixx.iyunv.com/admin/blogs/2085763 测试过redis的主从配置，作为一个互联网开发技术人员，必须熟悉各种分布式部署应用方案，而缓存的分布式部署又是其中相当重要的一环，下面就来说一说redis的分布式部署方案。
　　一.客户端jedis的实现方案
　　使用jedis时可以给jedis连接池配置多个reidsserver实例，然后通过一致性哈希将数据分布到各个实例上，此种方式简单易用。
　　但是缺点就是当扩容时，之前的缓存相当于全部失效。
　　二.redis本身的实现方案
　　通过利用reids的主从复制，实现一主多从的部署，并且可以在从服务器进行数据备份，提供数据安全性和稳定性，但是此种方式的弊端或者说主从复制的弊端就是当向从服务器插入数据时并不会同步到主服务器，不像mysql可以互为主从来解决这个问题。也就是说可供客户端同时插入和查询的只能是主服务器，否则将存在数据部同步问题。
　　三.结合的解决方案
　　通过一+二的结合，我们可以实现N主+N从的实现方案，既可以解决数据安全性问题，也部分解决了负载均衡问题，但是仍然无法解决扩容时缓存失效的问题，对此，参考以下文章：
　　因为使用了一致性哈稀进行分片，那么不同的key分布到不同的Redis-Server上，当我们需要扩容时，需要增加机器到分片列表中，这时候会使得同样的key算出来落到跟原来不同的机器上，这样如果要取某一个值，会出现取不到的情况，对于这种情况，Redis的作者提出了一种名为Pre-Sharding的方式：
　　Pre-Sharding方法是将每一个台物理机上，运行多个不同断口的Redis实例，假如有三个物理机，每个物理机运行三个Redis实际，那么我们的分片列表中实际有9个Redis实例，当我们需要扩容时，增加一台物理机，步骤如下：
　　A.     在新的物理机上运行Redis-Server；
　　B.      该Redis-Server从属于(slaveof)分片列表中的某一Redis-Server（假设叫RedisA）；
　　C.      等主从复制(Replication)完成后，将客户端分片列表中RedisA的IP和端口改为新物理机上Redis-Server的IP和端口；
　　D.     停止RedisA。
　　这样相当于将某一Redis-Server转移到了一台新机器上。Prd-Sharding实际上是一种在线扩容的办法，但还是很依赖Redis本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。
　　四.redis云
　　以上几种方式都是基于目前的redis版本给出的解决方案，redis的作者正在进行reids云版本的相关开发，期待中.