两种持久化方式
Redis有两种持久化方式，RDB和AOFgit
RDB(Redis DataBase)
RDB默认将数据保存到dump.rdb文件中redis
能够理解为将数据备份到磁盘，经过使用该文件就能够将磁盘中的数据恢复到Redis中app
相关配置操作系统
################################ SNAPSHOTTING ################################ # # 保存 DB 到硬盘: # # save <seconds> <changes> # # 将会在<seconds> 和 <changes>两个值同时知足时，将DB数据保存到硬盘中 # 其中<seconds> 每多少秒，<changes>是改变的key的数量 # # 在如下的例子中，将会存在以下的行为 # 当存在最少一个key 变动时，900秒(15分钟)后保存到硬盘 # 当存在最少10个key变动时，300秒后保存到硬盘 # 当存在最少1000个key变动时，60秒后保存到硬盘 # # 提示: 你能够禁用以下的全部 save 行 # # 你能够删除全部的save而后设置成以下这样的状况 # # save "" save 900 1 save 300 10 save 60 10000
在redis-cli中使用save或bgsave都可当即保存数据（bdsave 后台执行保存数据的动做）日志
持久化流程code
Redis会单首创建（fork）一个子进程来进行持久化server
子进程会先将数据写到一个临时文件中，待持久化过程结束后用这个临时文件替换掉上次的.rdb文件队列
持久化过程当中，主进程不进行IO操做。进程
因为RDB持久化每次会批量持久化数据，因此缺点是最后一次的持久化数据可能丢失。且因为每次fork时内存中的数据都会被克隆一份，数据会有2倍大小事务
AOF(Append Only File)
AOF将用户执行增删改的命令追加到appendonly.aof文件中
文件中存着用户使用过的除读操做外的历史命令的日志，重启redis-server后，Redis会读取并执行该文件中的命令，达到恢复数据的效果
相关配置
############################## APPEND ONLY MODE ############################### # 默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。 # 可是redis若是中途宕机，会致使可能有几分钟的数据丢失，根据save来策略进行持久化， # Append Only File是另外一种持久化方式，能够提供更好的持久化特性。 # Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件， # 每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。 appendonly yes # aof文件名(default: "appendonly.aof") appendfilename "appendonly.aof" # aof持久化策略的配置 # no 表示不执行fsync，由操做系统保证数据同步到磁盘，速度最快。 # always 表示每次写入都执行fsync，以保证数据同步到磁盘。 # everysec 表示每秒执行一次fsync，可能会致使丢失这1s数据。 appendfsync everysec
缺点
AOF使用的.aof文件的大小远大于.rdb文件的大小
持久化的使用方式
使用这两个文件恢复数据的方式：
将他们的文件放在redis目录下时，重启redis便可
两种持久化可同时使用，默认优先使用aof文件恢复数据
==注：若是你执行了fulhall（快乐删库）这条命令也会被追加到aof文件中或体如今.rdb文件中==
若是.aof或.rdb文件在备份时被写坏，致使Redis启动报错。使用redis-check-aof --fix <fileName>或redis-check-rdb --fix <fileName>修复文件
使用哪种持久化方式
两种都用
Redis的事务
一个事务是一条或多条命令的集合，这一条或者多条命令要么所有执行成功，要么所有执行失败。
Redis的支持事务，可是是部分支持。Redis的事务不保证原子性
用关事务的命令
MULTI 开始事务
DISCARD 取消事务
EXEX 执行事务中的命令
WATCH key 监视指定的key，若是==事务开始前==key的值被其余人修改了，事务执行的时候会被打断，事务中全部命令执行失败
UNWATCH 取消对全部key的WATCH
Redis事务的特色
Redis对事务的支持是部分支持，不是彻底支持
- 若是在一个事务中的命令出现错误，那么全部的命令都不会执行
- 若是在一个事务中出现运行错误，那么正确的命令会被执行
单独的隔离操做：事务中全部的命令多会序列化、按顺序地执行。事务在执行的过程当中，不会被其余客户端发送来的命令请求所打断
没有隔离级别的概念：队列中的命令没有提交以前都不会实际的被执行，由于事务提交前任何指令都不会被实际的执行，也就是不存在 “ 事务内的查询要看到事务里面的更新，在事务外查询不能看到 ”
不保证原子性：Redis 同一个事务中若是有一条命令执行失败，其后的命令仍然会被执行，没有回滚
Watch监控
watch在上述事务命令中已经简单介绍过，这里再也不赘述
| 锁的名称 | 描述 |
|---|---|
| 乐观锁 | 乐观。每次取数据的时候，会认为数据没有被修改过 |
| 悲观锁 | 悲观。每次取数据的时候，会认为数据都被修改过 |
| CAS（Check And Set） | 乐观锁的实现 |
加悲观锁，就是锁表。A在用数据，那B就不能用数据。由于悲观锁为防止取的数据是被修改过的而将数据锁上
加乐观锁，像git同样。A在改数据，结果B在A改以前改过了，那么A就要先拿到最新的数据而后再修改，提交。和git的pull，push的同样。由于乐观锁不会锁表，而会在改数据前检查一下能不能改
watch指令相似乐观锁