两台机器搭建redis集群（宝塔搭建redis集群）

本文目录

• 宝塔搭建redis集群
• redis怎么组建集群
• Redis集群方案应该怎么做
• Redis Cluster集群的搭建

宝塔搭建redis集群

单台服务器创建集群，多台也是一样操作，使用集群端口6380,6381,6382,6383,6384,6385

1、宝塔安装redis，路径一般是 /www/server/redis ，使用命令 ln -s /www/server/redis/src/redis-server /usr/bin/redis-server 将redis-server加入环境变量;

2、创建集群文件目录，如 /home/redis/cluster，从redis安装路径复制redis.conf到/home/redis/cluster下，并修改名称为redis_6380.conf,重复操作添加redis_6381.conf，redis_6382.conf，redis_6383.conf，redis_6384.conf，redis_6385.conf

3、修改配置文件，打开redis_6380.conf文件并一下内容，另外几个文件的端口分别改成和文件端口的一致
port 6380
pidfile /www/server/redis/redis_6380.pid
logfile "/home/redis/log/redis_6380.log"
dbfilename dump_6380.rdb
cluster-enabled yes
cluster-config-file nodes-6380.conf
cluster-node-timeout 15000

4、开启端口，将上面的6个端口分别开启，包括宝塔的和服务器的端口

5、分别启动redis redis-server cluster/redis_6380.conf

6、创建集群
redis-cli --cluster create 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6385 --cluster-replicas 1 如果不加–cluster-replicas 1则会创建6个主节点
7、通过端口连接redis
redis-cli -p 6384
使用命令 cluster info 查看集群信息
8、设置测试
连接6382端口redis获取test

获取成功

redis怎么组建集群

