目录
一、Redis事务
二、Redis存放二进制对象
三、Redis持久化
两者优缺点
传统数据库的特性
Redis的事务经过MULTI指令开启事务,然后一系列的指令(EXEC、DISCARD、MULTI 和 WATCH这几个命令除外)进入队列,然后经过EXEC提交事务。Redis事务是一次性、顺序性、排他性的执行一个队列中的一系列命令。
语法错误时,事务并不会提交(这样看事务是原子性)
127.0.0.1:6379> multi #开启事务
OK
127.0.0.1:6379(TX)> set a a
QUEUED
127.0.0.1:6379(TX)> set b b
QUEUED
127.0.0.1:6379(TX)> zset c c #语法错误
(error) ERR unknown command `zset`, with args beginning with: `c`, `c`,
127.0.0.1:6379(TX)> exec #提交事务,所有的指令并不会执行,即使正确的指令也不会执行
(error) EXECABORT Transaction discarded becaus e of previous errors.
127.0.0.1:6379> get a #值没有改变
"1"
运行错误,这种错误在实际执行之前Redis是无法发现的,如果事务里的一条命令出现了运行错误,事务里其他的命令依然会继续执行。(这么看是不支持原子性的)。我偏向这么理解单个Redis 命令的执行是原子性的,但 Redis 没有在事务上增加任何维持原子性的机制,所以 Redis 事务的执行并不是原子性的。事务可以理解为一个打包的批量执行脚本,但批量指令并非原子化的操作,中间某条指令的失败不会导致前面已做指令的回滚(不支持事务回滚),也不会影响后面指令的正常执行。
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set a 1
QUEUED
127.0.0.1:6379(TX)> sadd b 2
QUEUED
127.0.0.1:6379(TX)> set c 3
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> get c
"3"
DISCARD取消事务,也就是清空事务队列里的指令。
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set a a
QUEUED
127.0.0.1:6379(TX)> set b b
QUEUED
127.0.0.1:6379(TX)> discard #取消事务,清空事务队列
OK
127.0.0.1:6379> set a a
OK
WATCH 命令用于在事务开始之前监视任意数量的键: 当调用EXEC命令执行事务时, 如果任意一个被监视的键已经被其他客户端修改了, 那么整个事务不再执行, 直接返回失败
127.0.0.1:6379> watch a #初始值是100
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set a 200
QUEUED
#在这个时候,我用redis客户端,或者重新连接一个客户端,将a值修改之后
127.0.0.1:6379(TX)> get a
QUEUED
127.0.0.1:6379(TX)> exec #事务执行失败
(nil)
127.0.0.1:6379>
StringRedisTemplate 这个类是存放String类型的。 RedisTemplate 这个类存放的是二进制类型。
实体对象实现序列化,启动类加上@EnableCaching
@Cacheable(cacheNames = "users", key = "'getListUsers'")
@RequestMapping("/getListUsers")
public List getListUsers() {
List all = userMapper.findAll();
return all;
}
RDB方式 默认开启 文件名称是 dump.rdb
Redis6.0版本
AOF开启方式 修改配置文件 appendonly yes 文件名称appendonly.aof
RDB存在哪些优势呢?
RDB又存在哪些劣势呢?
AOF的优势有哪些呢?
AOF的劣势有哪些呢?
总结:RDB快照是紧凑压缩的二进制文件相对于aof文件要小,存储效率高。内部存储的时redis在某个时间点的数据快照,非常适合数据备份,全量复制等场景。数据恢复的速度比AOF快得多。缺点是存在丢失数据的风险,bgsave指令每次运行要执行fork操作创建子进程,要牺牲一些性能。AOF数据存储相对安全,即使丢失数据也只是丢失1秒的数据,数据量大时,会使用rewrite机制,恢复数据,恢复数据期间会生成一个新的文件来生成新的操作记录,数据恢复完之后,也会将新生成的操作记录恢复到内存中去。缺点是文件相对较大,恢复效率较低。
参考 :https://www.cnblogs.com/chenliangcl/p/7240350.html