（学习交流）三级缓存——nginx+redis+ehcache （一）

目的：解决电商网页，高并发，高可用的需求。

首先从redis的学习开始

redis需要面对的问题——海量数据，大量访问，高并发，高可用，服务器出现问题时数据的备份和恢复。

简而言之就是redis如何进行数据的存，取。

一，redis的持久化

问题：

 

redis突发状况，数据如果没有持久化，那么就会发生大量数据丢失，造成损失，那么持久化就是必需。

 

redis持久化：

分为RDB，AOF，目的都是为了数据恢复。

RDB——对redis中的数据执行周期性的持久化。

AOF——对每条写入指令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，通过回放AOF的日志写入数据。

 

RDB的优点：

RDB会生成多个数据文件，每个数据文件都代表某一个时刻中redis的数据，这种多个数据备份的方式，适合冷备份，可以将这些数据文件保存在相对安全的存储中。

RDB对于redis的对外读写服务，影响小，可以保持redis的高性能，因为redis的主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。

RDB相对于AOF来说，恢复数据是直接加载数据文件，而不像AOF读取日志的写入指令，效率更高，更利于重启和恢复redis进程。

RDB的缺点：

RDB在恢复数据的及时性低于AOF，RDB一般间隔五分钟或者更长时间，形成一个数据文件，那么恢复数据就会丢失这五分钟甚至更长时间的数据，所以RDB不适合作为第一优先的恢复方案。

RDB在fork子进程写数据文件的时候，如果间隔时间较长，产生的文件就会比较大，会影响redis的运行效能，所以一般不建议间隔的时间过长。

AOF的优点：

AOF可以保存数据的及时性，一般AOF间隔一秒，通过一个后台线程执行一次fsync操作，保证os cache中的数据写入磁盘中，最多丢失一秒的数据。

AOF文件以append-only的模式写入，没有磁盘寻址的开销，写入性能高，而且文件不容易破损，即使文件尾部破损，也容易修复。

AOF文件过大，需要重写操作的时候，会对其中的写入指令进行压缩，创建出一份需要恢复数据的最小日志。在创建新日志的时候，老文件的指令照常写入，当新的日志合并写完后，就会替换掉老日志。

AOF已非常可读的方式进行记录（非常可读的方式，没有想明白），如果有人误操作，用flushall命令清空了所有数据，只要后台rewrite没有发生，那么就可以拷贝AOF文件，将flushall指令删除，再将该AOF文件放回，通过恢复机制，恢复数据。

AOF的缺点：

相同数据而言，AOF文件通常比RDB文件要大。

AOF对于redis的QPS（每秒访问量）影响要大于RDB，如果AOF的fsync设置成每写入一条数据就fsync一次，QPS性能降低会更加明显。

AOF基于日志/合并/回放的方式比RDB持久化文件更容易出现bug。

AOF做数据恢复会比RDB要慢，因为是执行写入指令，不适合做冷备。