OK
#由于mykey已经被重新命名，再次获取将返回nil。
redis 127.0.0.1:6379> get mykey
(nil)
#通过新的键名获取。
redis 127.0.0.1:6379> get mykey1
"hello"
#由于mykey已经不存在了，所以返回错误信息。
redis 127.0.0.1:6379> rename mykey mykey1
(error) ERR no such key
#为renamenx准备测试key
redis 127.0.0.1:6379> set oldkey "hello"
OK
redis 127.0.0.1:6379> set newkey "world"
OK
#由于newkey已经存在，因此该命令未能成功执行。
redis 127.0.0.1:6379> renamenx oldkey newkey
(integer) 0
#查看newkey的值，发现它也没有被renamenx覆盖。
redis 127.0.0.1:6379> get newkey
"world"
2. PERSIST/EXPIRE/EXPIREAT/TTL:
#为后面的示例准备的测试数据。
redis 127.0.0.1:6379> set mykey "hello"
OK
#将该键的超时设置为100秒。
redis 127.0.0.1:6379> expire mykey 100
(integer) 1
#通过ttl命令查看一下还剩下多少秒。
redis 127.0.0.1:6379> ttl mykey
(integer) 97
#立刻执行persist命令，该存在超时的键变成持久化的键，即将该Key的超时去掉。
redis 127.0.0.1:6379> persist mykey
(integer) 1
#ttl的返回值告诉我们，该键已经没有超时了。
redis 127.0.0.1:6379> ttl mykey
(integer) -1
#为后面的expire命令准备数据。
redis 127.0.0.1:6379> del mykey
(integer) 1
redis 127.0.0.1:6379> set mykey "hello"
OK
#设置该键的超时被100秒。
redis 127.0.0.1:6379> expire mykey 100
(integer) 1
#用ttl命令看一下当前还剩下多少秒，从结果中可以看出还剩下96秒。
redis 127.0.0.1:6379> ttl mykey
(integer) 96
#重新更新该键的超时时间为20秒，从返回值可以看出该命令执行成功。
redis 127.0.0.1:6379> expire mykey 20
(integer) 1
#再用ttl确认一下，从结果中可以看出果然被更新了。
redis 127.0.0.1:6379> ttl mykey
(integer) 17
#立刻更新该键的值，以使其超时无效。
redis 127.0.0.1:6379> set mykey "world"
OK
#从ttl的结果可以看出，在上一条修改该键的命令执行后，该键的超时也无效了。
redis 127.0.0.1:6379> ttl mykey
(integer) -1
3. TYPE/RANDOMKEY/SORT:
#由于mm键在数据库中不存在，因此该命令返回none。
redis 127.0.0.1:6379> type mm
none
#mykey的值是字符串类型，因此返回string。
redis 127.0.0.1:6379> type mykey
string
#准备一个值是set类型的键。
redis 127.0.0.1:6379> sadd mysetkey 1 2
(integer) 2
#mysetkey的键是set，因此返回字符串set。
set
#返回数据库中的任意键。
redis 127.0.0.1:6379> randomkey
"oldkey"
#清空当前打开的数据库。
redis 127.0.0.1:6379> flushdb
OK
#由于没有数据了，因此返回nil。
redis 127.0.0.1:6379> randomkey
(nil)
七、事务处理命令与WATCH命令和基于CAS的乐观锁示例：
1. 事务被正常执行：
#在Shell命令行下执行Redis的客户端工具。
/> redis-cli
#在当前连接上启动一个新的事务。
redis 127.0.0.1:6379> multi
OK
#执行事务中的第一条命令，从该命令的返回结果可以看出，该命令并没有立即执行，而是存于事务的命令队列。
redis 127.0.0.1:6379> incr t1
QUEUED
#又执行一个新的命令，从结果可以看出，该命令也被存于事务的命令队列。
redis 127.0.0.1:6379> incr t2
QUEUED
#执行事务命令队列中的所有命令，从结果可以看出，队列中命令的结果得到返回。
redis 127.0.0.1:6379> exec
1) (integer) 1
2) (integer) 1
2. 事务中存在失败的命令：
#开启一个新的事务。
redis 127.0.0.1:6379> multi
OK
#设置键a的值为string类型的3。
redis 127.0.0.1:6379> set a 3
QUEUED
#从键a所关联的值的头部弹出元素，由于该值是字符串类型，而lpop命令仅能用于List类型，因此在执行exec命令时，该命令将会失败。
redis 127.0.0.1:6379> lpop a
QUEUED
#再次设置键a的值为字符串4。
redis 127.0.0.1:6379> set a 4
QUEUED
#获取键a的值，以便确认该值是否被事务中的第二个set命令设置成功。
redis 127.0.0.1:6379> get a
QUEUED
#从结果中可以看出，事务中的第二条命令lpop执行失败，而其后的set和get命令均执行成功，这一点是Redis的事务与关系型数据库中的事务之间最为重要的差别。
redis 127.0.0.1:6379> exec
1) OK
2) (error) ERR Operation against a key holding the wrong kind of value
3) OK
4) "4"
3. 回滚事务：
#为键t2设置一个事务执行前的值。
redis 127.0.0.1:6379> set t2 tt
OK
#开启一个事务。
redis 127.0.0.1:6379> multi
OK
#在事务内为该键设置一个新值。
redis 127.0.0.1:6379> set t2 ttnew
QUEUED
#放弃事务。
redis 127.0.0.1:6379> discard
OK
#查看键t2的值，从结果中可以看出该键的值仍为事务开始之前的值。
redis 127.0.0.1:6379> get t2
"tt"
在Redis的事务中，WATCH命令可用于提供CAS(check-and-set)功能。假设我们通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Null multi-bulk应答以通知调用者事务执行失败。例如，我们再次假设Redis中并未提供incr命令来完成键值的原子性递增，如果要实现该功能，我们只能自行编写相应的代码。其伪码如下：
val = GET mykey
val = val + 1
SET mykey $val
以上代码只有在单连接的情