Redis先执行指令，再记录AOF日志的原因：Redis选择将大部分数据保存在内存中，以提高运行速度，Redis 的数据是存内存的，断电之后就丢了，Redis 的 AOF / RDB 相当于有一个把硬盘当内存的 slave。
一、Redis先执行指令，再记录AOF日志的原因
Redis是一种内存数据库，对于大多数的操作，Redis会先将请求写入内存中的数据结构，然后再异步地将修改同步到磁盘上的AOF（Append-Only File）文件中，这就是非常高效的原因。Redis的性能很大程度上取决于CPU的速度和内存的大小。因此，Redis选择将大部分数据保存在内存中，以提高运行速度。Redis 的数据是存内存的，断电之后就丢了。Redis 的 AOF / RDB 相当于有一个把硬盘当内存的 slave。存储引擎数据是存硬盘的，断电之后，可能有脏数据，也可能没有，需要 redo log / undo log 来做原子 commit。保护 commit 的数据是不可能在 commit 之后写的。存储引擎的日志只保护 uncommitted data。
二、Redis 在 Java Web 中的应用
1、缓存
在日常对数据库的访问中，读操作的次数远超写操作，比例大概在 1:9 到 3:7，所以需要读的可能性是比写的可能大得多的。当我们使用SQL语句去数据库进行读写操作时，数据库就会去磁盘把对应的数据索引取回来，这是一个相对较慢的过程。
如果我们把数据放在 Redis 中，也就是直接放在内存之中，让服务端直接去读取内存中的数据，那么这样速度明显就会快上不少，并且会极大减小数据库的压力，但是使用内存进行数据存储开销也是比较大的，限于成本的原因，一般我们只是使用 Redis 存储一些常用和主要的数据，比如用户登录的信息等。
一般而言在使用 Redis 进行存储的时候，我们需要从以下几个方面来考虑：
- **业务数据常用吗？命中率如何？**如果命中率很低，就没有必要写入缓存；
- **该业务数据是读操作多，还是写操作多？**如果写操作多，频繁需要写入数据库，也没有必要使用缓存；
- **业务数据大小如何？**如果要存储几百兆字节的文件，会给缓存带来很大的压力，这样也没有必要。
在考虑了这些问题之后，如果觉得有必要使用缓存，那么就使用它。
- 当名列前茅次读取数据的时候，读取 Redis 的数据就会失败，此时就会触发程序读取数据库，把数据读取出来，并且写入 Redis 中；
- 当第二次以及以后需要读取数据时，就会直接读取 Redis，读到数据后就结束了流程，这样速度就大大提高了。
从上面的分析可以知道，读操作的可能性是远大于写操作的，所以使用 Redis 来处理日常中需要经常读取的数据，速度提升是显而易见的，同时也降低了对数据库的依赖，使得数据库的压力大大减少。
分析了读操作的逻辑，下面我们来看看写操作的流程：
从流程可以看出，更新或者写入的操作，需要多个 Redis 的操作，如果业务数据写次数远大于读次数那么就没有必要使用 Redis。
2、高速读/写的场合
在如今的互联网中，越来越多的存在高并发的情况，比如天猫双11、抢红包、抢演唱会门票等，这些场合都是在某一个瞬间或者是某一个短暂的时刻有成千上万的请求到达服务器，如果单纯的使用数据库来进行处理，就算不崩，也会很慢的，轻则造成用户体验极差用户量流失，重则数据库瘫痪，服务宕机，而这样的场合都是不允许的。所以我们需要使用 Redis 来应对这样的高并发需求的场合，我们先来看看一次请求操作的流程图：
我们来进一步阐述这个过程：
- 当一个请求到达服务器时，只是把业务数据在 Redis 上进行读写，而没有对数据库进行任何的操作，这样就能大大提高读写的速度，从而满足高速响应的需求；
- 但是这些缓存的数据仍然需要持久化，也就是存入数据库之中，所以在一个请求操作完 Redis 的读/写之后，会去判断该高速读/写的业务是否结束，这个判断通常会在秒杀商品为0，红包金额为0时成立，如果不成立，则不会操作数据库；如果成立，则触发事件将 Redis 的缓存的数据以批量的形式一次性写入数据库，从而完成持久化的工作。
三、AOF简介
1、AOF持久化方式
AOF持久化方式是将redis的操作日志以追加的方式写入磁盘文件中。AOF持久化是以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
2、AOF实现方式
AOF(append only file)持久化是以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。
3、AOF优势
该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。
- 每秒同步：事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。
- 每次修改：而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。
- 不同步：可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
如果日志过大，Redis可以自动启用rewrite机制，压缩和瘦身相关的aof文件。Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个临时的新文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
延伸阅读1：AOF重写机制
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
