redis原理和使用-安装和分布式配置

最新推荐文章于 2024-08-15 09:33:44 发布

还是转转

最新推荐文章于 2024-08-15 09:33:44 发布

阅读量262

点赞数

分类专栏：缓存系统工具

本文链接：https://blog.csdn.net/xiaoyi52/article/details/105235638

版权

工具同时被 2 个专栏收录

41 篇文章 5 订阅

订阅专栏

缓存系统

6 篇文章 0 订阅

订阅专栏

在之前的blog中，介绍过redis分布式锁实现。在日程的工作中，redis也使用得非常频繁，包括缓存，分布式锁，消息队列等。本系列将系统性地对redis做一个完整的介绍和总结。

Redis服务安装和远程访问

Redis安装网上教程很多，这里就不介绍了。

安装好之后可通过redis-server启动，通过客户端redis-cli进行访问，默认使用6379端口（本文环境为ubuntu+redis3.0.6)。

如果要在远程访问redis服务器，则需要在启动的时候指定redis.conf配置文件，并修改redis配置文件参数。将下行注释掉：
# bind 127.0.0.1
如果不注释，从远程访问时会报错：
Could not connect to Redis at ip:6379: Connection refused。
从而只能在本地访问。

注释掉绑定ip后，通过ps -ef | grep redis找到服务进程，通过kill -9 [pid]杀死服务进程并重启服务（如果开启了守护进程，则杀死之后就会重启，可通过/etc/init.d/redis-server stop来停止）。此时可远程访问redis服务器了。
可通过info命令来查看redis服务器相关信息，如下图所示：
在这里插入图片描述
输入config get requirepass可看到结果为:

此时，redis服务器是没有密码的。这种情况存在着安全隐患，即未授权登录。无需认证即可访问到内部数据，可导致敏感信息泄露，也可以恶意执行flushall来清空所有数据。
因此为了保证安全，通常会设置登录密码：
通过config set requirepass [password]可以设置临时密码。设置成功后再进行任何操作都会提示：

(error) NOAUTH Authentication required.

可通过auth [password]进行认证。
但这种设置方式在服务器重启之后无效，要想使密码认证一直有效，同样需要修改redis.conf配置文件：
在这里插入图片描述
并重启服务。

Redis集群

Redis有三种集群模式，分别是主从模式，哨兵(Sentinel)模式和集群(Cluster)模式。

主从模式（Master-Slave）

主从模式比较简单，跟mysql的主从模式类似，由一个主节点和多个从节点组成。主节点提供写能力，从节点提供读能力。主从模式的问题在于：master节点在主从模式中唯一，若master挂掉，则redis无法对外提供写服务。

部署

主节点ip：10.241.149.44，端口6379。
从节点ip：本机。端口分别为6381和6382。

现有本机目录/usr/local/redis-node/6381和/usr/local/redis-node/6382。将redis.conf分别拷贝到这两个目录。修改6381下的配置文件：

port 6381
...
masterauth xxx # 主节点开启了密码，则需要配置。见上文
...
slaveof 10.241.149.44 6379  # 配置主从模式

类似地修改6382下的配置文件。

最后，启动两个从节点：

redis-server /usr/local/redis-node/6381/redis.conf
redis-server /usr/local/redis-node/6382/redis.conf

连接上主节点：
redis-cli -h 10.241.149.44 -p 6379
写入：10.241.149.44:6379> set user howe成功
连接上从节点：redis-cli -p 6381
读取user：

127.0.0.1:6381> get user
"howe"

说明主节点上的数据同步到了从节点。
如果此时在从节点上写入，就会提示：
(error) READONLY You can't write against a read only slave.

哨兵模式(Sentinel)

主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此sentinel应运而生。

Sentinel中文含义为哨兵，顾名思义，它的作用就是监控redis集群的运行状况。当发现主节点挂掉以后，它会选举一个从节点升级为主节点，并让其他从节点从这个新的主节点进行数据同步。

sentinel因为也是一个进程，有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群。

当使用sentinel模式的时候，客户端不要直接连接Redis，而是连接sentinel，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。

部署

在主从模式已搭建的基础上，可以进一步搭建哨兵模式。
redis主节点为10.241.149.44:6379，两个从节点为本机：10.234.209.24:6381, 10.234.209.24:6382。
将两个从节点的配置文件中的bind 127.0.0.1改成bind 0.0.0.0，以便远程客户端能够访问。
同时，哨兵模式下从节点可能会切换为主节点，因此从节点和主节点地位同等，配置需要保持一致，将两个从节点的requirepass打开。

假设现有本地目录：
/usr/local/redis-sentinel。在该目录下创建s1，s2，s3，然后将sentinel.conf分别拷贝至s1，s2，s3下。Sentinel.conf初始内容如下：

port 26379
dir /tmp
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
# 主节点别名,ip,端口,确认master失效的哨兵数
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

