标签：name inf 事物 car 操作记录 客户端 info href red
Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：
事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
一个事务从开始到执行会经历以下三个阶段：
开始事务。
命令入队。
执行事务。
下表列出了 redis 事务的相关命令：
|
序号 |
命令及描述 |
|
1 |
DISCARD |
|
2 |
EXEC |
|
3 |
MULTI |
|
4 |
UNWATCH |
|
5 |
WATCH key [key ...] |
什么是Redis持久化,就是将内存数据保存到硬盘。
Redis 持久化存储 (AOF 与 RDB 两种模式)
RDB 是以二进制文件，是在某个时间 点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。
优点：
使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能
缺点：
RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候
这里说的这个执行数据写入到临时文件的时间点是可以通过配置来自己确定的，通过配置redis 在 n 秒内如果超过 m 个 key 被修改这执行一次 RDB 操作。这个操作就类似于在这个时间点来保存一次 Redis 的所有数据，一次快照数据。所有这个持久化方法也通常叫做 snapshots。
RDB 默认开启，redis.conf 中的具体配置参数如下：
|
#dbfilename：持久化数据存储在本地的文件 dbfilename dump.rdb #dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下 dir ./ ##snapshot触发的时机，save ##如下为900秒后，至少有一个变更操作，才会snapshot ##对于此值的设置，需要谨慎，评估系统的变更操作密集程度 ##可以通过“save “””来关闭snapshot功能 #save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key300s进行存储；更改10000个key60s进行存储。 save 900 1 save 300 10 save 60 10000 ##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等 stop-writes-on-bgsave-error yes ##是否启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间 rdbcompression yes |
Append-only file，将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在 append 操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程；当 server 需要数据恢复时，可以直接 replay 此日志文件，即可还原所有的操作过程。AOF 相对可靠，它和 mysql 中 bin.log、apache.log、zookeeper 中 txn-log 简直异曲同工。AOF 文件内容是字符串，非常容易阅读和解析。
优点：
可以保持更高的数据完整性，如果设置追加 file 的时间是 1s，如果 redis 发生故障，最多会丢失 1s 的数据；且如果日志写入不完整支持 redis-check-aof 来进行日志修复；AOF 文件没被 rewrite 之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）。
缺点：
AOF 文件比 RDB 文件大，且恢复速度慢。
我们可以简单的认为 AOF 就是日志文件，此文件只会记录“变更操作”(例如：set/del 等)，如果 server 中持续的大量变更操作，将会导致 AOF 文件非常的庞大，意味着 server 失效后，数据恢复的过程将会很长；事实上，一条数据经过多次变更，将会产生多条 AOF 记录，其实只要保存当前的状态，历史的操作记录是可以抛弃的；因为 AOF 持久化模式还伴生了“AOF rewrite”。
AOF 的特性决定了它相对比较安全，如果你期望数据更少的丢失，那么可以采用 AOF 模式。如果 AOF 文件正在被写入时突然 server 失效，有可能导致文件的最后一次记录是不完整，你可以通过手工或者程序的方式去检测并修正不完整的记录，以便通过 aof 文件恢复能够正常；同时需要提醒，如果你的 redis 持久化手段中有 aof，那么在 server 故障失效后再次启动前，需要检测 aof 文件的完整性。
AOF 默认关闭，开启方法，修改配置文件 reds.conf：appendonly yes
|
##此选项为aof功能的开关，默认为“no”，可以通过“yes”来开启aof功能 ##只有在“yes”下，aof重写/文件同步等特性才会生效 appendonly yes
##指定aof文件名称 appendfilename appendonly.aof
##指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec appendfsync everysec ##在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no” no-appendfsync-on-rewrite no
##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb” auto-aof-rewrite-min-size 64mb
##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。 ##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后 ##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。 auto-aof-rewrite-percentage 100
|
AOF 和 RDB 各有优缺点，这是有它们各自的特点所决定：
RDB是在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。
优点：
使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能
缺点：
RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候
Append-only file，将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后(已经写入到文件或者即将写入)，才进行实际的数据变更，“日志文件”保存了历史所有的操作过程；当server需要数据恢复时，可以直接replay此日志文件，即可还原所有的操作过程。AOF相对可靠，它和mysql中bin.log、apache.log、zookeeper中txn-log简直异曲同工。AOF文件内容是字符串，非常容易阅读和解析。
优点：
可以保持更高的数据完整性，如果设置追加file的时间是1s，如果redis发生故障，最多会丢失1s的数据；且如果日志写入不完整支持redis-check-aof来进行日志修复；AOF文件没被rewrite之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的flushall）。
缺点：
AOF文件比RDB文件大，且恢复速度慢。
Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。
Redis 客户端可以订阅任意数量的频道。
下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：
当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：
下表列出了 redis 发布订阅常用命令：
|
序 号 |
命令及描述 |
|
1 |
PSUBSCRIBE pattern [pattern ...] |
|
2 |
PUBSUB subcommand [argument [argument ...]] |
|
3 |
PUBLISH channel message |
|
4 |
PUNSUBSCRIBE [pattern [pattern ...]] |
|
5 |
SUBSCRIBE channel [channel ...] |
|
6 |
UNSUBSCRIBE [channel [channel ...]] |
标签：name inf 事物 car 操作记录 客户端 info href red
原文地址：https://www.cnblogs.com/Zzzzn/p/12133118.html
