redis学习及实践4---redis集群及相关性能分析

   由于redis不像memcached已经实现了服务器端的sharding，当前采用的是master-slave模式：由master完成读-写操作，而slave只能做读操作。（预计要在redis3.0才能实现真正的sharding。）所以在设计redis集群系统时，难免会遇到“扩容”及“单点故障”等问题。

1.扩容问题：

   因为使用了一致性哈稀进行分片，那么不同的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本身的复制功能的，如果主库快照数据文件过大，这个复制的过程也会很久，同时会给主库带来压力。所以做这个拆分的过程最好选择为业务访问低峰时段进行。

http://blog.nosqlfan.com/html/3153.html

2.       单点故障问题：

   还是用到Redis主从复制的功能，两台物理主机上分别都运行有Redis-Server，其中一个Redis-Server是另一个的从库，采用双机热备技术，客户端通过虚拟IP访问主库的物理IP，当主库宕机时，切换到从库的物理IP。只是事后修复主库时，应该将之前的从库改为主库（使用命令slaveof no one），主库变为其从库（使命令slaveof IP PORT），这样才能保证修复期间新增数据的一致性。

Redis常见的性能问题和解决方法，可参考下面的文章：

http://www.dedecms.com/knowledge/data-base/nosql/2012/0820/8576.html

基于redis的高可用服务器架构，可参考下面的文章：

http://snowolf.iteye.com/blog/1657488

Keepalived+HAproxy实现redis高可用负载均衡，可参考下面的文章：

http://wenku.baidu.com/link?url=qhWtA6hkmCTTTZJiAB38Qnd3qkNc8OQZOsg45-mgRY_06qhOmgjkV0vxZSQEc7hPkh0uPDPV7Yo-Q3JE43DAvbGew5H-tbQBQHoTEUl0sEa