Redis是使用c语言开的的数据库，redis的数据是存在内存中的，读写速度非常快，被广泛的用于缓存方向，分布式锁，消息队列，支持事务，持久化，lua脚本，多种集群方案。

使用场景：缓存，分布式锁，限流，消息队列，复杂的业务场景（redis提供的数据结构，bitmap统计活跃用户，排行榜等）

数据结构：

String：key-value类型，简单动态字符串(simple dynamic string) SDS,sds不逛可以保存文本数据还可以保存二进制数据，并且获取字符串长度复杂度为O（1）

常用命令：set get，strlen，exists，decr,incr,setex等

使用场景：一般常用在需要计数的场景，比如用户的访问次数，热点文章的点赞转发数量等

List ：压缩表，链表（双向链表）即可以支持反向查找和遍历，更方便操作，额外的内存开销

常用命令：rpush，lpop，lpush，rpop，lrange，llen等

使用场景：发布与订阅或者消息队列，慢查询。

Hash类似于hashmap，内部实现也差不多是数组+链表，redis的hash做了更多的优化，hash是一个string类型的field和value的映射表，特别适合于存储对象。

常用命令：hset，hmset，hexists，hget，hgetall，hkeys，hvals等

使用场景：系统中的对象存储。

Set:类似于hashset。无序集合， 基于set可以轻易实现交集，并集，差集，共同关注，共同粉丝，共同喜好等，

常用命令：sadd。spop，smembers，sismember，scard，sinterstore，sunion等

使用场景：交集并集差集。

Sorted set (Zset)跳表，压缩表ziplist:和set相比，sorted set增加一个权重参数score，使得集合中的元素能够按照score进行有序排列。

常用命令：zadd，zcard，zscore，zrange，zrevrange，zrem等

应用场景：需要数据根据某个权重进行排序的场景，直播间在线用户列表，各种礼物排行榜，弹幕消息。

BItmap：存储的是连续的二进制数据0和1，通过bitmap，只需要一个bit位来表示某个元素对应的值或者状态，key就是对应的元素本身，极大结算存储空间。

常用命令：setbit，getbit，bitcount，bitop

应用场景：签到，是否登录，用户行为统计

Redis是基于Reactor模式来设计开发的自己的一套事件处理模型

IO多路复用

redis过期策略：惰性删除，定时删除

1. volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
4. allkeys-lru（least recently used）：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！

4.0 版本后增加以下两种：

7. volatile-lfu（least frequently used）：从已设置过期时间的数据集（server.db[i].expires）中挑选最不经常使用的数据淘汰
8. allkeys-lfu（least frequently used）：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的 key

快照（snapshotting）持久化（RDB）

Redis 可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用。

快照持久化是 Redis 默认采用的持久化方式，在 Redis.conf 配置文件中默认有此下配置：、

save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

AOF 持久化

appendonly yes

开启aof持久化后每执行一条会更改redis中的数据命令，redis就会将该命令写入到内存缓存server.aof_buf中，然后再根据appendfsync配置来决定何时将其同步到硬盘中的aof文件。

aof文件的保存位置和rdb文件的位置相同，都是通过dir参数设置的，默认文件名是appendonly.aof

redis的配置文件中存在三种不同的aof持久化方式：

appendfsync always #每次有数据修改发生都会写入aod文件，这样会严重降低redis的速度

appendfsync everysec #每秒钟同步一次，显示地将多个写命令同步到硬盘

annpendfsync no #让操作系统决定何时进行同步

redis4.0开始支持rdb和aof混合使用

缓存穿透：大量请求的key根本不存在在缓存中，导致请求直接到了数据库上。

解决办法：首先做好参数校验，不合法的请求直接抛出异常信息返回客户端，当查询数据库不存在时，默认缓存一个空。

布隆过滤器元素不在，那么这个元素一定不在。（过滤非法请求）

缓存雪崩：缓存在同一时间大面积的失效，后面的请求直接落到了数据库上，造成数据库短时间能承受大量请求；

解决方法：采用reids集群，限流，设置不同的失效时间，比如随机设置缓存失效时间，环境永不失效。

如何保证缓存和数据库数据一致性：

1.更新 DB，然后直接删除 cache（失败重试）

2.加锁db和查询（强一致）

3.写入数据库后更新redis缓存放入消息队列，保证最终一直性（要求不是很高的服务中）。

哨兵机制

• 主观下线即 Sentinel 节点对 Redis 节点失败的偏见，超出超时时间认为 Master 已经宕机。Sentinel 集群的每一个 Sentinel 节点会定时对 Redis 集群的所有节点发心跳包检测节点是否正常。如果一个节点在 down-after-milliseconds 时间内没有回复 Sentinel 节点的心跳包，则该 Redis 节点被该 Sentinel 节点主观下线。
• 客观下线所有 Sentinel 节点对 Redis 节点失败要达成共识，即超过 quorum 个统一。当节点被一个 Sentinel 节点记为主观下线时，并不意味着该节点肯定故障了，还需要 Sentinel 集群的其他 Sentinel 节点共同判断为主观下线才行。该 Sentinel 节点会询问其它 Sentinel 节点，如果 Sentinel 集群中超过 quorum 数量的 Sentinel 节点认为该 Redis 节点主观下线，则该 Redis 客观下线。

每 1s 每个 Sentinel 对其他 Sentinel 和 Redis 执行 ping，进行心跳检测。

每 2s 每个 Sentinel 通过 Master 的 Channel 交换信息(pub - sub)。

每 10s 每个 Sentinel 对 Master 和 Slave 执行 info，目的是发现 Slave 节点、确定主从关系。

• LRU、LFU、FIFO 算法自动清除：一致性最差，维护成本低。

Martin 认为 Redlock 实在不是一个好的选择，对于需求性能的分布式锁应用它太重了且成本高；对于需求正确性的应用来说它不够安全。因为它对高危的时钟或者说其他上述列举的情况进行了不可靠的假设，如果你的应用只需要高性能的分布式锁不要求多高的正确性，那么单节点 Redis 够了；如果你的应用想要保住正确性，那么不建议 Redlock，建议使用一个合适的一致性协调系统，例如 Zookeeper，且保证存在 fencing token。

SDS（Simple Dynamic Strings, 简单动态字符串）是 Redis 的一种基本数据结构，主要是用于存储字符串和整数

redis哈希槽分区：1.哈希取余；2.一致性哈希分区（环 【0，2的32次方-1服务器ip地址hash均匀的放在环中，顺时针】）；3.哈希槽分区2的16次方-1 （16383）

ZAB协议
redlock锁 多个加锁 过半成功则成功