正文
一、Redis事务
传统数据库的特性
Atomicity（原子性）：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
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>
二、Redis存放二进制对象
StringRedisTemplate 这个类是存放String类型的。
RedisTemplate 这个类存放的是二进制类型。
实体对象实现序列化，启动类加上@EnableCaching
@Cacheable(cacheNames = "users", key = "'getListUsers'") @RequestMapping("/getListUsers") public List<User> getListUsers() { List<User> all = userMapper.findAll(); return all; }
三、Redis持久化
RDB方式 默认开启 文件名称是 dump.rdb
Redis6.0版本
save 3600 1 在3600秒(一个小时)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 100 在300秒(5分钟)之后，如果至少有100个key发生变化，则dump内存快照。
save 60 10000 在60秒之后，如果至少有10000个key发生变化，则dump内存快照。
AOF开启方式 修改配置文件 appendonly yes 文件名称appendonly.aof
# appendfsync always 每次有数据修改发生时都会写入AOF文件，能够保证数据不丢失，但是效率非常低。
appendfsync everysec （官方推荐）每秒钟同步一次，可能会丢失1s内的数据，但是效率非常高
# appendfsync no 效率高但是不会持久化数据
两者优缺点
RDB存在哪些优势呢？
一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
相比于AOF机制，如果数据集很大，RDB的启动效率会更高。
RDB又存在哪些劣势呢？
如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
AOF的优势有哪些呢？
该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。
AOF的劣势有哪些呢？
对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
总结：RDB快照是紧凑压缩的二进制文件相对于aof文件要小，存储效率高。内部存储的时redis在某个时间点的数据快照，非常适合数据备份，全量复制等场景。数据恢复的速度比AOF快得多。缺点是存在丢失数据的风险，bgsave指令每次运行要执行fork操作创建子进程，要牺牲一些性能。AOF数据存储相对安全，即使丢失数据也只是丢失1秒的数据，数据量大时，会使用rewrite机制，恢复数据，恢复数据期间会生成一个新的文件来生成新的操作记录，数据恢复完之后，也会将新生成的操作记录恢复到内存中去。缺点是文件相对较大，恢复效率较低。