修改s1的sentinel配置文件：
添加：

daemonize yes
logfile “/usr/local/redis-sentinel/s1.log”

修改监听的主节点为：

sentinel monitor mymaster 10.241.149.44 6379 2

如果主节点开启了密码，则还需添加密码认证：

sentinel auth-pass mymaster <password>

其余参数保持不变。
同理修改s2，s3的sentinel配置文件。

以指定配置文件的方式启动三个哨兵：

redis-sentinel /usr/local/redis-sentinel/s1/sentinel.conf
redis-sentinel /usr/local/redis-sentinel/s2/sentinel.conf
redis-sentinel /usr/local/redis-sentinel/s3/sentinel.conf

这里将三个哨兵放到同一台机器上，实际上为了避免单点故障，通常哨兵是部署在不同的机器上的。

现在kill掉主节点的redis服务进程。打开s1.log，可以看到进行了故障迁移：
在这里插入图片描述
说明如下：

*****s1节点哨兵端口为26379，监听另外两个哨兵节点26380和26381，监听主节点10.241.149.44 6379*****
10343:X 23 Apr 16:08:38.511 * +sentinel sentinel 10.234.209.24:26380 10.234.209.24 26380 @ mymaster 10.241.149.44 6379
10343:X 23 Apr 16:08:41.549 * +sentinel sentinel 10.234.209.24:26381 10.234.209.24 26381 @ mymaster 10.241.149.44 6379
*****监听到redis主节点下线*****
10343:X 23 Apr 16:10:40.093 # +sdown master mymaster 10.241.149.44 6379
*****选举一个新的redis主节点*****
10343:X 23 Apr 16:10:40.236 # +new-epoch 1
10343:X 23 Apr 16:10:40.242 # +vote-for-leader 9528d63b865c3fb8773c8ac6cfb52cb0a702f3e5 1
*****三个哨兵投票，满足2个确认的条件，认为redis主节点确实已下线*****
10343:X 23 Apr 16:10:41.186 # +odown master mymaster 10.241.149.44 6379 #quorum 3/2
10343:X 23 Apr 16:10:41.186 # Next failover delay: I will not start a failover before Thu Apr 23 16:16:40 2020
*****更新哨兵配置文件*****
10343:X 23 Apr 16:10:41.337 # +config-update-from sentinel 10.234.209.24:26380 10.234.209.24 26380 @ mymaster 10.241.149.44 6379
*****切换redis主节点为6382节点(原来的两个从节点之一)*****
10343:X 23 Apr 16:10:41.338 # +switch-master mymaster 10.241.149.44 6379 10.234.209.24 6382
10343:X 23 Apr 16:10:41.338 * +slave slave 10.234.209.24:6381 10.234.209.24 6381 @ mymaster 10.234.209.24 6382
10343:X 23 Apr 16:10:41.338 * +slave slave 10.241.149.44:6379 10.241.149.44 6379 @ mymaster 10.234.209.24 6382
*****此时，原redis主节点切换成了从节点，并且是下线状态*****
10343:X 23 Apr 16:11:11.397 # +sdown slave 10.241.149.44:6379 10.241.149.44 6379 @ mymaster 10.234.209.24 6382

查看s2.log和s3.log,大体过程都差不多。

此时打开s1节点的sentinel.conf配置文件可以发现，监听的主节点自动更新为：

sentinel monitor mymaster 10.234.209.24 6382 2

s2和s3的配置文件也是一样的被自动更新了。

再启动原来的主节点10.241.149.44:6379，发现s1.log多了一行日志：

10343:X 23 Apr 16:55:53.487 # -sdown slave 10.241.149.44:6379 10.241.149.44 6379 @ mymaster 10.234.209.24 6382

说明此时这个节点是作为从节点重新上线。

sentinel操作
连接上任意一个哨兵：
redis-cli -p 26379

查看主节点状态：
在这里插入图片描述
查看从节点状态：sentinel slaves mymaster

代码连接

在哨兵模式下，主节点和从节点是动态变化的，其状态有哨兵群管理。因此客户端连接redis服务器时，需要通过哨兵进行连接。

配置如下：

[redis]
host = 10.234.209.24:26379,10.234.209.24:26380,10.234.209.24:26381
pass = root
timeout = 100

代码示例：

import settings
from redis.sentinel import Sentinel

sentinels = []
host_list = settings.get('redis', 'host').split(",")
for host in host_list:
    ip = host.split(":")[0]
    port = host.split(":")[1]
    sentinels.append((ip, port))
sentinel = Sentinel(sentinels=sentinels)


service_name = "mymaster"

redis_master = sentinel.master_for(service_name=service_name, password=settings.get('redis', 'pass'))
redis_slave = sentinel.slave_for(service_name=service_name, password=settings.get('redis', 'pass'))

redis_master.set("user", "test")  # 主节点写入
print redis_slave.get("user")  # 从节点读取