Redis

简介

remote dictionary server

一个key value store

可以持久化的cache，断电或重启后，数据也不会丢失。因为Redis的存储分为内存存储、磁盘存储和log文件三部分，重启后，Redis可以从磁盘重新将数据加载到内存中

Redis运行在内存中但是可以持久化到磁盘

Redis支持复杂的数据特性（string list hash set zset）

Redis以内存作为数据存储介质，所以读写数据的效率极高，读取速度可高达110000次/s，写速度高达81000次/s。

支持主从模式，可以配置集群

关系型数据库的扩展性不强，难以改变表结构，nosql数据库没有关联关系，数据结构简单，拓展表比较容易

配合关系型数据库做高速缓存，减少io的读操作，减轻io的压力

Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。

持久化

官方推荐都启用（先使用aof）

1. 对数据不敏感，单独用RDB

2. 不建议单独使用AOF

1.rdb

在指定时间间隔内，将内存中的数据作为一个快照文件（snapshot）写入到磁盘，读取的时候也是直接读取snapshot文件到内存中

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

redis单独创建（fork）一个进程来持久化，会先将数据写入临时文件中，待上次持久化结束后，会将该临时文件替换上次持久化文件，比aof高效，但是最后一次数据可能会丢失

dbfilename dump.rdb

save 900 1

save 300 10

save 60 10000

劣势

1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

2.aof

以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

以日志形式记录每个写操作，启动时通过日志恢复操作

默认每秒记录一次，如果宕机该秒记可能失效

bgrewriteaof 因为日志是追加方式，文件会越来越大，当超过了设置的阈值时，日志文件会压缩，只保留可以恢复数据的最小指令集

主进程会fork出一条新的进程对文件重写，重写aof文件的操作并没有读取旧的aof文件，而是将整个内存的数据内容用命令的方式重写了一个新的aof文件。

当aof文件大小是上次rewrite后大小的一倍且文件大于64mb时触发重写

appendonly no

appendfilename appendonly.aof

appendfsync everysec

    no：表示等操作系统进行数据缓存同步到磁盘（快） 
    always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全） 
    everysec：表示每秒同步一次（折衷，默认值）

劣势

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效

如果aof或rdb文件语法有误，可以使用上面两条命令来修复。

aof修复命令：redis-check-aof --fix appendonlly.aof

rdb修复命令：redis-check-rdb--fix dump.rdb

主从复制

读写分离 性能拓展 容灾恢复

slaveof ip port

一主多从或者级联结构

全量同步和增量同步

1 全量同步

　　Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下： 

　　1）从服务器连接主服务器，发送SYNC命令； 

　　2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 

　　3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 

　　4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 

　　5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 

　　6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；.

　　另外，slave宕机并重新连接到master之后，slave会请求全量同步

2 增量同步

　　Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 

增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

 

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。

当然，如果有需要，slave 在任何时候都可以发起全量同步。

redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

 

事务

watch

unwatch

multi

exec

discard

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

mysql rollback VS redis discard

Rollback后,该条语句之前的所有语句都失效，回滚到本次事务开始之前的数据库一致性状态

Discard只是结束本次事务,前2条语句造成的影响仍然还在

muitl，将命令先放到queued队列中，exec之后再执行。放入队列中时，只是检查语法的正确性，Exec之后,会执行正确的语句,并跳过有不适当的语句.根本不会回滚。

Redis的事务中,启用的是乐观锁,只负责监测key没有被改动.watch unwatch