1.1 使用事务Redis事务是一个单独的隔离操作，事务中的所有命令都会序列化、按顺序的执行；事务在执行的过程中，不会被其它的客户端发来的命令请求所打断。
Redis的事务主要左右就是串联多个命令防止别的命令插队。
- multi：组队阶段：使用该命令之后，输入的其它命令都会依次进入命令队列中，单不会执行；
- exec：输入该命令，Redis会将之前的命令队列中的命令依次执行；
- discard：放弃组队，即不执行从multi开始组队的命令。
-
组队时某个命令失败了，执行时整个的所有队列都会被取消；
-
执行阶段某个命令出现了错误，只有报错的命令不执行，其它的命令依然执行，不会回滚。
这里引入一个并发场景下的例子，没有添加事务，在多任务同时操作进行购买下，金额变为**-4000**。
-
悲观锁：即每次操作都只允许一个线程进行操作，只有当当前线程释放锁之后，其它线程才可以操作。
-
乐观锁：拿数据时都默认认为不会被修改，在更新时判断一下期间别人有没有更新数据，可以引入一个版本号进制用来判断是否更新。适用于多读的场景，可以提高吞吐量。
-
乐观锁展示：使用watch key来监视一个或多个key，如果在事务执行之前key被其它命令改动，这个事务将被打断。
客户端A，监听balance，对客户端B也开启监听balance，然后对开启事务使用A进行增加操作，增加成功，再对B进行增加操作，由于当前key的值已经修改，其版本号也对应修改因此操作失败。
-
使用unwatch取消对key的监听。
- 单独的隔离操作：事务中的所有命令都会序列化、按顺序的执行。事务在执行过程中，不会被其它客户短端发送来的命令请求打断。
- 没有隔离级别的概念：队列中的命令没有提交之前都不会被执行，因为事务提交前任何指令都不会被实际执行。
- 不保证原子性：事务中如果有一条命令执行失败，其后的命令让然会执行，不会回滚。
在指定的时间间隔内将内存中的数据集快照写入磁盘，恢复时是将快照文件直接读到内存里。
- 执行过程： Redis会创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化进程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程不进行IO操作，这就确保了极高的性能，如果需要大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那么RDB优于AOF。其缺点可能是最后一次持久化的数据可能丢失。
默认临时文件为dump.rdb位于启动目录下。
- 优势：
- 适合大规模的数据恢复；
- 对数据完整性和一致性要求不高适用；
- 节省磁盘空间；
- 恢复速度快。
- 劣势：
- Fork时，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑；
- 虽然Redis再fork时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能；
- 在备份周期一定时间间隔内备份时（还没达到持久化条件），如果Redis意外宕机，就会丢失最后一次快照后的所有修改。
以日志的形式来记录每个些操作，将Redis执行过的所有写指令记录下来，最佳到文件后，Redis启动时会读取该文件重新构建数据。
-
开启方式：在配置文件中修改
appendonly yes
如果AOF和RDB同时开启会根据AOF中的数据来恢复。
-
数据文件：默认是位于redis目录下的appendonly.aof文件。
-
持久化流程：
- 客户端的写命令请求会被追加到AOF的缓冲区内；
- AOF缓冲区根据AOF持久化策略(always，everysec，no)，将操作以异步的方式同步到磁盘的AOF文件中；
- AOF文件大小超过重写策略或手动重写时，会对AOF文件重写，压缩文件容量；
- Redis服务重启时，会重写加载AOF文件中的写操作来恢复数据。
-
优势：
- 备份机制稳定，丢失数据概率低；
- 可读的日志文本，通过AOF操作稳健，可以处理误操作。
-劣势： - 需要更多的磁盘空间；
- 恢复速度慢；
- 如果每次都同步，有性能压力；
- 存在个别Bug，造成不能恢复。
- 选择：
- 推荐两个都开启；
- 对数据不敏感，RDB；
- 单独AOF可以存在Bug；
- 单纯做为缓存，可以不开启。