简要说明
2018年十月 Redis 发布了稳定版本的 5.0 版本，推出了各种新特性，其中一点是放弃 Ruby的集群方式，改为 使用 C语言编写的 redis-cli的方式，是集群的构建方式复杂度大大降低。关于集群的更新可以在 Redis5 的版本说明中看到，如下：
The cluster manager was ported from Ruby (redis-trib.rb) to C code inside redis-cli. check `redis-cli --cluster help ` for more info.可以查看Redis官网查看集群搭建方式，连接如下
***隐藏网址***
以下步骤是在一台 Linux 服务器上搭建有6个节点的 Redis集群。
操作步骤
创建目录
新建目录：/root/software/redis
下载源码并解压编译
***隐藏网址***
tar xzf redis-5.0.0.tar.gz
cd redis-5.0.0
make创建6个Redis配置文件
6个配置文件不能在同一个目录，此处我们定义如下：
/root/software/redis/redis-cluster-conf/7001/redis.conf
/root/software/redis/redis-cluster-conf/7002/redis.conf
/root/software/redis/redis-cluster-conf/7003/redis.conf
/root/software/redis/redis-cluster-conf/7004/redis.conf
/root/software/redis/redis-cluster-conf/7005/redis.conf
/root/software/redis/redis-cluster-conf/7006/redis.conf配置文件的内容为：
port 7001 #端口
cluster-enabled yes #启用集群模式
cluster-config-file nodes.conf
cluster-node-timeout 5000 #超时时间
appendonly yes
daemonize yes #后台运行
protected-mode no #非保护模式
pidfile /var/run/redis_7001.pid其中 port 和 pidfile 需要随着 文件夹的不同调增
启动节点
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7001/redis.conf
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7002/redis.conf
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7003/redis.conf
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7004/redis.conf
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7005/redis.conf
/root/software/redis/redis-5.0.0/src/redis-server /root/software/redis/redis-cluster-conf/7006/redis.conf启动集群
/root/software/redis/redis-5.0.0/src/redis-cli --cluster create 192.168.2.40:7001 192.168.2.40:7002 192.168.2.40:7003 192.168.2.40:7004 192.168.2.40:7005 192.168.2.40:7006 --cluster-replicas 1启动后，可看到成功信息，如下：
》》》 Performing hash slots allocation on 6 nodes...
Master -》 Slots 0 - 5460
Master -》 Slots 5461 - 10922
Master -》 Slots 10923 - 16383
Adding replica 192.168.2.40:7004 to 192.168.2.40:7001
Adding replica 192.168.2.40:7005 to 192.168.2.40:7002
Adding replica 192.168.2.40:7006 to 192.168.2.40:7003
》》》 Trying to optimize slaves allocation for anti-affinity
Some slaves are in the same host as their master
M: 191c645200a8b4d267f71e3354c8248dbb533dde 192.168.2.40:7001
slots: (5461 slots) master
M: 400a08d4e5a534c1b609988105d3e045395fbd12 192.168.2.40:7002
slots: (5462 slots) master
M: 684f6aa0fbccda295ce6818a8c01ee7255a7b002 192.168.2.40:7003
slots: (5461 slots) master
S: f2701549ae98315b432d73b49d139ee77d5685b4 192.168.2.40:7004
replicates 684f6aa0fbccda295ce6818a8c01ee7255a7b002
S: 9fdc1e375436767ab815cbddd3df674f3bc2ca99 192.168.2.40:7005
replicates 191c645200a8b4d267f71e3354c8248dbb533dde
S: e7742888ed85b37cff4a98e861e99bb16e8bae2c 192.168.2.40:7006
replicates 400a08d4e5a534c1b609988105d3e045395fbd12
Can I set the above configuration? (type ’yes’ to accept): yes
》》》 Nodes configuration updated
》》》 Assign a different config epoch to each node
》》》 Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
....
》》》 Performing Cluster Check (using node 192.168.2.40:7001)
M: 191c645200a8b4d267f71e3354c8248dbb533dde 192.168.2.40:7001
slots: (5461 slots) master
1 additional replica(s)
M: 684f6aa0fbccda295ce6818a8c01ee7255a7b002 192.168.2.40:7003
slots: (5461 slots) master
1 additional replica(s)
S: 9fdc1e375436767ab815cbddd3df674f3bc2ca99 192.168.2.40:7005
slots: (0 slots) slave
replicates 191c645200a8b4d267f71e3354c8248dbb533dde
S: e7742888ed85b37cff4a98e861e99bb16e8bae2c 192.168.2.40:7006
slots: (0 slots) slave
replicates 400a08d4e5a534c1b609988105d3e045395fbd12
M: 400a08d4e5a534c1b609988105d3e045395fbd12 192.168.2.40:7002
slots: (5462 slots) master
1 additional replica(s)
S: f2701549ae98315b432d73b49d139ee77d5685b4 192.168.2.40:7004
slots: (0 slots) slave
replicates 684f6aa0fbccda295ce6818a8c01ee7255a7b002
All nodes agree about slots configuration.
》》》 Check for open slots...
》》》 Check slots coverage...
All 16384 slots covered.至此，Reids集群搭建完成。

Redis集群方案应该怎么做

