目录
Redis 是典型的 NoSQL 数据库，支持多种数据结构类型。设计思想是： 单线程+多路IO复用技术
图中例子说明：“黄牛”到“火车站”为单线程操作，同时使用多个socket链接可以使得“黄牛”一刻不停一但处理完成后就可以继续下一个任务。总结一句话就是：通过一个线程，进行拨开关的方式，来同时传输多个IO流。
NoSQL数据库
web2.0时代，访问量太大，CPUI和内存有巨大压力，如果还是按照单个服务器进行响应的话，显然性能是不够的，于是引出分布式架构的服务，也就是多台服务器来响应请求，使用过NoSQL数据库进行解决。
NoSQL数据库的特点：
NoSQL（ NoSQL = Not Only SQL ），意即 “不仅仅是 SQL” ，泛指非关系型的数据库。
NoSQL 不依赖业务逻辑方式存储，而以简单的 key-value 模式存储。因此大大的增加了数据库的扩展能力。
- 不遵循 SQL 标准。
- 不支持 ACID。
- 远超于 SQL 的性能。
适用于的场景
- 对数据高并发的读写；
- 海量数据的读写；
- 对数据高可扩展性的。
不适用的场景
- 需要事务支持；
- 基于 sql 的结构化查询存储，处理复杂的关系，需要即席查询。
- 用不着sql的情况以及用了sql也不行的情况下，考虑NoSQL
常见的 NoSQL 数据库
-
Redis
-
MongoDB
-
常用五大基本数据类型
前言：Redis键（key操作）
keys *：查看当前库所有 key
set key value：添加一组 k-v
exists key：判断某个 key 是否存在
type key：查看你的 key 是什么类型
del key：删除指定的 key 数据（直接删除，而不是异步删除）
unlink key：根据 value 选择非阻塞删除，仅将 keys 从 keyspace 元数据中删除，真正的删除会在后续异步操作
expire key 10：为给定的 key 设置过期时间
ttl key：查看还有多少秒过期，-1表示永不过期，-2表示已过期
select：命令切换数据库
dbsize：查看当前数据库的 key 的数量
flushdb：清空当前库
flushall：通杀全部库
字符串（String）
String 类型是最基本的类型，是二进制安全的。意味着 Redis 的 string 可以包含任何数据，比如 jpg 图片或者序列化的对象，只要数据能够存储为字符串类型，redis都能通过k-v的形式存储。
String 类型是 Redis 最基本的数据类型，一个 Redis 中字符串 value 最多可以是 512M。
命令操作：
set <key> <value>：添加键值对，也包含对一个key下的value进行覆盖
get <key>：查询对应键值
append <key> <value>：将给定的 <value> 追加到原值的末尾，返回添加后的字符串长度值
strlen <key>：获得值的长度
setnx <key> <value>：只有在 key 不存在时，才能设置 key 的值（注意与set命令的区别）
incr <key>：将 key 中储存的数字值增 1，只能对数字值操作，如果为空，新增值为 1（具有原子性）
decr <key>：将 key 中储存的数字值减 1，只能对数字值操作，如果为空，新增值为 -1
incrby/decrby <key><步长>：将 key 中储存的数字值增减。自定义步长
mset <key1> <value1> <key2> <value2> ：同时设置一个或多个 key-value 对
mget <key1> <key2> <key3>...：同时获取一个或多个 value
msetnx <key1> <value1> <key2> <value2>...：同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在（原子性操作，有一个失败那么就全部失败，成功返回1，反之返回0）
getrange <key><起始位置><结束位置>：获得值的范围（将字符串理解成一个数组，按数组序号进行取子字符串的操作）
setrange <key><起始位置><value>：用 <value> 覆写 <key> 所储存的字符串值
setex <key><过期时间><value>：设置键值的同时，设置过期时间，单位秒。（可以通过ttl key的命令，查看过期时间）
getset <key><value>：以新换旧，设置了新值同时获得旧值。
原子性
所谓 原子 操作是指不会被线程调度机制打断的操作；
这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （切换到另一个线程）。
在单线程中， 能够在单条指令中完成的操作都可以认为是"原子操作"，因为中断只能发生于指令之间。（而redis是单线程的，所以redis中的操作是不会被打断的）
在多线程中，不能被其它进程（线程）打断的操作就叫原子操作。
Redis 单命令的原子性主要得益于 Redis 的单线程。
列表（List）
单键多值
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。
它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。
lpush/rpush <key><value1><value2><value3> ....： 从左边/右边插入一个或多个值。
k1内部: v3 v2 v1（lpush）
k1内部: v1 v2 v3（rpush）lpop/rpop <key>：从左边/右边吐出一个值。值在键在，值光键亡。
rpoplpush <key1><key2>：从 <key1> 列表右边吐出一个值，插到 <key2> 列表左边。(道理同上)
lrange <key><start><stop>：按照索引下标获得元素（从左到右）
lrange <key> 0 -1：左边第一个，-1右边第一个，（0 -1表示获取所有）
lindex <key><index>：按照索引下标获得元素（从左到右，从0开始到index索引值）
llen <key>：获得列表长度
linsert <key> before/after <value> <newvalue>：在 <value> 的前面/后面插入 <newvalue> 插入值
lrem <key><n><value>：从左边删除 n 个 value（从左到右）
lset <key><index><value>：将列表 key 下标为 index 的值替换成 value
数据结构
List 的数据结构为快速链表 quickList。
首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是 ziplist，也即是压缩列表。
- 它将所有的元素紧挨着一起存储，分配的是一块连续的内存。
当数据量比较多的时候才会改成 quicklist。
因为普通的链表需要的附加指针空间太大，会比较浪费空间。比如这个列表里存的只是 int 类型的数据，结构上还需要两个额外的指针 prev 和 next。
Redis 将链表和 ziplist 结合起来组成了 quicklist。也就是将多个 ziplist 使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。quicklist结构图如下：
Set（集合）
Set 对外提供的功能与 List 类似列表的功能。（一个key，对应一个set集合）
特殊之处在于 Set 是可以 自动排重 的
当需要存储一个列表数据，又不希望出现重复数据时，Set 是一个很好的选择，并且 Set 提供了判断某个成员是否在一个 Set 集合内的重要接口，这个也是 List 所不能提供的。
Redis 的 Set 是 String 类型的无序集合。它底层其实是一个 value 为 null 的 hash 表，所以添加，删除，查找的复杂度都是 O(1)。
一个算法，随着数据的增加，执行时间的长短，如果是 O(1)，数据增加，查找数据的时间不变。
sadd <key><value1><value2> .....：将一个或多个 member 元素加入到集合 key 中，已经存在的 member 元素将被忽略
smembers <key>：取出该集合的所有值。
sismember <key><value>：判断集合 <key> 是否为含有该 <value> 值，有返回 1，没有返回 0
scard<key>：返回该集合的元素个数。
srem <key><value1><value2> ....：删除集合中的某个元素
spop <key>：随机从该集合中吐出一个值
srandmember <key><n>：随机从该集合中取出 n 个值，不会从集合中删除
smove <source><destination>value：把集合中一个值从一个集合移动到另一个集合（会删除该值）
sinter <key1><key2>：返回两个集合的交集元素
sunion <key1><key2>：返回两个集合的并集元素
sdiff <key1><key2>：返回两个集合的差集元素（key1 中的，不包含 key2 中的）
Hash（哈希）
Redis hash 是一个键值对集合。
Redis hash 是一个 String 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。（ 可以理解为Java中的Map<String,Object> ）
hset <key><field><value>：给 <key> 集合中的 <field> 键赋值 <value>
- hset user:1001 id 1，redis允许key带 ：，可以理解为key值是 user:1001，这是为了存很多对象时，用来区分不同对象
- hset user:1001 name zhanggsan，给 user:1001 这个key对应的对象中，添加一个name字段，值为zhangsan
hget <key1><field>：从 <key1> 集合 <field> 取出 value
- hget user:1001 id，打印结果为“1”
- hget user:1001 name，打印结果为“zhangsan”
hmset <key1><field1><value1><field2><value2>...： 批量设置 hash 的值（新版本这项命令，已经可以用hset进行实现了）
hexists <key1><field>：查看哈希表 key 中，给定域 field 是否存在（1：存在，0：不存在）
hkeys <key>：列出该 hash 集合的所有 field
- hkeys user:1001，列出这个key下所有的字段
hvals <key>：列出该 hash 集合的所有 value
hincrby <key> <field> <increment>：为哈希表 key 中的域 field 的值加上增量 1 -1
hsetnx <key> <field> <value>：将哈希表 key 中的域 field 的值设置为 value ，当且仅当域 field 不存在
数据结构
Hash 类型对应的数据结构是两种：ziplist（压缩列表），hashtable（哈希表）。
当 field-value 长度较短且个数较少时，使用 ziplist，否则使用 hashtable。
Zset（有序集合）
Redis 有序集合 zset 与普通集合 set 非常相似，是一个没有重复元素的字符串有序集合。
不同之处是有序集合的每个成员都关联了一个评分（score）,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复的。
因为元素是有序的，所以可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。
访问有序集合的中间元素也是非常快的，因此能够使用有序集合作为一个没有重复成员的智能列表。
zadd <key> <score1> <value1> <score2> <value2> …：将一个或多个 member 元素及其 score 值加入到有序集 key 当中
zrange <key> <start> <stop> [WITHSCORES]：返回有序集 key 中，下标在 <start><stop> 之间的元素（ 0 -1 ，表示所有）
- 当带上 WITHSCORES 时，可以让分数一起和值返回到结果集
zrangebyscore key min max [withscores] [limit offset count]：返回有序集 key 中，所有 score 值介于 min 和 max 之间（包括等于 min 或 max ）的成员。有序集成员按 score 值递增（从小到大）次序排列。
zrevrangebyscore key max min [withscores] [limit offset count]：同上，改为从大到小排列
zincrby <key> <increment> <value>：为元素的 score 加上增量
zrem <key> <value>：删除该集合下，指定值的元素
zcount <key> <min> <max>：统计该集合，分数区间内的元素个数
zrank <key> <value>：返回该值在集合中的排名，从 0 开始。
数据结构
SortedSet（zset）是 Redis 提供的一个非常特别的数据结构，一方面它等价于 Java 的数据结构 Map<String, Double>，可以给每一个元素 value 赋予一个权重 score，另一方面它又类似于 TreeSet，内部的元素会按照权重 score 进行排序，可以得到每个元素的名次，还可以通过 score 的范围来获取元素的列表。
zset 底层使用了两个数据结构
hash，hash 的作用就是关联元素 value 和权重 score（通过key值，能够找到关联的value和score），保障元素 value 的唯一性，可以通过元素 value 找到相应的 score 值
跳跃表，跳跃表的目的在于给元素 value 排序，根据 score 的范围获取元素列表
配置文件
**Redis 的配置文件位于 Redis 安装目录下，文件名为 ** redis.conf (Windows 名为 redis.windows.conf)。
网络相关配置。
##bind##
默认情况 bind=127.0.0.1 只能接受本机的访问请求。
不写的情况下，无限制接受任何 ip 地址的访问。
生产环境肯定要写你应用服务器的地址，服务器是需要远程访问的，所以需要将其注释掉。
如果开启了protected-mode，那么在没有设定 bind ip 且没有设密码的情况下，Redis 只允许接受本机的响应
##protected-mode##
将本机访问保护模式设置 no。
##port##
端口号，默认 6379
##tcp-backlog##
设置 tcp 的 backlog，backlog 其实是一个连接队列，backlog 队列总和 $=$ 未完成三次握手队列 $+$ 已经完成三次握手队列。
在高并发环境下你需要一个高 backlog 值来避免慢客户端连接问题。
##timeout##
一个空闲的客户端维持多少秒会关闭，0 表示关闭该功能。即永不关闭。
##tcp-keepalive##
对访问客户端的一种心跳检测，每个 n 秒检测一次。（默认是300s检测一次）
单位为秒，如果设置为 0，则不会进行 Keepalive 检测。
##daemonize##
是否为后台进程，设置为 yes。
守护进程，后台启动。
##pidfile##
存放 pid 文件的位置，每个实例会产生一个不同的 pid 文件。
##loglevel##
指定日志记录级别，Redis 总共支持四个级别：debug、verbose、notice、warning，默认为 notice。
##logfile##
日志文件名称。
##database##
设定库的数量 默认16，默认数据库为 0，可以使用 SELECT <dbid> 命令在连接上指定数据库 id。
##maxmemory##
建议必须设置，否则，将内存占满，造成服务器宕机。
设置 redis 可以使用的内存量。一旦到达内存使用上限，redis 将会试图移除内部数据，移除规则可以通过 maxmemory-policy 来指定。
如果 redis 无法根据移除规则来移除内存中的数据，或者设置了不允许移除，那么 redis 则会针对那些需要申请内存的指令返回错误信息，比如 SET、LPUSH 等。
但是对于无内存申请的指令，仍然会正常响应，比如 GET 等。如果你的 redis 是主 redis（ 说明你的 redis 有从 redis ），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素。
##maxmemory-policy##
volatile-lru：使用 LRU 算法移除 key，只对设置了过期时间的键（最近最少使用）。
allkeys-lru：在所有集合 key 中，使用 LRU 算法移除 key。
volatile-random：在过期集合中移除随机的 key，只对设置了过期时间的键。
allkeys-random：在所有集合 key 中，移除随机的 key。
volatile-ttl：移除那些 TTL 值最小的 key，即那些最近要过期的 key。
noeviction：不进行移除。针对写操作，只是返回错误信息。
##maxmemory-samples##
设置样本数量，LRU 算法和最小 TTL 算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis 默认会检查这么多个 key 并选择其中 LRU 的那个。
一般设置 3 到 7 的数字，数值越小样本越不准确，但性能消耗越小。
Redis的发布与订阅
Redis 发布订阅（ pub/sub ）是一种消息通信模式：发送者（ pub ）发送消息，订阅者（ sub ）接收消息。
Redis 客户端可以订阅任意数量的频道。
发布者可以建立许多个频道进行消息的发送（如上图频道1、频道2、频道3），供订阅者进行接收和监听消息。
- 客户端可以订阅频道
- 当给这个频道发布消息后，消息就会发送给订阅的客户端
发布订阅命令行实现
- 打开一个客户端订阅channel1
- subscribe channel1
- 打开另一个客户端，给channel1发布消息hello
-
publish channel1 hello
-
返回的数字表示：订阅者的数量、
- 打开第一个客户端可以看到发送的信息
Redis6 新数据类型
Bitmaps
- 将 Bitmaps 数据类型理解为一个数组，每个单位只存储0和1
实例：
- getbit ：获取Bitmaps中某个偏移量的值
- bitcount [start end]：统计字符串被设置为1的bit数，start end可以指定范围，且可以使用负数值，例如：-1表示最后一个位，-2表示倒数第二个位置（从0开始....）
- bitop and(or/not/xor) [key...]：复合操作，可以做多个Bitmaps的交集、并集等操作，并将结果保存在destkey中
- 例如：bitop and users:1 users:2 users:3，将users:2与users:3的交集结果存放到key为users:1的值中
Bitmaps与set对比
HyperLogLog
基数：{1，2，2，3，4，5} 去重后是{1，2，3，4，5} 基数就是5
命令操作：
-
pfadd [element...]：添加指定元素到HyperLogLog中，执行命令后，若基数发生变化则返回1，否则返回0
-
pfcount [key...]：计算基数值
-
pfmerge [其中，sourcekey可以为多个]：将多个HyperLogLog数据类型进行合并，例子比如将月活跃用户数与日活跃用户数进行合并，就可以使用pfcount进行统计基数
Geospatial
事务和锁机制
Redis 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
Redis 事务的主要作用就是串联多个命令防止别的命令插队。
Multi、Exec、Discard
Multi
Exec
Discard
从输入 Multi 命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入 Exec 后，Redis 会将之前的命令队列中的命令依次执行。
组队的过程中可以通过 Discard 来放弃组队。
Redis的事务就是：先使用multi进行命令的添加（组队过程），组队完毕后，使用exec进行执行，这个执行过程不能被其他命令打断（相当于事务执行的过程），如果要中止，就使用discard命令（类似于回滚操作）。
-
multi开启组队，输入命令；组队成功，exec执行事务，执行完毕，事务结束
-
放弃组队
-
组队中有命令错误，不会执行
-
组队中不报错，执行时报错
悲观锁
悲观锁（Pessimistic Lock），即每次去拿数据的时候都认为有其他线程会修改，所以每次在拿数据的时候都会上锁，这样其他线程想要拿到这个数据就会被 block 直到释放锁后，成功拿到锁。（效率低，操作之前先上锁）
乐观锁
乐观锁（Optimistic Lock），即每次去拿数据的时候都认为其他线程不会修改，所以不会上锁，但是在更新的时候会判断，在此期间有没有其他线程去更新这个数据，可以使用版本号控制等机制。
乐观锁适用于多读的应用类型，这样可以提高吞吐量。
Redis 就是利用这种 check-and-set 机制实现事务的。
Watch、unwatch
在执行 multi 之前，先执行 watch key1 [key.....]，可以监视一个（或多个 ）key 。如果在事务执行之前，这个 key 被其他命令所改动，那么事务将被打断。（类似于上锁，一旦发现watch的这个key被修改了，那么自己的exec操作就会中断）
取消 WATCH 命令对所有 key 的监视：如果在执行 WATCH 命令之后，EXEC 命令或 DISCARD 命令先被执行，那么就不需要再执行 UNWATCH 。
事务三特性
-
单独的隔离操作
事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
-
没有隔离级别的概念
队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。
-
不保证原子性
事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚 。
模拟秒杀
Controller层
package com.hubin.controller;
import com.hubin.service.RedisService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.Random;
import java.util.UUID;
@RestController
public class RedisController {
@Autowired
RedisService redisService;
@RequestMapping("/test")
public String seckilll(){
String mid = UUID.randomUUID().toString().replace("-", "");
String proId=UUID.randomUUID().toString().replace("-","");
String doseekill = redisService.doseekill(mid, proId);
return doseekill;
}
}
service层
package com.hubin.service.impl;
import com.hubin.service.RedisService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.dao.DataAccessException;
import org.springframework.data.redis.core.RedisOperations;
import org.springframework.data.redis.core.SessionCallback;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import java.util.List;
@Service
public class RedisServiceImpl implements RedisService {
@Autowired
// StringRedisTemplate redisTemplate;
StringRedisTemplate redisTemplate;
@Override
public String doseekill(String mid, String proId) {
redisTemplate.setEnableTransactionSupport(true);
//1.判断非空
//略
//2.拼接key
String midKey="sk:"+mid+"user";
String proKey="sk:"+proId+"pro";
List<Object> execute = redisTemplate.execute(new SessionCallback<List<Object>>() {
@Override
public List<Object> execute(RedisOperations redisOperations) throws DataAccessException {
redisTemplate.watch("ware");
String ware = redisTemplate.opsForValue().get("ware");
//4.获取库存如果没有，则还么开始
if (ware == null) {
System.out.println("还没开始");
return null;
}
//5.判断用户是否在重复秒杀操作
String s = redisTemplate.opsForValue().get(midKey);
if (s != null) {
System.out.println("该用户已经秒杀过了");
return null;
}
//6如果没有货物了则秒杀结束
if (Integer.parseInt(ware) < 1) {
System.out.println("货物已经销售完毕");
return null;
}
//7秒杀
redisOperations.multi();
redisOperations.opsForValue().decrement("ware");
redisOperations.opsForValue().set(midKey, proKey);
return redisOperations.exec();
}
});
if(execute!=null&&execute.size()!=0){
System.out.println(execute);
System.out.println("秒杀成功");
return "秒杀成功";
}
return "秒杀失败";
}
}
html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<form action="/test">
<button>
test
</button>
</form>
</body>
</html>超卖情况
Redis中两种持久化机制
两种持久化机制，RDB和AOF，简单来说就是存数据使用的哪种机制，默认是使用RDB(Redis DataBase)。
RDB
Redis DataBase
在指定的时间间隔内将内存中的 数据集快照 写入磁盘，即 Snapshot 快照，恢复时是将快照文件直接读到内存里。
周期性地进行持久化的操作
Redis 会单独创建一个子进程（fork）来进行持久化。
底层执行过程：先将数据写入到一个临时文件中，待持久化过程完成后（同步过程完成），再将这个临时文件内容覆盖到 dump.rdb（持久化文件）。
- 整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能。
- 为什么要先同步到文件临时区域而不直接同步到rdb中？若同步过程中发生异常情况中断，不会导致数据库中的数据发生损坏，待同步过程完成后，用临时文件替代这个持久化的文件，保证了数据的完整性和一致性。
- 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。
RDB 的缺点是最后一次持久化后的数据可能丢失。
Fork
-
Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。
-
作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
-
在 Linux 程序中，fork() 会产生一个和父进程完全相同的子进程，但子进程在此后多会 exec 系统调用，出于效率考虑，Linux 中引入了 写时复制技术
-
一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程
配置
dump 文件名字
在 redis.conf 中配置文件名称，默认为 dump.rdb。
dump 保存位置
rdb 文件的保存路径可以修改。默认为 Redis 启动时命令行所在的目录下。
stop-writes-on-bgsave-error
即当 redis 无法写入磁盘，关闭 redis 的写入操作。推荐yes
rdbcompression
持久化的文件是否进行压缩存储。
rdbchecksum
完整性的检查，即数据是否完整性、准确性。
save
表示写操作的次数。
格式：save 秒 写操作次数
优点
- 适合大规模的数据恢复；
- 对数据完整性和一致性要求不高更适合使用；
- 节省磁盘空间；
- 恢复速度快。
- redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作
缺点
- Fork 的时候，内存中的数据被克隆了一份，大致 2 倍的膨胀性需要考虑；
- 虽然 Redis 在 fork 时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能；
- 在备份周期在一定间隔时间做一次备份，所以如果还没到达指定备份时间间隔的时候，Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改，数据发生了丢失。
AOF
Append Only File
以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来（读操作不记录）， 只许追加文件但不可以改写文件（可能是使用的redo和undo日志恢复？）。Redis 启动之初会读取该文件重新构建数据，换言之，如果 Redis 重启就会根据日志文件的内容将写指令从前到后执行一次，以完成数据的恢复工作。
一种使用追加方式记录数据的方法
执行流程
-
客户端的请求写命令会被 append 追加到 AOF 缓冲区内；
-
AOF 缓冲区根据 AOF 持久化策略
[always,everysec,no]将操作 sync 同步到磁盘的 AOF 文件中； -
AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 Rewrite 重写，压缩 AOF 文件容量；
-
Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。
AOF 和 RDB 同时开启时，系统默认读取 AOF 的数据（数据不会存在丢失）
配置
redis.conf中配置开启aof，默认生成的aof配置文件为appendonly.aof，与rdb文件路径一致（启动路径）。
AOF 默认不开启 （RDB默认开启）
若AOF和RDB同时开启，系统默认读取AOF的数据（数据不会存在丢失）。
文件名字
AOF 同步频率设置
appendfsync always
始终同步，每次 Redis 的写入都会立刻记入日志；
性能较差但数据完整性比较好。
appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync no
Redis 不主动进行同步，把同步时机交给操作系统。
Rewrite 压缩
当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof。
优点
- 备份机制更稳健，丢失数据概率更低；
- 可读的日志文本，通过操作 AOF 稳健，可以处理误操作。
缺点
- 比起 RDB 占用更多的磁盘空间（不仅记录数据还要记录操作）；
- 恢复备份速度要慢；
- 每次读写都同步的话，有一定的性能压力；
- 存在个别 Bug，造成不能恢复。
总结
官方推荐两个都启用。
如果对数据不敏感（允许数据有部分丢失），可以选单独用 RDB。
不建议单独用 AOF，因为可能会出现 Bug。
如果只是做纯内存缓存，可以都不用。
主从复制
基本介绍
主机数据更新后根据配置和策略， 自动同步到备机的 master/slaver 机制，Master 以写为主，Slaver 以读为主，即主服务器承担写操作，复制的若干 从服务器 则承担读操作。
特点：
-
读写分离，性能扩展
编
2.容灾快速恢复
1.某个从服务器发生故障，那么会快速切换到另一个从服务器中，不影响读操作的进行
3.一主多从
1.只有一台主服务器，供其他从服务器进行复制
搭建一主两从
1.完全复制一份一摸一样的redis文件夹（作为从服务器）
2.修改第二份里面的redis.windows.conf里面的port，将其修改为与主服务器不一样的端口
3.在从文件夹里面的redis.windows.conf里面添加一句slaveof 127.0.0.1 6379（这里的6379是我主服务器的端口号）这个配置是为了让从服务器找到主服务器（不在配置文件里面加直接在黑从客户
端的黑窗口中直接输入也可以）。
4.依次先启动主服务器=>从服务器=>主客户端=>从客户端，使用info命令查看当前服务器主从状态
注意：1.在启动从客户端的时候要以黑窗口形式启动并且指定配置文件不然启动无效。
2.启动从客户端的时候指定启动的端口号不然会启动为主客户端 
一主二从
特点：
主机 6379，从机 6380 和 6381。
假设从机 6380 挂掉。（从机挂掉）
- 当6380重启后，6380不再是6379的从机，而是作为新的master；（从机重启后，不再是某个主机的从机，其自身就是一个主机）
- 当再次把6380作为6379的从机加入后，从机才会把数据从头到尾复制。（从机重启后，需要再输入成为从机的指令）
假设主机 6379 挂掉。（主机挂掉）
- 6380和6381仍然是6379的从机，不会做任何事；（从机不会改变）
- 当6379重启后，既然是主服务器。（主机重启后，还是主机）
主从复制原理
完整版：
-
slave 启动成功连接到 master 后会发送一个 sync 命令（同步命令）。
-
master 接到命令启动后台的存盘进程，对数据进行持久化操作，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master 将传送整个数据文件（rdb）到 slave，以完成一次完全同步。
-
当主服务进行写操作后，和从服务器进行数据同步。
-
全量复制：而 slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中。
-
增量复制：master 继续将新的所有收集到的修改命令依次传给 slave，完成同步。
-
只要是重新连接 master，一次完全同步（全量复制）将被自动执行。
全量复制：是从机主动去请求主机进行同步操作，是一开始连接的时候
增量复制：主机进行一次写操作之后，就主动同步从机
简洁版
薪火相传
上一个 slave 可以是下一个 slave 的 master（从机是另一个从机的主机，并由这个担任主机的从机，进行数据同步），slave 同样可以接收其他 slave的连接和同步请求，那么该 slave 作为了链条中下一个的 master，可以有效减轻 master 的写压力，去中心化降低风险。
slaveof <ip> <port>
-
特点与一主二从类似
-
中途变更转向：会清除之前的数据，重新建立拷贝最新的。
-
当某个担任主机的 slave 宕机，其挂在后面的 slave 都没法备份。
- 即当主机挂掉，从机还是从机，但是无法继续写数据。
反客为主
当一个 master 宕机后，后面的 slave 可以立刻升为 master，其后面的 slave 不用做任何修改。（需要手动完成，如果不手动执行的话，那么从机没有任何动作，主机重新启动后，还依旧是主机
哨兵模式
基本介绍
反客为主的自动版，即能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
- 创建 sentinel.conf 文件
/opt/etc/sentinel.conf
- 配置哨兵
sentinel monitor mymaster 172.16.xx.xxx 6379 1
# mymaster：给监控对象起的服务器名称
# 1：至少有多少个哨兵同意迁移的数量
- 启动哨兵
redis-sentinel /opt/etc/sentinel.conf
Window版下为:redis-server.exe sentinel.conf --sentinel主机挂掉，哨兵监控到之后，会按照选举规则，从 从机 中选举中产生新的主机，原来挂掉的主机会变成新主机的从机。
选举规则
选择条件依次为：
-
根据优先级别，slave-priority/replica-priority，优先选择优先级靠前的。（越小优先级越高）
-
根据偏移量，优先选择偏移量大的。（偏移量是指获得原主机数据最全的）
-
若前两个条件相同，那么选择 runid 最小的，优先选择最小的服务
- 每个redis实例启动后，都会随机生成一个40位的runid
复制延时
由于所有的写操作都是先在 master 上操作，然后同步更新到 slave 上，所以从 master 同步到 slave 从机有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave 机器数量的增加也会使这个问题更加严重。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
