redis 服务相关

Posted 2020-09-02 枫红一叶

一 什么是redis

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)

二redis 安装

1  **如果内存情况比较紧张的话，需要设定内核参数：

                   /etc/sysctl.conf 添加

                   vm.overcommit_memory=1

                   即使生效：sysctl vm.overcommit_memory=1

                   补充介绍：

echo 1 > /proc/sys/vm/overcommit_memory

                  内核参数说明如下：

overcommit_memory文件指定了内核针对内存分配的策略，其值可以是0、1、2。

0， 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。

1， 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。

2， 表示内核允许分配超过所有物理内存和交换空间总和的内存

 

2 下载最新的redis源码版本https://github.com/antirez/redis/archive/3.0.0-rc3.tar.gz

         解压直接安装:

                   Make

                   make PREFIX=/usr/local/redis install

         从源码包里拷贝redis.conf到安装目录下

         3 按需修改配置文件：

**编辑redis.conf配置文件，按需求做出适当调整，比如：

daemonize yes #转为守护进程，否则启动时会每隔5秒输出一行监控信息

save 60 1000 #减小改变次数，其实这个可以根据情况进行指定

maxmemory 256000000 #分配256M内存

         部分配置文件解释

                   daemonize：是否以后台daemon方式运行

pidfile：pid文件位置

port：监听的端口号

timeout：请求超时时间

loglevel：log信息级别

logfile：log文件位置

databases：开启数据库的数量

save * *：保存快照的频率，第一个*表示多长时间，第三个*表示执行多少次写操作。在一定时间内执行一定数量的写操作时，自动保存快照。可设置多个条件。

rdbcompression：是否使用压缩

dbfilename：数据快照文件名（只是文件名，不包括目录）

dir：数据快照的保存目录（这个是目录）

appendonly：是否开启appendonlylog，开启的话每次写操作会记一条log，这会提高数据抗风险能力，但影响效率。

appendfsync：appendonlylog如何同步到磁盘（三个选项，分别是每次写都强制调用fsync、每秒启用一次fsync、不调用fsync等待系统自己同步）

4 启动redis

         /usr/local/redis/bin/redis-server /usr/local/redis/redis.conf

5 一台机器可以启动多个redis的进程，只需要复制出多个配置文件，并修改每个配置文件的路径相关的信息，然后启动就可以了，这样多个redis进程之间是相互独立的存在的。

/usr/local/redis/bin/redis-server /usr/local/redis/redis6380.conf

/usr/local/redis/bin/redis-server /usr/local/redis/redis6381.conf

/usr/local/redis/bin/redis-server /usr/local/redis/redis6382.conf

/usr/local/redis/bin/redis-server /usr/local/redis/redis6383.conf

 

三 Redis的主从配置

         Redis的主从配置就是为一个redis的服务器配置一个从服务器，从服务器实时的同步主服务器的数据，从而作为一个主服务器数据的实时备份或者只读的从服务器来使用。

         1 配置过程

只需要在从服务器的配置文件里增加主服务器相关的配置信息即可

         slaveof 172.21.13.2 6379         

         slave-read-only设置从服务器是否可写。

四 twemproxy介绍与安装配置

         Twemproxy,也叫nutcraker。是一个twtter开源的一个redis和memcache代理服务器。 redis作为一个高效的缓存服务器，非常具有应用价值。但是当使用比较多的时候，就希望可以通过某种方式 统一进行管理。避免每个应用每个客户端管理连接的松散性。同时在一定程度上变得可以控制。Twemproxy是一个快速的单线程代理程序，支持Memcached ASCII协议和更新的Redis协议：它全部用C写成，使用Apache 2.0 License授权。Twemproxy 通过引入一个代理层，可以将其后端的多台 Redis 或 Memcached 实例进行统一管理与分配，使应用程序只需要在 Twemproxy 上进行操作，而不用关心后面具体有多少个真实的 Redis 或 Memcached 存储。

1       twemproxy特性：

•       支持失败节点自动删除

•       可以设置重新连接该节点的时间

•       可以设置连接多少次之后删除该节点

•       该方式适合作为cache存储

•       支持设置HashTag

•       通过HashTag可以自己设定将两个KEYhash到同一个实例上去。

