消息队列Stream
Stream相关的命令都以X开头可以通过XDD向stream中添加消息
XDD geekhour * course redis
XDD后面是key,*表示自动生成消息ID 添加消息的内容是“课程是redis”
XLEN geekhour //看key为geekhour的消息数量
XRANGE geekhour - +//查看消息详细内容 - +表示所有消息
XDEL geekhour id //删除一条消息 id为*自动生成的id
XTRIM geekhour MAXLEN 0// 删除所有消息
XADD geekhour 1-0 course git //手动写id添加消息
XADD geekhour 2-0 course docker
XADD geekhour 3-0 course redis
XREAD COUNT 2 BLOCK 1000 STREAMS geekhour 0//读2条消息,阻塞1000毫秒再读,从geekhour里读从索引0开始读取
XREAD COUNT 2 BLOCK 10000 STREAMS geekhour $//$表示从现在开始获取消息,阻塞10秒再获取消息
XGROUP CREATE geekhour group1 0//创建了一个叫做group1 的消费者组XGROUP 表示组命令
XINFO GROUPS geekhour//查看消费者组的信息,返回组的名称"name""group1",消费者数量"consumers""0",待处理消息数"pending""0","last-delivered-id""0-0","entries-read""null", "lag""4";
XGROUP CREATECONSUMER geekhour group1 consumer1//给消息队列geekhour,组group1,添加消费者consumer1
//通过XREADGROUP来读取消息,组group1,消费者consumer1,读2条,阻塞3秒从消息队列geekhour中最新(>)读取
XREADGROUP GROUP group1 consumer1 COUNT 2 BLOCK 3000 STREAMS geekhour >
地理空间Geospatial
key是地理位置信息的名字 城市就用city
[NX|XX]
精度和纬度
添加一条数据
city 116.405285 39.904989 beijing
添加四条数据
GEOADD city 121.472644 31.231706 shanghai 114.085947 22.547 shenzhen
37 23.125178 guangzhou 120.153576 30.287459 hangzhou
查询地理位置
GEOPOS city guangzhou
计算两地距离(m)加km就是以km为单位
GEODIST city shanghai beijing
GEODIST city shanghai beijing km
查询以城市shanghai为中心300 km为半径内的城市
GEOSEARCH city FROMMEMBER shanghai BYRADIUS 300 KM
HyperLogLog
HyperLogLog(HLL)是一种数据结构,用于在大数据集合中估计基数(不重复元素的数量),而无需存储每个元素。它通常用于在大规模数据集上执行近似基数计数,例如统计网站的独立访客数量或者社交媒体上的唯一用户数,而无需存储每个用户的详细信息。 HyperLogLog的优点在于它提供了一种在内存效率和计算效率之间取得良好平衡的方法。
往course里添加3门课程
PFADD course git docker redis
统计个数
PFCOUNT course
添加另一门课程course2
PFADD course2 git go
融合两门课程
PFMERGE course course2
统计融合后course的个数
PFCOUNT course
位图Bitmap
在Redis中,Bitmap是一种数据结构,用于存储位图或位数组。它由一系列位(通常是0或1)组成,每个位代表一种状态或标记。Bitmap可以用于解决各种问题,例如跟踪用户的在线状态、统计用户的活跃度、进行布隆过滤器等。
在Redis中,Bitmap通常使用字符串类型来表示。Redis提供了一系列针对Bitmap的命令,包括设置位、获取位、计算位的数量、对位进行逻辑运算等。Bitmap的一个重要特性是它非常节省空间,因为它只存储每个位的状态,而不是像集合那样存储每个元素。
举例来说,可以使用Bitmap来跟踪用户的签到情况。对于每个用户,可以用一个Bitmap来表示一年中的签到情况,其中每一位代表一天,位的值表示用户是否在该天签到。通过使用Bitmap,可以高效地存储和查询大量用户的签到数据。
设key为xuexi的位图第0位的值为1
SETBIT xuexi 0 1
设key为xuexi的位图第1位的值为0
SETBIT xuexi 1 0
融合两门课程
PFMERGE course course2
获取第0位的值
GETBIT xuexi 0
以字符串的方式设置位图, "\xF0"用二进制表示是11110000
SET xuexi "\xF0"
获取第0到7位的值
GETBIT xuexi 0
GETBIT xuexi 1
GETBIT xuexi 2
GETBIT xuexi 3
GETBIT xuexi 4
GETBIT xuexi 5
GETBIT xuexi 6
GETBIT xuexi 7
返回第一次出现0的位
BITPOS xuexi 0
位域Bitfield
在Redis中,位域(Bitfield)是一种用于执行位级操作的命令,允许对字符串中的位进行读取和设置。这个命令允许用户以原子方式执行一系列位操作,例如读取、设置、反转、计数等。位域命令使得Redis可以在位级别上进行高效的操作,例如实现简单的布隆过滤器、跟踪用户行为、进行计数等。
位域命令通常使用一个或多个操作符来指定对位进行的操作,例如GET、SET、INCRBY等。它还可以指定偏移量和位数,以确定要操作的位的范围。通过这些命令,可以在字符串中的位级别上执行各种操作,而不必关心整个字符串的内容。
举例来说,可以使用位域命令来跟踪用户的在线状态。每个用户可以用一个位字符串来表示,其中每个位代表一个时间段(例如每分钟或每小时),位的值表示用户是否在线。通过使用位域命令,可以高效地记录和查询大量用户的在线状态。
你刚刚出生在新手村,等级是1级,兜里有100个金币,可以使用BITFIELD命令来设置
BITFIELD player:1 set u8 #0 1
key:player:1
表示你的id,u8
表示8位无符号整数,#0
表示第一个位置,1
表示1级
获取player:1的内存信息,
GET player:1
返回"\x01"
表示十六进制的01
想要获取player:1的角色等级
BITFIELD player:1 get u8 #0
可以看到返回了1
设置一个金钱
BITFIELD player:1 set u32 #1 100
查看内存使用情况
获取金钱
现在play:1使出浑身解数杀掉一个哥布林,获得100金币,并且等级也升到2级
BITFIELD player:1 incrby u32 #1 100
返回结果是你当前的余额
BITFIELD player:1 incrby u8 #0 1
事务
事务是指一组命令的集合,这些命令作为一个单独的执行单元被执行。Redis使用MULTI、EXEC、DISCARD和WATCH这四个命令来实现事务。以下是这些命令的简要说明:
-
MULTI: 开启一个事务,之后的命令将被放入事务队列中等待执行。
-
EXEC: 执行事务队列中的所有命令。如果事务执行成功,则返回事务中所有命令的执行结果;如果其中一个命令执行失败,事务将会回滚,之前执行的命令不会生效。
-
DISCARD: 取消当前事务,清空事务队列中的所有命令。
-
WATCH: 监视一个或多个键,如果在事务执行期间这些键被其他客户端修改,事务将被取消。
使用事务可以确保一系列操作的原子性,即要么全部执行成功,要么全部执行失败,这样可以保证数据的一致性。需要注意的是,Redis事务并不支持回滚到某个中间状态,只能保证事务的原子性。
- 先向数据库里添加3条key-value
- 开启事务
- 对每个value执行+1操作
- 执行事务
返回结果显示只有k1和k3执行成功,k2报错失败,虽然事务中有些指令报错了,但并不会影响其他指令的执行。
持久化
在Redis中,持久化是指将数据从内存保存到磁盘以保证数据在重启时不会丢失的过程。Redis提供了两种主要的持久化方式:RDB(Redis Database)和AOF(Append Only File)。
- RDB持久化:
- RDB持久化是将Redis在某个时间点的数据快照保存到磁盘上。
- 当启用RDB持久化时,Redis会在指定的时间间隔内将内存中的数据保存到磁盘上,生成一个快照文件。
- 这种方式适合用于备份数据或者进行数据迁移。
- AOF持久化:
- AOF持久化是将Redis的写操作记录以追加的方式保存到磁盘上的文件中。
- AOF文件记录了Redis服务器接收到的每个写操作指令,例如SET、INCR等。
- 在Redis重启时,会通过重新执行AOF文件中的指令来恢复数据,从而保证数据的完整性。
- AOF持久化相比RDB持久化更加可靠,因为它可以提供更精确的数据恢复,但相应地,AOF文件会比RDB文件大。
除了以上两种持久化方式外,Redis还支持使用混合持久化,即同时使用RDB和AOF持久化。这样可以在RDB和AOF之间取得平衡,既可以获得快速的恢复速度,又可以保证数据的安全性。
开启RDB
可以通过save <seconds> <changes>
来配置
save 3600 1
表示1个小时之内只要有一次修改就进行一次快照
开启AOF
只需要把配置文件中的appendonly
的值改成yes就行
主从复制
在Redis中,主从复制是一种用于数据备份、读写分离以及提高系统可用性的机制。它允许将一个Redis服务器(主节点)的数据复制到多个其他Redis服务器(从节点)上。
以下是Redis主从复制的主要特点和工作原理:
- 特点:
- 主从复制可以实现数据的热备份,增加系统的可用性和容错性。
- 允许在主节点上进行写操作,同时从节点可以用于读操作,实现读写分离,从而提高系统的性能和扩展性。
- 主从复制可以用于实现数据分布式部署,将负载均衡在多个从节点上,降低主节点的压力。
- 可以通过从节点来进行灾难恢复,在主节点发生故障时,从节点可以被晋升为新的主节点,继续提供服务。
- 工作原理:
- 主节点将自己的数据变更操作记录在内存中的AOF文件或者RDB文件中。
- 从节点连接到主节点,并发送SYNC命令请求数据同步。
- 主节点在收到SYNC命令后,开始将自己的数据发送给从节点。
- 从节点接收到数据后,将其应用到自己的数据库中,从而使得从节点的数据和主节点保持一致。
- 一旦初始化同步完成,从节点会持续地通过主节点接收到的命令来更新自己的数据,以保持与主节点的数据同步。
- 主节点会定期发送心跳包给从节点,检测从节点的状态,确保连接的可靠性
在配置主从复制时,需要在从节点的配置文件中指定主节点的地址和端口,并启动从节点,它会自动连接到主节点并开始复制数据。同时,主节点需要开启对外的监听以供从节点连接,并允许对应的网络访问。
总的来说,主从复制可以提高Redis系统的可用性、容错性和扩展性,是实现高可用Redis架构的重要组成部分。
修改从节点配置
- 通过命令行设置(不常用)---
slaveof host port
orreplicaof host port
- 通过修改配置文件设置
通过修改配置文件设置
在Redis中配置从节点的host和port来实现主从复制需要修改从节点的配置文件,一般是redis.conf
文件。以下是一个简单的Linux代码示例,假设从节点的配置文件位于 /etc/redis/redis.conf:
#!/bin/bash
# 停止从节点
sudo systemctl stop redis
# 备份原始配置文件
sudo cp /etc/redis/redis.conf /etc/redis/redis.conf.bak
# 修改配置文件中的主从复制相关配置
sudo sed -i 's/^# slaveof <masterip> <masterport>/slaveof <master_host> <master_port>/' /etc/redis/redis.conf
# 请将 <master_host> 和 <master_port> 替换为实际的主节点的主机名和端口号
# 启动从节点
sudo systemctl start redis
这段代码的主要步骤如下:
- 停止从节点的Redis服务以避免配置文件冲突。
- 创建原始配置文件的备份.放到redis安装目录根目录,作为主节点配置文件
- 使用
sed
命令修改配置文件中的slaveof
配置项,指定主节点的主机名和端口号。 - 启动从节点的Redis服务。
回到根目录,复制一份redis.conf
-->redis-6380.conf
配置文件把 redis-6380.conf
作为从节点的配置文件
6380就是从节点端口号
打开配置文件
- 改端口号为6380,
- pidfile文件改成6380进程id,为了和主节点pidfile区分开,在后面加端口号
- dbfilename dump-6380.rdb 后面也加上端口号(持久化文件)
- replicaof 配置主节点host和port
哨兵模式
在Redis中,哨兵模式(Sentinel)是一种用于实现高可用性(High Availability)的机制。它可以监控Redis主从复制架构中的主节点,并在主节点出现故障时自动将一个从节点晋升为新的主节点,从而保证系统的持续可用性。
以下是Redis哨兵模式的主要特点和工作原理:
- 特点:
- 自动故障检测和故障转移:哨兵会定期检测主节点和从节点的健康状态,一旦发现主节点故障,会自动将一个从节点晋升为新的主节点。
- 配置中心:哨兵可以作为一个集中式的配置中心,负责管理多个Redis实例的配置信息。
- 客户端重定向:哨兵可以告知客户端主节点发生变化,并重定向客户端的请求到新的主节点上,以保证客户端可以无缝切换到新的主节点
- 工作原理:
- 哨兵集群中包含多个哨兵节点,它们通过选举机制选出一个领导者(leader)节点,负责协调监控和故障转移操作。
- 每个哨兵节点会定期向Redis实例发送PING命令来检测其健康状态,并收集各个节点的信息。
- 当主节点出现故障或不可达时,哨兵会进入自动故障转移流程:
- 哨兵会通过选举协议选出一个新的主节点。
- 选出的新主节点会将自己的信息广播给其他哨兵节点和客户端。
- 客户端收到新主节点信息后,会更新连接地址并重新连接。
- 故障转移过程中,哨兵会使用Quorum机制确保故障转移的可靠性,例如要求多数派哨兵同意故障转移操作才能执行。
哨兵模式可以保证Redis系统的高可用性和容错性,在主节点发生故障时实现自动切换,无需人工干预。它是构建可靠Redis集群的重要组成部分,特别适用于对数据可用性要求较高的生产环境。
代码实现
以下是一个简单的示例,演示如何使用Redis哨兵模式来实现高可用性的Redis集群。假设我们有一个Redis主从复制的架构,其中包含一个主节点、两个从节点和三个哨兵节点。
- 首先,我们需要启动三个Redis哨兵节点。假设它们分别运行在三台服务器上,端口分别为26379、26380和26381。在每台服务器上创建一个配置文件(例如
sentinel.conf
),配置如下:
port 26379
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
这里配置了哨兵节点的端口、监控的主节点地址和端口、主节点失联后的判断时间、执行故障转移的超时时间等信息。
- 在每台服务器上启动哨兵节点:
redis-server /path/to/sentinel.conf --sentinel
- 接下来,我们需要启动一个Redis主节点和两个从节点。假设它们分别运行在三台服务器上,端口分别为6379、6380和6381。在每台服务器上创建一个配置文件(例如
redis.conf
),配置如下:
port 6379 # 主节点的端口
bind 127.0.0.1
port 6380 # 第一个从节点的端口
bind 127.0.0.1
slaveof 127.0.0.1 6379 # 设置主节点地址和端口
port 6381 # 第二个从节点的端口
bind 127.0.0.1
slaveof 127.0.0.1 6379 # 设置主节点地址和端口
- 在每台服务器上启动Redis节点:
redis-server /path/to/redis.conf
至此,我们已经成功地搭建了一个包含一个主节点、两个从节点和三个哨兵节点的Redis高可用集群。哨兵节点会监控主节点的健康状态,一旦主节点发生故障,会自动执行故障转移操作,将一个从节点晋升为新的主节点,从而保证系统的高可用性。
标签:配置文件,Redis,redis,哨兵,节点,geekhour From: https://www.cnblogs.com/tigerWei/p/18088436