centos安装redis并客户端连接_CentOS 7离线安装Redis

简介

Redis作为一个开源的key-value存储系统，目前已经使用在很多大型系统中。作为key-value存储系统的代表，同时也经受过千万级应用的检验，它的强大性、易用性、安全性都不言而喻。而我们在进行key-value存储系统选型时，很多时候都会默认把Redis作为默认的备选对象。所以，Redis就变的越来越重要，基本上是运维人员、开发人员的必备技能。而我这里总结的这篇文章主要面向的是运维人员，目的是告诉大家搭建Redis、如何配置Redis，希望通过我的这篇文章，你能掌握以下技能：

Redis的搭建

Redis的配置

好了，开始Redis的学习之旅。(注：以下操作均在CentOS Linux release 7.3下完成)

单机版安装

我们先从单机版安装开始，因为我们在搭建开发环境时，都是安装的单机版，所以单机版的安装是运维人员、开发人员必备的技能。

安装单机版主要分为以下几步：

下载源码

打开https://redis.io/download网站，下载Redis最新稳定版源码。

上传至服务器，解压缩、编译

到这里，Redis已经编译完成，我们就可以使用单机版的，通过以下命令启动Redis：

使用自带的redis-cli客户端连接redis-server进行测试：

到此关于Redis的单机版安装就结束了。单机版安装是非常简单的，只需要按照官网说明进行执行即可。

Redis主从模式配置

在实际生产环境下，Redis基本上是不可能部署单节点的，而是通过部署Redis集群实现Redis的高可用，从而保障实际生产业务的正常运行。

说到集群安装，那就需要先来说说Redis简单的主从配置。在一些简单的，小型应用中，我们可能会看到这样的Redis部署架构：

如上图所示，也就是所谓的一主多从。主机和从机的数据完全一致，主机支持数据的写入和读取等各项操作，而从机则只支持与主机数据的同步和读取，也就是说，客户端可以将数据写入到主机，由主机自动将数据的写入操作同步到从机。主从模式很好的解决了数据备份问题，并且由于主从服务数据几乎是一致的，因而可以将写入数据的命令发送给主机执行，而读取数据的命令发送给不同的从机执行，从而达到读写分离的目的。下面我部署一个一主三从的例子。

我们都知道每个Redis实例都是一个单独的进程，都会有一个对应的进程。为了搭建一主三从这个例子，我准备以下三个配置文件：

角色

配置文件

监听端口

主

redis-6379.conf

6379

从

redis-6380.conf

6380

从

redis-6381.conf

6381

从

redis-6382.conf

6382

redis-6379.conf配置文件内容如下：

redis-6380.conf配置文件内容如下：

redis-6381.conf配置文件内容如下：

redis-6382.conf配置文件内容如下：

接下来使用以下命令启动Redis：

然后使用redis-cli命令连接Redis实例：

分别在三个命令行工具中执行一个get命令，获取键名为website的数据，如下所示：

可以看到，在三个redis实例中都不存在键为msg的数据，现在我们在主机6379上设置一个键为website的数据，如下所示：

可以看到设置成功了，此时我们在6380、6381和6382的实例上执行get website的命令，如下所示：

可以看到，虽然我们只是在6379的实例上设置了website这条数据，但是在6380、6381和6382的实例上也有了相应的数据，说明我们成功配置了redis的主从模式。

Redis sentinel哨兵配置

通过上面配置的最简单的主从模式，我们可以实现读写分离，解决了数据备份和单例可能存在的性能问题，但是也引入了新的问题。由于主从模式配置了四个redis实例，并且每个实例都使用不同的ip(如果在不同的机器上)和端口号，根据前面所述，主从模式下可以将读写操作分配给不同的实例进行从而达到提高系统吞吐量的目的，但也正是因为这种方式造成了使用上的不便，因为每个客户端连接redis实例的时候都是指定了ip和端口号的，如果所连接的redis实例因为故障下线了，而主从模式也没有提供一定的手段通知客户端另外可连接的客户端地址，因而需要手动更改客户端配置重新连接。另外，主从模式下，如果主节点由于故障下线了，那么从节点因为没有主节点而同步中断，因而需要人工进行故障转移工作。

为了解决上面的这个不能自动进行故障转移的问题，在2.8版本之后redis正式提供了sentinel(哨兵)架构。

Sentinel(哨兵)是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

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

监控(Monitoring): Sentinel会不断地定期检查主服务器和从服务器是否运作正常

提醒(Notification): 当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知

自动故障迁移(Automaticfailover): 当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器

当然了Redis sentinel的哨兵机制是一个非常复杂的机制，如果做更多的了解，推荐阅读《redis-Sentinel配置》和《Redis 高可用架构最佳实践》这两篇文章。我这里重点说说如何配置。