通常，为了提高网站响应速度，总是把热点数据保存在内存中而不是直接从后端数据库中读取。Redis是一个很好的Cache工具。大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，在这种情况下，如何正确架构Redis呢？
首先，无论我们是使用自己的物理主机，还是使用云服务主机，内存资源往往是有限制的，scale up不是一个好办法，我们需要scale out横向可伸缩扩展，这需要由多台主机协同提供服务，即分布式多个Redis实例协同运行。
其次，目前硬件资源成本降低，多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相对较小的内存高效。因此，实际使用中，通常一台机器上同时跑多个Redis实例。
方案
1.Redis官方集群方案 Redis Cluster
Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。
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 3.0以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。
2.Redis Sharding集群
Redis 3正式推出了官方集群技术，解决了多Redis实例协同服务问题。Redis Cluster可以说是服务端Sharding分片技术的体现，即将键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通，共同对外承担一致服务。
多Redis实例服务，比单Redis实例要复杂的多，这涉及到定位、协同、容错、扩容等技术难题。这里，我们介绍一种轻量级的客户端Redis Sharding技术。
Redis
Sharding可以说是Redis
Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定
的key会映射到特定的Redis节点上。这样，客户端就知道该向哪个Redis节点操作数据。Sharding架构如图：
庆幸的是，java redis客户端驱动jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。
Jedis的Redis Sharding实现具有如下特点：
采
用一致性哈希算法(consistent
hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类
似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。
2.
为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟
化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点
时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。
3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。
Redis Sharding采用客户端Sharding方式，服务端Redis还是一个个相对独立的Redis实例节点，没有做任何变动。同时，我们也不需要增加额外的中间处理组件，这是一种非常轻量、灵活的Redis多实例集群方法。
当然，Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性哈希，毕竟还是会有key匹配不到而丢失，这时需要键值迁移。
作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。有没有其它手段改善这种情况？
Redis
作者给出了一个比较讨巧的办法--presharding，即预先根据系统规模尽量部署好多个Redis实例，这些实例占用系统资源很小，一台物理机可部
署多个，让他们都参与sharding，当需要扩容时，选中一个实例作为主节点，新加入的Redis节点作为从节点进行数据复制。数据同步后，修改
sharding配置，让指向原实例的Shard指向新机器上扩容后的Redis节点，同时调整新Redis节点为主节点，原实例可不再使用。
presharding
是预先分配好足够的分片，扩容时只是将属于某一分片的原Redis实例替换成新的容量更大的Redis实例。参与sharding的分片没有改变，所以也
就不存在key值从一个区转移到另一个分片区的现象，只是将属于同分片区的键值从原Redis实例同步到新Redis实例。
并不是只有增
删Redis节点引起键值丢失问题，更大的障碍来自Redis节点突然宕机。在《Redis持久化》一文中已提到，为不影响Redis性能，尽量不开启
AOF和RDB文件保存功能，可架构Redis主备模式，主Redis宕机，数据不会丢失，备Redis留有备份。
这样，我们的架构模式变
成一个Redis节点切片包含一个主Redis和一个备Redis。在主Redis宕机时，备Redis接管过来，上升为主Redis，继续提供服务。主
备共同组成一个Redis节点，通过自动故障转移，保证了节点的高可用性。则Sharding架构演变成：
Redis Sentinel提供了主备模式下Redis监控、故障转移功能达到系统的高可用性。
高访问量下，即使采用Sharding分片，一个单独节点还是承担了很大的访问压力，这时我们还需要进一步分解。通常情况下，应用访问Redis读操作量和写操作量差异很大，读常常是写的数倍，这时我们可以将读写分离，而且读提供更多的实例数。
可以利用主从模式实现读写分离，主负责写，从负责只读，同时一主挂多个从。在Sentinel监控下，还可以保障节点故障的自动监测。
3.利用代理中间件实现大规模Redis集群
上面分别介绍了多Redis服务器集群的两种方式，它们是基于客户端sharding的Redis Sharding和基于服务端sharding的Redis Cluster。
客户端sharding技术其优势在于服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。其不足之处在于：
由于sharding处理放到客户端，规模进步扩大时给运维带来挑战。
服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。
连接不能共享，当应用规模增大时，资源浪费制约优化。
服务端sharding的Redis Cluster其优势在于服务端Redis集群拓扑结构变化时，客户端不需要感知，客户端像使用单Redis服务器一样使用Redis集群，运维管理也比较方便。
不过Redis Cluster正式版推出时间不长，系统稳定性、性能等都需要时间检验，尤其在大规模使用场合。
能不能结合二者优势？即能使服务端各实例彼此独立，支持线性可伸缩，同时sharding又能集中处理，方便统一管理？本篇介绍的Redis代理中间件twemproxy就是这样一种利用中间件做sharding的技术。
twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后(如sharding)，再转发给后端真正的Redis服务器。也就是说，客户端不直接访问Redis服务器，而是通过twemproxy代理中间件间接访问。
参照Redis Sharding架构，增加代理中间件的Redis集群架构如下：
twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可避免单点压力或故障。
twemproxy又叫nutcracker，起源于twitter系统中redis/memcached集群开发实践，运行效果良好，后代码奉献给开源社区。其轻量高效，采用C语言开发，工程网址是：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis
twemproxy后端不仅支持redis，同时也支持memcached，这是twitter系统具体环境造成的。
由于使用了中间件，twemproxy可以通过共享与后端系统的连接，降低客户端直接连接后端服务器的连接数量。同时，它也提供sharding功能，支持后端服务器集群水平扩展。统一运维管理也带来了方便。
当然，也是由于使用了中间件代理，相比客户端直连服务器方式，性能上会有所损耗，实测结果大约降低了20%左右。

Redis Cluster集群的搭建

搭建集群工作需要以下三个步骤：

1）准备节点。

2）节点握手。

3）分配槽。

Redis集群一般由多个节点组成，节点数量至少为6个才能保证组成完整高可用的集群。每个节点需要开启配置cluster-enabled yes，让Redis运行在集群模式下。建议为集群内所有节点统一目录，一般划分三个目录：conf、data、log，分别存放配置、数据和日志相关文件。把6个节点配置统一放在conf目录下，集群相关配置如下：

其他配置和单机模式一致即可，配置文件命名规则redis-{port}.conf，准备好配置后启动所有节点。

Cluster集群启动过程如下图：
每个节点目前只能识别出自己的节点信息，可以执行cluster nodes命令获取集群节点状

态。

节点握手是指一批运行在集群模式下的节点通过Gossip协议彼此通信，达到感知对方的过程。节点握手是集群彼此通信的第一步，由客户端发起命令：cluster meet{ip}{port}

cluster meet命令是一个异步命令，执行之后立刻返回。内部发起与目标节点进行握手通信，握手通信过程：

1）节点6379本地创建6380节点信息对象，并发送meet消息。

2）节点6380接受到meet消息后，保存6379节点信息并回复pong消息。

3）之后节点6379和6380彼此定期通过ping/pong消息进行正常的节点通

信。

分别执行meet命令让其他节点加入到集群中，

最后执行cluster nodes命令确认6个节点都彼此感知并组成集群。

节点建立握手之后集群还不能正常工作，这时集群处于下线状态，所有的数据读写都被禁止，通过cluster info命令可以获取集群当前状态。

Redis集群把所有的数据映射到16384个槽中。每个key会映射为一个固定的槽，只有当节点分配了槽，才能响应和这些槽关联的键命令。通过cluster addslots命令为节点分配槽。这里利用bash特性批量设置槽（slots），命令如下：

执行cluster info查看集群状态，如下所示：

当前集群状态是OK，集群进入在线状态。所有的槽都已经分配给节点，执行cluster nodes命令可以看到节点和槽的分配关系：

集群模式下，Reids节点角色分为主节点和从节点。首次启动的节点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关的数据。使用cluster replicate{nodeId}命令让一个节点成为从节点。其中命令执行必须在对应的从节点上执行，nodeId是要复制主节点的节点ID，命令如下：

Redis集群模式下的主从复制使用了之前介绍的Redis复制流程，依然支持全量和部分复制。复制（replication）完成后，整个集群的结构如图：
集群搭建需要很多步骤当集群节点众多时，必然会加大搭建集群的复杂度和运维成本。因此Redis官方提供了redis-trib.rb工具方便我们快速搭建集群。

redis-trib.rb是采用Ruby实现的Redis集群管理工具。内部通过Cluster相关命令帮我们简化集群创建、检查、槽迁移和均衡等常见运维操作，使用之前需要安装Ruby依赖环境。

1、安装Ruby：

2、安装rubygem redis依赖：

3、安装redis-trib.rb：

4、安装完Ruby环境后，执行redis-trib.rb命令确认环境是否正确，输出如

下：

首先我们跟之前内容一样准备好节点配置并启动：

启动好6个节点之后，使用redis-trib.rb create命令完成节点握手和槽分配过程，命令如下：

--replicas参数指定集群中每个主节点配备几个从节点，这里设置为1。

如果部署节点使用不同的IP地址，redis-trib.rb会尽可能保证主从节点不分配在同一机器下，因此会重新排序节点列表顺序。节点列表顺序用于确定主从角色，先主节点之后是从节点。创建过程中首先会给出主从节点角色分配的计划，当我们同意这份计划之后输入yes，redis-trib.rb开始执行节点握手和槽分配操作。

集群完整性指所有的槽都分配到存活的主节点上，只要16384个槽中有一个没有分配给节点则表示集群不完整。可以使用redis-trib.rb check命令检测之前创建的集群是否成功，check命令只需要给出集群中任意一个节点地址就可以完成整个集群的检查工作，命令如下：