【redis-基础】数据持久化 事务 发布订阅

1 数据持久化

1.1 RDB方式

1.1.1 配置

// 定时持久化规则
save 900 1
save 300 10
save 60 10000
# 默认值为yes，当启用了RDB且最后一次在后台保存数据失败，Redis是否停止接收数据：
# yes代表可以继续写入数据；no代表不会写入成功，通知用户持久化出现错误
stop-writes-on-bgsave-error yes
# 持久化的数据是否进行压缩
rdbcompression yes
# 存储的快照是否进行CRC64算法的数据校验，如果希望获取到最大的性能提升，可以关闭此功能
Rdbchecksum yes
# 设置快照的文件名，默认是dump.rdb
dbfilename dump.rdb

1.1.2命令

命令	示例	解释
save	save	save命令将内存数据的镜像保存为RDB文件。 由于Redis是以单线程方式执行命令，因此save命令执行期间会阻塞Redis服务进程
bgsave	bgsave	执行bgsave命令时Redis还能继续处理客户端的操作

1.2 AOF方式

RDB全量备份总是非常耗时的，而且不能提供强一致性（Strict Consistency），如果Redis进程崩溃，那么在最近一次RDB备份之后的数据也会随之消失。AOF（Append Only File）以独立日志的方式记录每次的写命令，可以很好地解决了数据持久化的实时性。

1.2.1 配置

# 开启AOF持久化
appendonly yes
# AOF文件名
appendfilename "appendonly.aof"
# AOF文件存储路径
dir "/opt/app/redis6/data"
# aof文件比上次重写时增长100%(配置可以大于100%)时触发重写[auto-aof-rewrite-percentage
100
# aof文件大小超过64MB时触发重写
auto-aof-rewrite-min-size 64mb
// aof 持久化策略，任选一个，默认是everysec
# appendfsync always
# appendfsync everysec
# appendfsync no

1.2.2 命令

命令	示例	解释
bgrewriteaof	bgrewriteaof	重写操作

1.3 区别

方式	RDB	AOF
启动优先级	低	高
体积	小	大
恢复性能	速度快	速度慢
数据安全性	丢数据	根据策略配置

2 事务

Redis事务的本质是一组命令的集合 。

事务支持一次执行多个命令，一个事务中的所有命令都会被序列化。

在事务执行过程中会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入事务执行命令序列中。

multi、exec、discard和watch是Redis中事务的基础。

• watch key：监听一个或多个键（key），如果在事务执行之前被监听的键被其他客户端改动了，则事务被打断。
• multi：标记一个事务块的开始。
• exec：执行事务块内的所有命令。
• discard：取消事务，放弃事务块中的所有命令。
• unwatch：取消watch对所有键的监视。

2.1 事务使用

• 开启：以multi开启一个事务。
• 入队：将多个命令加到事务中，事务接到这些命令后并不会立即执行，而是放到等待执行的事务队列中。
• 执行：由exec命令触发事务的执行。

2.2 事务性质

• 原子性
  • 数据库将事务中的多个命令作为一个整体来执行，服务器要么执行事务中的所有命令，要么一个命令也不执行 ；
  • Redis不支持事务回滚机制
• 一致性
  • 如果数据库在执行事务之前是一致的，那么在事务执行之后无论事务是否执行成功，数据库仍然应该是一致的
• 隔离性
  • 即使数据库中有多个事务并发执行，各个事务之间也不会互相影响，并且在并发状态下执行的事务和串行状态下执行的事务产生的结果完全相同。
  • 因为Redis使用单线程（执行命令的线程只有一个）的方式来执行事务，并且服务器保证在执行期间不会中断事务，Redis的事务总是以串行的方式执行，因此事务也总是具有隔离性。
• 持久性
  • 当一个事务执行完毕时，执行这个事务所得的结果已经被保存到硬盘中，即使服务器在事务执行完毕之后停机，执行事务所得的结果也不会丢失。
• 安全性
  • 当服务器接收到一个客户端发来的exec命令时，服务器会根据这个客户端是否打开了REDIS_DIRTY_CAS标识来决定是否执行事务。

3 发布订阅

3.1 命令

命令	示例	解释
publish	publish mychannel helloworld	发布消息到mychannel
subscribe	subscribe mychannel1 mychannel2	订阅指定的一个或多个频道
psubscribe	psubscribe mychan*	订阅一个或多个符合指定模式的频道
unsubscribe	unsubscribe mychannel1	退订一个或多个频道
punsubscribe	punsubscribe mychann*	退订一个或多个符合指定模式的频道

3.2 与kafka区别

区别	redis	kafka
持久化	无法持久化	将数据持久化到磁盘内
端点消费	当订阅者断开后重连时断开期间发布者发布的消息会丢失	Kafka中会记录每个消费者消费的主题（topic）的偏移量（offset），因此Kafka可以从断开的偏移量继续消费
偏移量	Redis发布和订阅根本不会记录订阅者消费的偏移量	Kafka的消费者可以指定从某个偏移量开始重新消费
消费方式	数据消费情况是由发布者控制的，当发布者把消息发布到频道中后， 只有当前连接了频道的订阅者才能消费数据，断开后重连的订阅者会失去那部分数据	Kafka中消费进度是由消费者控制的，消费者从主题中拉取数据并记录消费的偏移量
消费者组	同kafka	不同的消费者组中的消费者消费相同的主题时会各自维护一个偏移量，因此不会出现A消费之后的数据B就消费不到的情况