Redis进阶

卑微的cv工程师
275 阅读6分钟

Redis持久化机制

RDB

rdb：持久话的是数据本身，也就是给数据做一次快照。

达到某个条件进行快照

如：

save 900 1   900秒内有1此修改

save 300 10 300秒内有10此修改

save 60  10000   60秒内有1w次修改

优点：

  1. rdb是二进制文件，占用空间小。

  2. 在恢复数据时，redis会启用一个子进程，不会占用父进程，异步，redis是单线程的（多路复用）

缺点：会丢失最后一次快照后修改的数据。

AOF

aof:持久化保存的是一系列指令，把生成数据的命令保存到硬盘上的文件中。

保存方式

  • 每秒保存一次（推荐）

save操作使用的子进程的方式，不会占用主进程。

  • 每修改一次就保存一次

会执行write和save操作，这里的save在主进程调用，可能会造成阻塞。

aof文件重写

aof重写保证了数据最终一致性，省略了部分中间步骤，使得文件变小。

优点：理论上可以保证数据完整性，但是性能又比较差。修改一次保存一次

缺点：aof文件比较大，恢复速度比rdb要慢。

RDB和AOF

一般进行持久化操作时，两种方式并存。
方式：先用rdb进行数据恢复，再使用aof进行数据补全。

Redis事务控制

redis虽然支持事务，但是不支持回滚（所以了解即可），并且执行了事务也不一定对。

事务控制

加入队列时错误

遇到了入队时即可检测到的错误，整个队列都不会执行。

执行队列时出错

错误在入队列时检测不出来，整个队列执行时有错的命令，而执行失败，且不支持回滚。

为什么不支持回滚

官方：

如果你有使用关系式数据库的经验， 那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。以下是这种做法的优点：
1.Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。

2.因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。

乐观锁和悲观锁

乐观锁

认为当前环境下不容易发生碰撞，所以执行操作前不加锁，如果发生了碰撞，会检查版本号：

  • 如果是基于最新版本修改的，执行操作，服务器接受，修改成功。
  • 如果不是，服务器不接受，修改失败，整个MULTI队列中的操作都被丢弃。

Redis主从复制机制

读写分离的好处

  • 性能优化：服务器只专注于一件事，主服务器只专注于写操作，可以用更适合写入数据的工作模式，从服务器只专注于读操作，可以用更适合读取数据的模式工作。
  • 强化数据安全，避免单点故障：由于数据同步机制的存在，各个服务器之间数据保持一致，所以其中某个服务器宕机不会导致数据丢失或者无法访问。

搭建步骤

  1. 创建三个不同的配置文件，在执行时，分别带入不同的配置文件参数。
mkdir /usr/local/cluster-redis

redis6000.conf
redis7000.conf
redis8000.conf

redis6000.conf修改的位置有

daemonize yes
dir /usr/local/cluster-redis
port 6000
dbfilename dump6000.rdb
logfile /var/logs/redis6000.log
pidfile /var/run/redis6000.pid


7000 和 8000直接对6000进行复制，替换6000即可

cp redis6000.conf redis7000.conf
命令行模式下
:%s/6000/7000
查询7000
:/7000
  1. 分别启动三个redis
/usr/local/redis/bin/redis-server ./redis6000.conf
/usr/local/redis/bin/redis-server ./redis7000.conf
/usr/local/redis/bin/redis-server ./redis8000.conf
  1. 查看redis进程
ps -ef | grep redis | grep -v grep (-v表示去除grep查询)
  1. 查看redis端口
netstat -anp | grep redis
  1. info replication (查看信息（主服务器为谁，多少台从）)
  2. 建立主从关系
slaveof 127.0.0.1 6000 (给其他端口的redis设置主服务器为6000redis)
  1. 取消主从关系
slaveof no one

注意

  • 在没有哨兵的情况下，主服务器挂了，从服务器不会自动晋升，且关联的主服务器不会改变。
  • 从服务器宕机，恢复后，不会自动关联主服务器。
  • 读写分离，从服务器只能读。

哨兵模式

意义

通过哨兵服务器监控master/slave实现主从复制集群的自动管理。

监控的相关概念

主观下线

有一台哨兵检测到某个节点服务器下线。

客观下线

认为某个节点服务器下线的哨兵服务器达到指定数量。这个数量后面在哨兵的启动配置文件中指定（一般为过半的哨兵检测到某个节点的服务器下线）。
注意：只有 master 服务器做客观下线的判断， slave 只做主观下线的判定。

心跳检查

客户端为了确认服务器是否存活，不断的向服务器发送很小的数据包，服务器在一定时间内返回了数据包，证明服务器是否存活。

配置

vim /usr/local/cluster-redis/sentinel.conf
格式sentinel monitor 为主机命名 主机IP 主机端口号 将主机判定为下线时需要Sentinel同意的数量
例子sentinel monitor mymaster 127.0.0.1 6000 1

直接插入文件内即可。

启动

启动哨兵

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

注意：还是使用redis-server启动，最后要加--sentinel表示当前时哨兵。

启动哨兵 image.png 关闭8000

image.png 重启8000

image.png

关闭6000

image.png

重启选举

image.png

选举为7000

image.png

重启6000，成为从服务器

image.png

选举

  • 情况1：
    • slave A：投票给 slave B
    • slave B：投票给 slave A
    • 两个服务器各得一票，平手，不能确定，需要继续投票
  • 情况2：
    • slave A：投票给自己
    • slave B：投票给自己
    • 两个服务器各得一票，平手，不能确定，需要继续投票
  • 情况3：
    • slave A：投票给自己
    • slave B：投票给 slave A
    • slave A 得 2 票，slave B 没有得票，所以 slave A 当选

发布订阅（消息队列）

订阅一个频道

SUBSCRIBE cctv

发送消息给队列

PUBLISH cctv nihao

收到推送的消息

SUBSCRIBE cctv

Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "cctv"
3) (integer) 1
1) "message"
2) "cctv"
3) "nihao"
avatar
文章
阅读
粉丝