Redis怎么做集群

为什么集群？

通常，为了提高网站响应速度，总是把热点数据保存在内存中而不是直接从后端数据库中读取。Redis是一个很好的Cache工具。大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，在这种情况下，如何正确架构Redis呢？

首先，无论我们是使用自己的物理主机，还是使用云服务主机，内存资源往往是有限制的，scale up不是一个好办法，我们需要scale out横向可伸缩扩展，这需要由多台主机协同提供服务，即分布式多个Redis实例协同运行。

其次，目前硬件资源成本降低，多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相对较小的内存高效。因此，实际使用中，通常一台机器上同时跑多个Redis实例。

方案

1Redis官方集群方案 Redis Cluster

Redis Cluster是一种服务器Sharding技术，30版本开始正式提供。

Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类pre sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简单，就是CRC16后16384取模。

Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实现中，还处于半自动状态，需要人工介入。

Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。

为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似前篇文章提到的Redis Sharding场景下服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。

Redis Cluster的新节点识别能力、故障判断及故障转移能力是通过集群中的每个node都在和其它nodes进行通信，这被称为集群总线(cluster bus)。它们使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是16379。nodes之间的通信采用特殊的二进制协议。

对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个node进行操作，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这有点儿像浏览器页面的302 redirect跳转。

Redis Cluster是Redis 30以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

2Redis Sharding集群

Redis 3正式推出了官方集群技术，解决了多Redis实例协同服务问题。Redis Cluster可以说是服务端Sharding分片技术的体现，即将键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通，共同对外承担一致服务。

多Redis实例服务，比单Redis实例要复杂的多，这涉及到定位、协同、容错、扩容等技术难题。这里，我们介绍一种轻量级的客户端Redis Sharding技术。

Redis Sharding可以说是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。这样，客户端就知道该向哪个Redis节点操作数据。

庆幸的是，java redis客户端驱动jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。

Jedis的Redis Sharding实现具有如下特点：

1 采用一致性哈希算法(consistent hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。

2为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。

3ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。

科学计算领域,服务器集群这种计算工具有相当重要的作用,通常一个集群可以有几十、几百颗处理器通过高速网络连接组合在一起，形成巨大的计算资源为特定的应用服务。

我们首先来介绍一下集群，Cluster集群技术可如下定义：一组相互独立的服务器在网络中表现为单一的系统，并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。

大多数模式下，集群中所有的计算机拥有一个共同的名称，集群内任一系统上运行的服务可被所有的网络客户所使用。Cluster必须可以协调管理各分离的组件的错误和失败，并可透明地向Cluster中加入组件。

一个Cluster包含多台（至少二台）拥有共享数据存储空间的服务器。任何一台服务器运行一个应用时，应用数据被存储在共享的数据空间内。每台服务器的操作系统和应用程序文件存储在其各自的本地储存空间上。

Cluster内各节点服务器通过一内部局域网相互通讯。当一台节点服务器发生故障时，这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。当一个应用服务发生故障时，应用服务将被重新启动或被另一台服务器接管。当以上任一故障发生时，客户将能很快连接到新的应用服务上。

由于组成集群的机器不尽相同，所以我们通常可以把集群分成两种：工作站集群和胖节点集群。

工作站集群（COW）

工作站集群的节点机规模一般都比较小，常常配备的示2-4颗处理器的服务器，采用通常的以太网或者InfiniBand来连接，一般采用Linux集群操作系统来对集群进行管理。

这种集群最常见的是PC服务器厂商的PC－Cluster集群或者刀片服务器集群，他的优点主要是价格便宜和容易部署，所以很多小的服务器厂商也可以做这种集群。在国外，很多大学生通过一个公用的高速专用网络，将数十台的PC联在一起，用Linux集群操作系统来管理，就构成了这种集群。

这种集群的缺点是不太稳定，不能运行大规模的商业应用软件。而且由于这种松散连接，使得占用的空间可能比较大，散热也成问题。

胖节点集群

胖节点集群的服务器节点多是8-16颗CPU的SMP服务器，其稳定性大大提高，通过专有技术用以太网或者InfiniBand连接，系统采用UNIX操作系统，应用经过优化的专用集群管理软件。常见的机器有IBM的

Cluster1600和HPQ

AlphaServer

SC，他的好处是节点机的性能比较稳定，系统节点不太容易出问题，这样就可以运行大型的应用程序，应用到商业或者科学计算中。它的扩展性也比较好，支持所有并行方式，但是相比于前一种，价格也要贵很多。国外和国内都有这种应用案例，当然这种价格也不是一般企业和机构可以采用的，多数是原来做商业计算或者科研。

详情请参照：http://articlepchomenet/content-123394html

linux服务器集群平台的搭建比较简单，有专门的均衡软件，比如lvs，lvs是一个集群系统，由很多服务器组成，可以根据需要，把它门分为三层，一层是前端机，用于均衡，相当于公平为系统分配工作，二层是服务器群，比如web服务器群，DNS，mail群等，这些就是接待员，把均衡器分配的工作进行处理，第三层是存储设备，用于存储数据，相当于档案库。

知道这些后，要搭建就非常容易，有现成的软件，比如我有四台web服务器，2台数据库，1台前置机 ，安装linux系统，安装lvs软件，比如

heartbeat-214-9el5i386rpm

heartbeat-ldirectord-214-9el5i386rpm

libnet-114-3el5i386rpm

heartbeat-devel-214-9el5i386rpm

heartbeat-pils-214-10el5i386rpm

perl-MailTools-177-1el5noarchrpm

heartbeat-gui-214-9el5i386rpm

heartbeat-stonith-214-10el5i386rpm

当然还需要配置，你可以自己百度有关lvs集群的详细安装说明。希望能帮助你。

你这个需求是备份吧，Windows有两种服务可以解决你现在的问题：

1、网络负载均衡，可以把指定的服务器添加到负载均衡群中，并指定网络端口和协议，选择负载均衡集群切换模式是按照一对一还是交叉负载均衡；

2、故障转移集群，可以针对进程判断是否启用备份机的指定进程；

这两个集群各有各的用途，同时对于搭建也有自己的要求，完成集群后所对应的功能也略有不同。

部署：

负载均衡不需要额外设备；

但故障转移，需要iSCSI存储设备支持；

用途：

负载均衡针对网络端口，重点在于均衡，可以通过交叉策略，保证a/b的访问量一致，或者单一主机方式，保证在宕机或网线不通的情况下切换到备机；

故障转移，可以精确监控到进程，保证进程出现故障（包括宕机）即可转移到备机；

具体问题具体分析，看你需要什么级别的备份，要求高的话，上故障转移（但是要增加设备——iSCSI），要求简单，就上负载均衡