事务处理
Redis对事务的支持目前还比较简单。Redis只能保证一个client发起的事务中的命令可以连续的执行，而中间不会插入其他client的命令。当一个client在一个连接中发出multi命令时，这个连接会进入一个事务上下文，该连接后续的命令不会立即执行，而是先放到一个队列中，当执行exec命令时，redis会顺序的执行队列中的所有命令。
| 127.0.0.1:6379> get age (nil) 127.0.0.1:6379> multi OK //表示事务开始 127.0.0.1:6379> set age 10 QUEUED //表示放入队列 127.0.0.1:6379> set age 20 QUEUED //表示这两个都放入队列中了 127.0.0.1:6379> exec //分别分别返回两条命令的结果 1) OK 2) OK 127.0.0.1:6379> get age "20" 127.0.0.1:6379> |
A:取消一个事务，使用discard
| 127.0.0.1:6379> get age "20" 127.0.0.1:6379> multi OK 127.0.0.1:6379> set age 30 QUEUED 127.0.0.1:6379> set age 40 QUEUED 127.0.0.1:6379> discard OK 127.0.0.1:6379> get age "20" 127.0.0.1:6379> |
可以发现这次2个set age命令都没被执行。Discard命令其实就是清空事务的命令队列并退出事务上下文，也就是我们常说的事务回滚。
B．乐观锁：大多数是基于数据版本（version）的记录机制实现的。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过数据库表添加一个“version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加1。此时，将提交数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版本号大于数据库当前版本号，则予以更新，否则认为是过期数据。
Redis乐观锁实例：假设一个age的key，我们开2个session来对age进行赋值操作，我们来看一下结果如何。
watch命令会监视给定的key，当exec时候如果监视的key从调用watch后发生过变化，则整个事务会失败。也可以调用watch多次监视多个key。这样就可以对指定的key加乐观锁了，注意watch的key是对整个连接有效的，事务也一样。如果连接断开，监视和事务都会被自动清除。当然了exec，discard,unwatch命令都会清除连接中的所有监视。
| 127.0.0.1:6379> get age "20" 127.0.0.1:6379> get name (nil) 127.0.0.1:6379> set name toto OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> incr age QUEUED 127.0.0.1:6379> incr name QUEUED 127.0.0.1:6379> exec 1) (integer) 21 //可以看到事务并没有回滚，执行了一条，后面一条失败 2) (error) ERR value is not an integer or out of range 127.0.0.1:6379> get age "21" 127.0.0.1:6379> get name "toto" 127.0.0.1:6379> |
从这个例子中可以看到，age由于是个数字，那么它可以有自增运算，但是name是个字符串，无法对其进行自增运算，所以会报错，如果按传统关系型数据库的思路来讲，整个事务都会回滚，但是我们看到redis却是将可以执行的命令提交了，所以这个现象对于习惯关系型数据库操作的朋友来说是很别扭的，这一点也是redis今天需要改进的地方。
持久化机制
Redis是一个支持持久化的内存数据库，也就是说redis需要经常讲内存中的数据同步到硬盘来保证持久化。Redis支持两种持久化方式：
snapshotting(快照)也是默认方式。（也就是说把数据做一个备份）
append-only file(缩写aof)的方式。（将写和更改删除等操作放到文件中）。
快照是默认的持久化方式。这种方式是将内存中数据以快照的方式写入到二进制文件中。默认的文件名为dump.rdb。可以通过配置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照。
| save 900 1 #900秒内如果超过1个key被修改，则发起快照保存 save 300 10 #300秒内容如超过10个key被修改，则发起快照保存 save 60 10000 |
rdb所在位置：
默认开启的配置是：
aof方式：
由于快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。
aof比快照方式更好的持久性，是由于在使用aof时，redis会将每一个收到的写命令都通过write函数追加到文件中，当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
当然由于os会在内核中缓存write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能丢失部分修改。
可以通过配置文件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机。
| appendonly yes //启动aof持久化方式 # appendfsync always //收到写命令就立即写入磁盘，最慢，但是保证完全的持久化。（表示每次写都会往文件中写一次） appendfsync everysec //每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中。（表示每秒都会执行一次） #appendfsync no //完全依赖os，性能最好，持久化没保证 |
要修改的配置文件是：vim /usr/local/redis/etc/redis.conf
appendonly的默认参数是no，我们可以给它改成yes
修改同步方式：
重新启动服务器：/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf
测试运行
| [toto@localhost ~]$ /usr/local/redis/bin/redis-cli 127.0.0.1:6379> set name toto1 (error) NOAUTH Authentication required. 127.0.0.1:6379> auth toto OK 127.0.0.1:6379> set name toto1 OK 127.0.0.1:6379> exit [toto@localhost ~]$ ll 总用量 60 drwxrwxr-x. 2 toto toto 4096 10月 16 19:09 1016 -rw-r--r--. 1 toto toto 57 2月 15 15:59 appendonly.aof -rw-rw-r--. 1 toto toto 38 2月 15 15:56 dump.rdb drwxr-xr-x. 3 root root 4096 10月 13 16:34 mysql drwxrwxr-x. 3 toto toto 4096 2月 6 17:24 redis drwxrwxr-x. 2 toto toto 4096 1月 31 19:58 server drwxrwxr-x. 3 toto toto 4096 10月 16 19:02 shell drwxr-xr-x. 2 toto toto 4096 10月 16 08:58 公共的 drwxr-xr-x. 2 toto toto 4096 10月 16 08:58 模板 drwxr-xr-x. 2 toto toto 4096 10月 16 08:58 视频 drwxr-xr-x. 2 toto toto 4096 10月 16 08:58 图片 drwxr-xr-x. 2 toto toto 4096 10月 16 08:58 文档 drwxr-xr-x. 2 toto toto 4096 10月 16 08:58 下载 drwxr-xr-x. 2 toto toto 4096 10月 16 08:58 音乐 drwxr-xr-x. 2 toto toto 4096 10月 16 10:07 桌面 |
| [toto@localhost ~]$ ls 1016 appendonly.aof dump.rdb mysql redis server shell 公共的 模板 视频 图片 文档 下载 音乐 桌面 [toto@localhost ~]$ cat appendonly.aof *2 $6 SELECT $1 0 *3 $3 set $4 name $5 toto1 *3 $3 set $4 name $5 toto2 [toto@localhost ~]$ |
由上可以知道aof文件中存的是写命令。
发布及订阅消息
发布订阅（pub/sub）是一种消息通信模式，主要的目的是解除消息发布者和消息订阅者之间的耦合，Redis作为一个pub/sub的server,在订阅者和发布者之间起到了消息路由的功能。订阅者可以通过subscribe和psubscribe命令向redis server订阅自己感兴趣的消息类型，redis将信息类型称为通道（channel）.当发布者通过publish命令向redis server发送特定类型的信息时，订阅信息类型的全部client都会收到此消息。
实验步骤：
打开三个客户端：
分别使用：/usr/local/redis/bin/redis-cli -a toto登录客户端
在第一个客户端输入：subscribe tv1 通过这种方式监听tv1频道
在第二个客户端输入：subscribe tv1 tv2 通过这种方式监听tv1,tv2频道
在第三个客户端通过public命令发布消息，输入：以下命令：
这样，在第一个客户端和第二个客户端中会监听到第三个客户端发布的消息，最后的输出如下：
客户端一的消息如下：
客户端二的消息如下：
应用：做消息系统和聊天系统
虚拟内存的使用：
Redis的虚拟内存与操作系统的虚拟内存内存不是一回事儿，但是思路和目的都是相同的。就是暂时把不经常访问的数据从内存交换到磁盘中，从而腾出宝贵的内存空间用于其他需要访问的数据。尤其是对于redis这样的内存数据库，内存总是不够用的。除了可以将数据分割到多个redis server外。另外能够提高数据库容量的办法就是使用虚拟内存把那些不经常访问的数据交换到磁盘上。
下面是虚拟内存的配置情况：
vm-enabled yes #开启vm功能
vm-swap-file /tmp/redis.swap #交换出来的value保存的文件路径
vm-max-memory 1000000 #redis使用的最大内存上限
vm-page-size 32 #每个页面的大小32字节
vm-pages 134217728 #最多使用多少页面
vm-max-threads 4 #用于执行value对象换入的工作线程数量
注意：自己在2.配置的时候上面的参数不可以配置。