•       减少与redis的直接连接数

•       保持与redis的长连接

•       可设置代理与后台每个redis连接的数目

•       自动分片到后端多个redis实例上

•       多种hash算法：能够使用不同的策略和散列函数支持一致性hash。

•       可以设置后端实例的权重

•       避免单点问题

•       可以平行部署多个代理层.client自动选择可用的一个

•       支持redis pipelining request

     支持请求的流式与批处理，降低来回的消耗

•       支持状态监控

•       可设置状态监控ip和端口，访问ip和端口可以得到一个json格式的状态信息串

•       可设置监控信息刷新间隔时间

•       高吞吐量

•       连接复用，内存复用。

•       将多个连接请求，组成reids pipelining统一向redis请求。

2 安装与配置

                   autoconf下载地址：http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz

                   twemproxy的安装要求autoconf的版本在2.64以上，否则提示”error: Autoconf version 2.64 or higher is required“。autoconf直接make和make install即可。

Twemproxy下载    git clone git://github.com/twitter/twemproxy.git 

         cd twemproxy

         autoreconf -fvi

         ./configure --prefix=/usr/local/twemproxy

         Make

         Make install

         修改配置文件/usr/local/twemproxy/conf/nutcracker.yml

         启动 nutcracker -d –c nutcracker.yml -s 22221 -m 1024

         redis1: 

  listen: 0.0.0.0:8888 

  redis: true 

  hash: fnv1a_64 

  distribution: ketama 

  auto_eject_hosts: false 

  timeout: 400 

  servers: 

   - 192.168.149.128:6380:1 

   - 192.168.149.128:6381:1

   - 192.168.149.128:6382:1

   - 192.168.149.128:6383:1

redis2: 

  listen: 0.0.0.0:9999 

  redis: true

  hash: fnv1a_64

  distribution: ketama

  auto_eject_hosts: false

  timeout: 400

  servers:

   - 192.168.149.128:6380:1

   - 192.168.149.128:6381:1

   - 192.168.149.128:6382:1

   - 192.168.149.128:6383:1

配置项解释

         redis1: 

           listen: 127.0.0.1:6379 #使用哪个端口启动Twemproxy 

           redis: true #是否是Redis的proxy 

           hash: fnv1a_64 #指定具体的hash函数 

           distribution: ketama #具体的hash算法 

           auto_eject_hosts: true #是否在结点无法响应的时候临时摘除结点 

           timeout: 400 #超时时间（毫秒） 

           server_retry_timeout: 2000 #重试的时间（毫秒） 

           server_failure_limit: 1 #结点故障多少次就算摘除掉 

           servers: #下面表示所有的Redis节点（IP:端口号:权重） 

            - 127.0.0.1:6380:1 

            - 127.0.0.1:6381:1 

            - 127.0.0.1:6382:1 

你可以同时开启多个 Twemproxy (对应配置文件里的redis1和redis2)实例，它们都可以进行读写，这样你的应用程序就可以完全避免所谓的单点故障。

五 Sentinel

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

• 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
• 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。完成迁移后，sentinel会修改相应的配置文件和redis的配置文件，从而使转移配置持久化。Sentinel会将失效的主服务器定义为从服务器。

Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个运行在特殊模式下的 Redis 服务器， 你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动 Redis Sentinel 。

1 安装

         和redis的安装步骤一样，安装完成后安装bin目录下会生成redis-sentinel命令文件。

         创建配置文件sentinel.conf

                   daemonize yes

port 26379

logfile "/usr/local/sentinel/sentinel.log"

pidfile "/usr/local/sentinel/sentinel.pid"

dir /tmp

sentinel monitor redis-128-6380-master 192.168.149.128  6380 1

sentinel down-after-milliseconds  redis-128-6380-master    60000

sentinel failover-timeout  redis-128-6380-master  180000

sentinel parallel-syncs redis-128-6380-master  1

         配置文件解释：

                   sentinel monitor mymaster 127.0.0.1 6379 2

sentinel down-after-milliseconds mymaster 60000

sentinel failover-timeout mymaster 180000

sentinel parallel-syncs mymaster 1

 

第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移， 并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。

         down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决。

parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。如果从服务器被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明）， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。你可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。

         2 Sentinel API

         在默认情况下， Sentinel 使用 TCP 端口 26379 （普通 Redis 服务器使用的是 6379 ）。Sentinel 接受 Redis 协议格式的命令请求， 所以你可以使用 redis-cli 或者任何其他 Redis 客户端来与 Sentinel 进行通讯。

有两种方式可以和 Sentinel 进行通讯：第一种方法是通过直接发送命令来查询被监视 Redis 服务器的当前状态， 以及 Sentinel 所知道的关于其他 Sentinel 的信息， 诸如此类。另一种方法是使用发布与订阅功能， 通过接收 Sentinel 发送的通知： 当执行故障转移操作， 或者某个被监视的服务器被判断为主观下线或者客观下线时， Sentinel 就会发送相应的信息。

Sentinel 命令

以下列出的是 Sentinel 接受的命令：

PING ：返回 PONG 。

SENTINEL masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态。

SENTINEL slaves <master name> ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态。

SENTINEL get-master-addr-by-name <master name> ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号。

SENTINEL reset <pattern> ： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清除主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel 。

SENTINEL failover <master name> ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移 （不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。

发布与订阅信息

SUBSCRIBE 、 UNSUBSCRIBE 和 PUBLISH 三个命令实现了发布与订阅信息泛型（Publish/Subscribe messaging paradigm）， 在这个实现中， 发送者（发送信息的客户端）不是将信息直接发送给特定的接收者（接收信息的客户端）， 而是将信息发送给频道（channel）， 然后由频道将信息转发给所有对这个频道感兴趣的订阅者。发送者无须知道任何关于订阅者的信息， 而订阅者也无须知道是那个客户端给它发送信息， 它只要关注自己感兴趣的频道即可。对发布者和订阅者进行解构（decoupling）， 可以极大地提高系统的扩展性（scalability）， 并得到一个更动态的网络拓扑（network topology）。

客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器： 你不可以使用 PUBLISH 命令向这个服务器发送信息， 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收所有实例进入主观下线（SDOWN）状态的事件。         订阅一个主服务器切换的消息为：PSUBSCRIBE +switch-master <master name> <oldip> <oldport> <newip> <newport>。

这样就可以收到关于主服务器切换频道的消息。

六 redis命令参考

BGSAVE

CLIENT GETNAME

CLIENT KILL

CLIENT LIST

CLIENT SETNAME

CONFIG GET

CONFIG RESETSTAT

CONFIG REWRITE

CONFIG SET

DBSIZE

DEBUG OBJECT

DEBUG SEGFAULT

FLUSHALL

FLUSHDB

INFO

LASTSAVE

MONITOR

PSYNC

SAVE

SHUTDOWN

SLAVEOF

SLOWLOG

SYNC

TIME

七 redis-cluster的安装和配置

Redis的集群可以通过两种方式进行构建，一种是通过twemproxy代理后端的多个redis实例进行构建的，这种方法构建的集群，后端的redis实例之间是相互独立的，一个实例出问题后不会影响到其它实例上的数据和服务。另一种构建方式是通过redis自带的集群功能进行构建.如果集群中的一个节点出问题后，并且没有从节点，集群就会停止工作，所以建议集群都是建立在主从的基础上。

   1 redis集群简介

         Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施（installation）。Redis 集群不支持那些需要同时处理多个键的 Redis 命令， 因为执行这些命令需要在多个 Redis 节点之间移动数据， 并且在高负载的情况下， 这些命令将降低 Redis 集群的性能， 并导致不可预测的行为。Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。Redis 集群提供了以下两个好处：将数据自动切分（split）到多个节点的能力。当集群中的一部分节点失效或者无法进行通讯时， 仍然可以继续处理命令请求的能力。

  2 Redis 集群数据共享

    Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 数据库中的每个键都属于这 16384 个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。

 

集群中的每个节点负责处理一部分哈希槽。 举个例子， 一个集群可以有三个哈希槽， 其中：

 

节点 A 负责处理 0 号至 5500 号哈希槽。

节点 B 负责处理 5501 号至 11000 号哈希槽。

节点 C 负责处理 11001 号至 16384 号哈希槽。

这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。 比如说：

 