先根据上一节内容做好Redis主从模式配置。再看看sentienl规划：

角色

配置文件

监听端口

sentienl

sentinel-26379.conf

26379

sentienl

sentinel-26380.conf

26380

sentienl

sentinel-26381.conf

26381

建议哨兵至少部署3个，并且使用奇数个哨兵。Redis Sentinel的节点数量要满足2n+1(n>=1)的奇数个。

sentinel-26379.conf配置文件如下：

sentinel-26380.conf配置文件如下：

sentinel-26381.conf配置文件如下：

上述主要配置说明如下：

sentinel monitor mymaster 127.0.0.1 6379 2

表示sentinel监控的master的名字叫做mymaster，监控的的master地址为127.0.0.1，端口号为6379；行尾最后的2表示当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了

sentinel down-after-milliseconds mymaster 30000

表示master在多少毫秒内无反应，哨兵会开始进行master-slave间的切换，使用“选举”机制

sentinel parallel-syncs mymaster 1

在发生failover主备切换时，这个选项指定了最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态

sentinel failover-timeout mymaster 180000

同一个sentinel对同一个master两次failover之间的间隔时间

当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时所对应的最大时间

当想要取消一个正在进行的failover所需要的时间

当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了

接下来就是启动Redis和Redis sentinel了。启动顺序如下：

关于Redis Master和Redis Slave的启动命令上一节已经说了，这里说一下Redis Sentinel的启动命令：

启动成功后，我们可以通过redis-cli命令来连接sentinel，从而完成管理。

目前我们已经搭建好了Redis sentinel哨兵以及Redis Master-Slave。现在我们就可以通过关闭Master来模拟Master故障，从而检测Redis sentinel哨兵。

接下来，我们再连接sentinel，检查sentinel信息：

我们可以看到Master变成了127.0.0.1:6380。这个时候，Master-Slave信息如下：

很明显的，一主两备。

接下来，我们再将127.0.0.1:6379启动。

再次变成了一主三备。

Redis cluster集群配置

Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。当客户端操作的key没有分配到该node上时，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这有点儿像浏览器页面的302 redirect跳转。

Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务，具有以下特点：

无中心架构，支持动态扩容，对业务透明

具备Sentinel的监控和自动Failover能力

客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

高性能，客户端直连redis服务，免去了proxy代理的损耗

缺点是运维也很复杂，数据迁移需要人工干预，只能使用0号数据库，不支持批量操作，分布式逻辑和存储模块耦合等。

由于Redis cluster是redis官方提供的，目前官方一直都在维护中，具有代表性，建议生产使用。目前我们的生产环境的Redis就是使用的Redis cluster，已经经历过百万次调用的考验。

官方推荐集群至少需要六个节点，即三主三从。六个节点的配置文件基本相同，只需要修改端口号。Redis cluster规划如下：

角色

配置文件

监听端口

主

cluster-6383.conf

6383

主

cluster-6384.conf

6384

主

cluster-6385.conf

6385

备

cluster-6386.conf

6386

备

cluster-6387.conf

6387

备

cluster-6388.conf

6388

配置文件内容如下(只是端口号不同)：

现在，先使用redis-server命令将6个Redis节点启动。然后使用Redis官方提供的redis-trib.rb这个工具创建集群，比如这样：

在任意一台Redis节点上运行，不要在每台机器上都运行，一台就够了

但是要运行redis-trib.rb命令，我们的主机还是要安装一些软件的。而在一台新的机器上离线安装这些软件，会让你非常难受，下面就来说说如何离线安装这些软件：

离线安装ruby

可以在这里下载ruby源码。编译源码，然后进行安装：

离线安装zlib

可以在这里下载zlib源码。编译源码，然后进行安装：

离线安装rubygems

可以在这里下载rubygems源码。编译源码，然后进行安装：

安装rubygems的redis api

可以在这里下载rubygems的redis api。然后进行安装：

此时再执行以下命令就可以执行成功：

到此，关于redis cluster如何搭建就到此总结完毕。

Redis配置

关于Redis配置文件，这里需要分为两部分来说明，因为在Redis的安装包中，有以下两个配置文件的示例文件：

sentinel.conf

redis.conf

sentinel.conf配置文件说明

redis.conf配置文件说明

总结

这是一篇关于如何在CentOS 7上离线搭建Redis的文章，文章详细的总结了单节点搭建，简单的主从搭建，Sentinel搭建和Redis Cluster搭建。文章内容有点多，但是很全，其中搭建方式可以直接用于生产环境搭建。希望我的这篇文章能够帮助到大家。

果冻想，认真玩技术的地方。

2018年7月13日 于呼和浩特。