事物处理:
redis只能保证一个client发起的事物中的命令可以连续的执行,而中间不会插入其他client命令。
当一个client在一个连接中发出multi命令时,这个连接会进入事物上下文,该连接后续的命令不会立即执行,
而是先放到一个队列中,当执行exec命令时,redis会顺序的执行队列中的所有命令。
multi
set age 10 #返回QUEUED
set age 20
exec
get age
discard 取消事务 (清空事物队列) 回滚事务
redis中某个队列执行失败,事务不会回滚
multi
incr age
incr name
exec
乐观锁复杂事物控制
大多是基于数据版本(version)的记录机制实现的,即为数据增加一个标识版本,在基于数据库表的版本解决方案中,一般是为数据库添加一个“version” 字段来实现读取数据时,将此版本号一同读书,之后更新时,对此版本加1.此时将提交数据的版本号与数据库表对应记录的当前版本号进行对比,如果提交的数据版本号大于数据库当前版本号,则予以更新,否则认为是过期数据。(类似SVN工作机制)
watch命令会监视给定的key,当exec执行的时候如果监视的key从调用watch后发生过变化,则整个事务会失败。
也可以调用watch多次监视多个key,这样就可以对指定的key加乐观锁了。注意watch的key是对整个连接有效的,
事物也一样。如果连接断开,监视和事务都会自动清除,exex、discard、unwatch命令都会去清除连接中的监视。
乐观锁
watch age 监控
unwatcgh age 取消监视
然后我们重新打开一个终端
再回到第一个终端
此时事物执行会失败
持久化机制:
1:snapshotting 快照 也是默认方式。(做数据备份)
快照是默认的持久化方式。
这种方式将内存中的数据以快照的方式写入二进制文件中,默认的文件名为dump.rdb。
可以通过设置自动做快照的持久化方式。
save 900 1 #在900秒内如果一个key被修改,则发起快照保存
2:append-only file (缩写aof)的方式 (将写、更改、删除操作写入文件)。
由于快照方式是一定间隔时间做一次的,所以所有redis意外挂掉的话,就会丢失最后一次快照的修改
aof比快照方式与更好的持久化性,由于在使用aof时,redis会将每一个收到的写命令通过write函数追加到文件、当redis重启时会通过重新执行文件中保存的写命令重建整个数据库内容
aof配置:
修改redis.conf文件
appendonly no -> appendonly yes
# appendfsync always //收到写命令立刻写入磁盘,最慢,但是保证完全的持久化
appendfsync everysec //每秒写入磁盘一次,在性能和持久化方便做了很好的折中
# appendfsync no //完全依赖OS,性能最好,但是持久化没有保证
发布订阅(pub/sub)
pub/sub是一种消息通信模式, 主要的目的是解除消息发布和消息订阅者之间的耦合。
起到了消息路由的功能。 订阅者可以通过 subscibe和psubscribe命令向redis server订阅。
redis 将信息类型称为通道。当发布者通过publish命令向redis server发送哦你不过特定类型的信息时,
订阅该信息类型的全部client都会收到此信息。
终端1:subscribe tv1
终端2:subscribe tv1 tv2
终端3:publish tv1 loveyun
我们再看看终端1和终端2:
这里说的pub/sub是很简单的应用,详细的请看这里
虚拟内存的使用
配置文件 redis.conf
vm-enabled yes #开启vm功能
vm-swap-file /tmp/redis.swap #交换出来的value保存的文件路径/tmp/redis.swap
vm-max-memory 1000000 #redis使用的最大内存上限,超过上限后redis开始交换value到磁盘文件中。
vm-page-size 32 #每个页面的大小32个字节
vm-pages 134217728 #最多使用在文件中使用多少页面,交换文件的大小 = vm-page-size * vm-pages
vm-max-threads 4 #用于执行value对象换入换出的工作线程数量。0表示不使用工作线程