Redis系统相关命令和Redis事务

曾经终败给现在 2023-06-08 06:19 12阅读 0赞

### 一、系统相关命令 ###

（1）BGREWRITEAOF：手动触发AOF重写操作，用于减小AOF文件体积

** 格式：BGREWRITEAOF**

![20191016211449999.png][]

（2）BGSAVE：后台异步保存当前数据库的数据到磁盘

**格式：BGSAVE**

![20191016211543468.png][]

（3）CLIENT KILL：关闭地址为ip:port的客户端；由于Redis为单线程设计，因此当当前命令执行完之后才会关闭客户端

** 格式：CLIENT KILL ip:port**

![20191016212352796.png][]

（4）CLIENT LIST：以可读的格式，返回所有连接到服务器的客户端信息和统计数据

**格式：CLIENT LIST**

![20191016211313498.png][]

（5）CONFIG GET：取得运行中的Redis服务器配置参数；支持\*

**格式：CONFIG GET parameter**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70][]

（6）CONFIG RESETSTAT：重置INFO命令中的某些统计数据，例如Keyspace hits、Keyspace misses等

**格式：CONFIG RESETSTAT**

![20191016212711613.png][]

（7）CONFIG REWRITE：对启动Redis时指定的redis.conf文件进行改写

**格式：CONFIG REWRITE**

![20191016212832332.png][]

（8）CONFIG SET：动态调整Redis服务器的配置而无需重启；修改后的配置立即生效。

**格式：CONFIG SET parameter value**

（9）SELECT：切换到指定数据库，数据库索引index用数字指定，以0作为起始索引值；默认使用0号数据库

**格式：SELECT index**

![20191016213035879.png][]

（10）DBSIZE：返回当前数据库的Key的数量

**格式：DBSIZE**

![20191016213129433.png][]

（11）DEBUG OBJECT：这是一个调试命令，不应当被客户端使用；key存在时返回有关信息，key不存在时返回错误

**格式：DEBUG OBJECT key**

（12）FLUSHALL：清空整个Redis服务器的数据

**格式：FLUSHALL**

![20191016213313669.png][]

（13）FLUSHDB：清空当前数据库中的所有数据

**格式：FLUSHDB**

![20191016213401907.png][]

（14）INFO：以一种易于解释且易于阅读的格式，返回Redis服务器的各种信息和统计数值；通过给定可选参数section，可以让命令只返回某一部分信息

**格式：INFO \[section\]**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 1][]

（15）LASTSAVE：返回最近一次Redis成功将数据保存到磁盘上的时间，以UNIX时间戳格式表示

**格式：LASTSAVE**

![20191016213638772.png][]

（16）MONITOR：实时打印出Redis服务器接收到的命令，调试用

**格式：MONITOR**

（17）SHUTDOWN：停止所有客户端；如果至少有一个保存点在等待，执行SAVE命令；如果AOF选项被打开，更新AOF文件；关闭Redis服务器。

** 格式：SHUTDOWN \[SAVE|NOSAVE\]**

![20191016214016712.png][]

### 二、Redis的事务 ###

Redis的事务是由DISCARD、EXEC、MULTI、UNWATCH、WATCH五个命令来保证的：

（1）DISCARD：取消事务；如果正在使用WATCH命令监视某个/某些key，那么取消所有监视，等同于执行UNWATCH。

**格式：DISCARD**

（2）EXEC：执行所有事务块内的命令；如果某个/某些key正处于WATCH命令监视之下且事务块中有和这个/这些key相关的命令，那么EXEC命令只在这个/这些key没有被其他命令改动的情况下才会执行并生效，否则该事务被打断。

**格式：EXEC**

（3）MULTI：标记一个事务块的开始；事务块内的多条命令会按照先后顺序被放入一个队列中，最后由EXEC命令原子性地执行

**格式：MULTI**

（4）UNWATCH：取消WATCH命令对所有key的监视；如果WATCH之后，EXEC/DISCARD命令先被执行了，UNWATCH命令就没必要执行了

**格式：UNWATCH**

（5）WATCH：监视一个/多个key，如果在事务执行之前这个/这些key被其他命令改动，那么事务将被打断

**格式：WATCH key \[key ...\]**

**例子：**事务没有被打断的情况

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 2][]

看到开启事务之后，所有的命令返回的都是QUEUED，即放入队列，而不是直接执行。

接着模拟一下事务被打断的情况，WATCH一下Number这个Key，我另外起了一个Redis客户端INCR了一下num，结果为：

![20191016215609104.png][]

看到，并没有命令被执行，返回nil即事务被打断。

接着简单说一下事务，和数据库类似的，事务保证的是两点：

*  隔离：所有命令序列化、按顺序执行，事务执行过程中不会被其他客户端发来的命令打断
 *  原子性：事务中的命令要么全部执行，要么全部不执行

另外，Redis的事务并不支持回滚，这个其实网上已经说法挺多了，大致上是两个原因：

*  Redis命令只会因为语法而失败（且这些问题不能再入队时被发现），或是命令用在了错误类型的键上面，也就是说，从实用性角度来说，失败的命令是由于编程错误造成的，而这些错误应该在开发的过程中被发现而不应该出现在生产环境中
 *  Redis内部可以保持简单且快速，因为不需要对回滚进行支持

总而言之，对Redis来说，回滚无法解决编程错误带来的问题，因此还不如更简单、更快速地无回滚处理事务。

**如果本文对您有很大的帮助，还请点赞关注一下。**

[20191016211449999.png]: /images/20230531/6187ea9512614369a78d6ce2ade5ecbe.png
[20191016211543468.png]: /images/20230531/07b4c3a11422430992029ef5190e62ae.png
[20191016212352796.png]: /images/20230531/f714d2893998484d8ebf373b57ef5744.png
[20191016211313498.png]: /images/20230531/63f9036f5713471caa0dcd18a709ada6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70]: /images/20230531/9c1169fea3bc4082aeb4b3726002d0be.png
[20191016212711613.png]: /images/20230531/cc982fdb70494d57a9c3ed2d5726b937.png
[20191016212832332.png]: /images/20230531/f76da88b22904b47806e1a8e8cc1ee64.png
[20191016213035879.png]: /images/20230531/56fb1f642eab4ccdafee0e89b4c11764.png
[20191016213129433.png]: /images/20230531/0d21ce15cadc40ac880012a189444ba0.png
[20191016213313669.png]: /images/20230531/f624f5ddd278407789a7f66fc7333feb.png
[20191016213401907.png]: /images/20230531/2fe2ae9a591c4eaca8127bf018f8d826.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 1]: /images/20230531/fb4e53a0280f49d88a0811a1789313f4.png
[20191016213638772.png]: /images/20230531/53e66fee44e34b10a8cbb8af85cbaaff.png
[20191016214016712.png]: /images/20230531/dc12708d38884342b995b0cc58c3df7c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 2]: /images/20230531/5b512b51a0dd47dfb455b8bc2f1dfced.png
[20191016215609104.png]: /images/20230531/cacd947085314ebda4484565f714ffd9.png