如果用户将新节点 D 添加到集群中， 那么集群只需要将节点 A 、B 、 C 中的某些槽移动到节点 D 就可以了。

与此类似， 如果用户要从集群中移除节点 A ， 那么集群只需要将节点 A 中的所有哈希槽移动到节点 B 和节点 C ， 然后再移除空白（不包含任何哈希槽）的节点 A 就可以了。

因为将一个哈希槽从一个节点移动到另一个节点不会造成节点阻塞， 所以无论是添加新节点还是移除已存在节点， 又或者改变某个节点包含的哈希槽数量， 都不会造成集群下线。

3 Redis 集群中的主从复制

为了使得集群在一部分节点下线或者无法与集群的大多数（majority）节点进行通讯的情况下， 仍然可以正常运作， Redis 集群对节点使用了主从复制功能： 集群中的每个节点都有 1 个至 N 个复制品（replica）， 其中一个复制品为主节点（master）， 而其余的 N-1个复制品为从节点（slave）。

在之前列举的节点 A 、B 、C 的例子中， 如果节点 B 下线了， 那么集群将无法正常运行， 因为集群找不到节点来处理 5501 号至11000 号的哈希槽。

另一方面， 假如在创建集群的时候（或者至少在节点 B 下线之前）， 我们为主节点 B 添加了从节点 B1 ， 那么当主节点 B 下线的时候， 集群就会将 B1 设置为新的主节点， 并让它代替下线的主节点 B ， 继续处理 5501 号至 11000 号的哈希槽， 这样集群就不会因为主节点 B 的下线而无法正常运作了。不过如果节点 B 和 B1 都下线的话， Redis 集群还是会停止运作。

4 Redis 集群的一致性保证

Redis 集群不保证数据的强一致性（strong consistency）： 在特定条件下， Redis 集群可能会丢失已经被执行过的写命令。

使用异步复制（asynchronous replication）是 Redis 集群可能会丢失写命令的其中一个原因。 考虑以下这个写命令的例子：

客户端向主节点 B 发送一条写命令。

主节点 B 执行写命令，并向客户端返回命令回复。

主节点 B 将刚刚执行的写命令复制给它的从节点 B1 、 B2 和 B3 。

如你所见， 主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。

如果真的有必要的话， Redis 集群可能会在将来提供同步地（synchronou）执行写命令的方法。

Redis 集群另外一种可能会丢失命令的情况是， 集群出现网络分裂（network partition）， 并且一个客户端与至少包括一个主节点在内的少数（minority）实例被孤立。

举个例子， 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点， 其中 A 、B 、C 为主节点， 而 A1 、B1 、C1 分别为三个主节点的从节点， 另外还有一个客户端 Z1 。

假设集群中发生网络分裂， 那么集群可能会分裂为两方， 大多数（majority）的一方包含节点 A 、C 、A1 、B1 和 C1 ， 而少数（minority）的一方则包含节点 B 和客户端 Z1 。

在网络分裂期间， 主节点 B 仍然会接受 Z1 发送的写命令：

如果网络分裂出现的时间很短， 那么集群会继续正常运行；

但是， 如果网络分裂出现的时间足够长， 使得大多数一方将从节点 B1 设置为新的主节点， 并使用 B1 来代替原来的主节点 B ， 那么 Z1 发送给主节点 B 的写命令将丢失。

注意， 在网络分裂出现期间， 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选项：

对于大多数一方来说， 如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群， 那么集群会将这个主节点视为下线， 并使用从节点来代替这个主节点继续工作。

对于少数一方， 如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群， 那么它将停止处理写命令， 并向客户端报告错误。

5 配置reids集群

  为单个redis的配置文件增加关于集群的配置项，然后分别启动各个redis的实例就行。

  关于集群的配置项如下：

                   port 7000

cluster-enabled yes

cluster-config-file nodes.conf

cluster-node-timeout 5000

appendonly yes

      文件中的 cluster-enabled 选项用于开实例的集群模式， 而 cluster-conf-file 选项则设定了保存节点配置文件的路径， 默认值为 nodes.conf 。

节点配置文件无须人为修改， 它由 Redis 集群在启动时创建， 并在有需要时自动进行更新。

