诸葛数据库-司马懿诸葛亮

admin

作者

引言

Redis是一个开源的、使用C语言编写的、支持网络交互的、可基于内存也可持久化的Key-Value数据库。Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。

学会安装redis

从redis.io下载最新版redis-X.Y.Z.tar.gz后解压，然后进入redis-X.Y.Z文件夹后直接make即可，安装非常简单。

make成功后会在src文件夹下产生一些二进制可执行文件，包括redis-server、redis-cli等等诸葛数据库：

$ find . -type f -executable

./redis-benchmark //用于进行redis性能测试的工具

./redis-check-dump //用于修复出问题的dump.rdb文件

./redis-cli //redis的客户端

./redis-server //redis的服务端

./redis-check-aof //用于修复出问题的AOF文件

./redis-sentinel //用于集群管理

学会启动redis

启动redis非常简单，直接./redis-server就可以启动服务端了，还可以用下面的 *** 指定要加载的配置文件诸葛数据库：

./redis-server ../redis.conf

默认情况下，redis-server会以非daemon的方式来运行，且默认服务端口为6379。

有关作者为什么选择6379作为默认端口，还有一段有趣的典故，英语好的同学可以看看作者这篇博文中的解释。

使用redis客户端

我们直接看一个例子：

//这样来启动redis客户端了

$ ./redis-cli

//用set指令来设置key、value

127.0.0.1:6379> set name "roc"

//来获取name的值

127.0.0.1:6379> get name

"roc"

//通过客户端来关闭redis服务端

127.0.0.1:6379> shutdown

127.0.0.1:6379>

redis的事务处理

众所周知，事务是指“一个完整的动作，要么全部执行，要么什么也没有做”。

在聊redis事务处理之前，要先和大家介绍四个redis指令，即MULTI、EXEC、DISCARD、WATCH。这四个指令构成了redis事务处理的基础。

MULTI用来组装一个事务诸葛数据库；

EXEC用来执行一个事务；

DISCARD用来取消一个事务；

WATCH用来监视一些key，一旦这些key在事务执行之前被改变，则取消事务的执行。

纸上得来终觉浅，我们来看一个MULTI和EXEC的例子：

redis> MULTI //标记事务开始

redis> INCR user_id //多条命令按顺序入队

QUEUED

redis> INCR user_id

QUEUED

redis> INCR user_id

QUEUED

redis> PING

QUEUED

redis> EXEC //执行

1) (integer) 1

2) (integer) 2

3) (integer) 3

4) PONG

在上面的例子中，我们看到了QUEUED的字样，这表示我们在用MULTI组装事务时，每一个命令都会进入到内存队列中缓存起来，如果出现QUEUED则表示我们这个命令成功插入了缓存队列，在将来执行EXEC时，这些被QUEUED的命令都会被组装成一个事务来执行。

对于事务的执行来说，如果redis开启了AOF持久化的话，那么一旦事务被成功执行，事务中的命令就会通过write命令一次性写到磁盘中去，如果在向磁盘中写的过程中恰好出现断电、硬件故障等问题，那么就可能出现只有部分命令进行了AOF持久化，这时AOF文件就会出现不完整的情况，这时，我们可以使用redis-check-aof工具来修复这一问题，这个工具会将AOF文件中不完整的信息移除，确保AOF文件完整可用。

有关事务，大家经常会遇到的是两类错误：

调用EXEC之前的错误

调用EXEC之后的错误

“调用EXEC之前的错误”，有可能是由于语法有误导致的，也可能时由于内存不足导致的。只要出现某个命令无法成功写入缓冲队列的情况，redis都会进行记录，在客户端调用EXEC时，redis会拒绝执行这一事务。（这时2.6.5版本之后的策略。在2.6.5之前的版本中，redis会忽略那些入队失败的命令，只执行那些入队成功的命令）。我们来看一个这样的例子：

127.0.0.1:6379> multi

127.0.0.1:6379> haha //一个明显错误的指令

(error) ERR unknown command 'haha'

127.0.0.1:6379> ping

QUEUED

127.0.0.1:6379> exec

//redis无情的拒绝了事务的执行，原因是“之前出现了错误”

(error) EXECABORT Transaction discarded because of previous errors.

而对于“调用EXEC之后的错误”，redis则采取了完全不同的策略，即redis不会理睬这些错误，而是继续向下执行事务中的其他命令。这是因为，对于应用层面的错误，并不是redis自身需要考虑和处理的问题，所以一个事务中如果某一条命令执行失败，并不会影响接下来的其他命令的执行。我们也来看一个例子：

127.0.0.1:6379> multi

127.0.0.1:6379> set age 23

QUEUED