要让集群正常运作至少需要三个主节点， 不过在刚开始试用集群功能时， 强烈建议使用六个节点： 其中三个为主节点， 而其余三个则是各个主节点的从节点。

6 创建集群

  现在我们已经有了六个正在运行中的 Redis 实例， 接下来我们需要使用这些实例来创建集群， 并为每个节点编写配置文件。

通过使用 Redis 集群命令行工具 redis-trib ， 编写节点配置文件的工作可以非常容易地完成： redis-trib 位于 Redis 源码的 src 文件夹中， 它是一个 Ruby 程序， 这个程序通过向实例发送特殊命令来完成创建新集群， 检查集群， 或者对集群进行重新分片（reshared）等工作。

我们需要执行以下命令来创建集群：（如果提示/usr/bin/env: ruby: 没有那个文件或目录，请看最后的ruby的相关安装）

./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \

127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

命令的意义如下：

给定 redis-trib.rb 程序的命令是 create ， 这表示我们希望创建一个新的集群。

选项 --replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

之后跟着的其他参数则是实例的地址列表， 我们希望程序使用这些地址所指示的实例来创建新集群。

简单来说， 以上命令的意思就是让 redis-trib 程序创建一个包含三个主节点和三个从节点的集群。

接着， redis-trib 会打印出一份预想中的配置给你看， 如果你觉得没问题的话， 就可以输入 yes ， redis-trib 就会将这份配置应用到集群当中：

>>> Creating cluster

Connecting to node 127.0.0.1:7000: OK

Connecting to node 127.0.0.1:7001: OK

Connecting to node 127.0.0.1:7002: OK

Connecting to node 127.0.0.1:7003: OK

Connecting to node 127.0.0.1:7004: OK

Connecting to node 127.0.0.1:7005: OK

>>> Performing hash slots allocation on 6 nodes...

Using 3 masters:

127.0.0.1:7000

127.0.0.1:7001

127.0.0.1:7002

127.0.0.1:7000 replica #1 is 127.0.0.1:7003

127.0.0.1:7001 replica #1 is 127.0.0.1:7004

127.0.0.1:7002 replica #1 is 127.0.0.1:7005

M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000

slots:0-5460 (5461 slots) master

M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001

slots:5461-10921 (5461 slots) master

M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002

slots:10922-16383 (5462 slots) master

S: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003

S: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004

S: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005

Can I set the above configuration? (type ‘yes‘ to accept): yes

输入 yes 并按下回车确认之后， 集群就会将配置应用到各个节点， 并连接起（join）各个节点 —— 也即是， 让各个节点开始互相通讯：

>>> Nodes configuration updated

>>> Sending CLUSTER MEET messages to join the cluster

Waiting for the cluster to join...

>>> Performing Cluster Check (using node 127.0.0.1:7000)

M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000

slots:0-5460 (5461 slots) master

M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001

slots:5461-10921 (5461 slots) master

M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002

slots:10922-16383 (5462 slots) master

M: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003

slots: (0 slots) master

M: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004

slots: (0 slots) master

M: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005

slots: (0 slots) master

[OK] All nodes agree about slots configuration.

如果一切正常的话， redis-trib 将输出以下信息：

>>> Check for open slots...

>>> Check slots coverage...

[OK] All 16384 slots covered.

这表示集群中的 16384 个槽都有至少一个主节点在处理， 集群运作正常。

  集群客户端 redis-cli    -c   –p 注意加-c参数

 

Ruby相关的安装

mkdir /usr/local/ruby

#tar -zxvf ruby-1.8.4.tar.gz
#cd ruby-1.8.4
#./configure --prefix=/usr/local/ruby
#make
#make install

设置路径
#vi /etc/profile
在该文件中加入，
RUBY_HOME=/usr/local/ruby
PATH=$PATH:$RUBY_HOME/bin
export RUBY_HOME PATH

检查是否安装成功
重新登录，
#ruby –v

 

安装 Ruby Gems
#tar -zxvf rubygems-0.9.0.tgz
#cd rubygems-0.9.0
#ruby setup.rb

安装redis-gem

下载  https://rubygems.global.ssl.fastly.net/gems/redis-3.0.5.gem

安装  gem install -l redis-3.0.5.gem