1. 缓存

2. 共享Session

3. 消息队列系统

4. 分布式锁

因为 cpu 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现，而且 cpu 又不会成为瓶颈，那就顺理成章地采用单线程的方案了。 可以避免多线程上下文切换。

1. String字符串:字符串类型是 Redis 最基础的数据结构，首先键都是字符串类型， Value 不仅是 String，也可以是数字。常用在缓存、计数、共享Session、限速等。

2. Hash哈希:在Redis中，哈希类型是指键值本身又是一个键值对结构，哈希可以用来存放用户信息，比如实现购物车。

3. List列表（双向链表）:列表（list）类型是用来存储多个有序的字符串。可以做简单的消息队列的功能。 数据结构：List 就是链表，可以用来当消息队列用。Redis 提供了 List 的 Push 和 Pop 操作，还提供了操作某一段的 API，可以直接查询或者删除某一段的元素。 实现方式：Redis List 的是实现是一个双向链表，既可以支持反向查找和遍历，更方便操作，不过带来了额外的内存开销。

4. Set集合：集合（set）类型也是用来保存多个的字符串元素，集合是通过 hashtable 实现的。 但和列表类型不一样的是，集合中不允许有重复元素，并且集合中的元素是无序的，不能通过索引下标获取元素。利用 Set 的交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

5. Sorted Set有序集合（跳表实现）：Sorted Set 多了一个权重参数 Score，集合中的元素能够按 Score 进行排列。实现方式：Redis Sorted Set 的内部使用 HashMap 和跳跃表（skipList）来保证数据的存储和有序，HashMap 里放的是成员到 Score 的映射。

1. 新写入操作会报错。（Redis 默认策略）

2. 在键空间中，移除最近最少使用的 Key。（LRU推荐使用）

3. 在键空间中，随机移除某个 Key。

4. 在设置了过期时间的键空间中，移除最近最少使用的 Key。这种情况一般是把 Redis 既当缓存，又做持久化存储的时候才用。

5. 在设置了过期时间的键空间中，随机移除某个 Key。

6. 在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除。

传统的LRU是使用栈的形式，每次都将最新使用的移入栈顶，但是用栈的形式会导致执行select *的时候大量非热点数据占领头部数据，所以需要改进。Redis每次按key获取一个值的时候，都会更新value中的lru字段为当前秒级别的时间戳。Redis初始的实现算法很简单，随机从dict中取出五个key,淘汰一个lru字段值最小的。在3.0的时候，又改进了一版算法，首先第一次随机选取的key都会放入一个pool中(pool的大小为16),pool中的key是按lru大小顺序排列的。接下来每次随机选取的keylru值必须小于pool中最小的lru才会继续放入，直到将pool放满。放满之后，每次如果有新的key需要放入，需要将pool中lru最大的一个key取出。淘汰的时候，直接从pool中选取一个lru最小的值然后将其淘汰。

- RDB：快照形式是直接把内存中的数据保存到一个dump的文件中，定时保存，保存策略。 当Redis需要做持久化时，Redis会fork一个子进程，子进程将数据写到磁盘上一个临时RDB文件中。当子进程完成写临时文件后，将原来的RDB替换掉。

- AOF：把所有的对Redis的服务器进行修改的命令都存到一个文件里，命令的集合。 使用AOF做持久化，每一个写命令都通过write函数追加到appendonly.aof中。aof的默认策略是每秒钟fsync一次，在这种配置下，就算发生故障停机，也最多丢失一秒钟的数据。 缺点是对于相同的数据集来说，AOF的文件体积通常要大于RDB文件的体积。根据所使用的fsync策略，AOF的速度可能会慢于RDB。 Redis默认是快照RDB的持久化方式。对于主从同步来说，主从刚刚连接的时候，进行全量同步（RDB）；全同步结束后，进行增量同步(AOF)。

- AOF 可以更好的保护 数据不丢失，一般 AOF 会每隔 1 秒，最多丢失 1 秒钟的数据。

- 写入性能非常高，而且文件不容易破损

- **适合做灾难性的误删除的紧急恢复**。

如果能承受分钟内的数据丢失，且追求大数据集的恢复速度选用RDB，RDB 非常适合灾难恢复。

分布式环境下非常容易出现缓存和数据库间数据一致性问题，针对这一点，如果项目对缓存的要求是强一致性的，那么就不要使用缓存。

我们只能采取合适的策略来降低缓存和数据库间数据不一致的概率，而无法保证两者间的强一致性。

- 缓存失败时增加重试机制。

在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会再同一时间大面积失效。如果 Redis 是集群部署，将热点数据均匀分布在不同的 Redis 库中也能避免全部失效。或者设置热点数据永不过期，有更新操作就更新缓存就好了

**布隆过滤器（Bloom Filter）**这个也能很好的预防缓存穿透的发生，就是利用高效的数据结构和算法快速判断出你这个Key是否在数据库中存在，不存在你return就好了，存在你就去查DB刷新KV再return

解决：设置热点数据永不过期，或者加上个锁就搞定了。

缓存和数据库数据一致性问题

**作用：**

读写分离：master写、slave读，提高服务器的读写负载能力

负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量

故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复

数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式

高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

**过程：**

- 从节点执行 **slaveof IP，port** 发送指令

- 主节点响应

- 从节点保存主节点信息（IP，port），建立和主节点的 Socket 连接。

- 从节点发送 Ping 信号，主节点返回 Pong，确定两边能互相通信。

- 连接建立后，主节点将所有数据发送给从节点（数据同步）。

- 主节点把当前的数据同步给从节点后，便完成了复制的建立过程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

**复制/数据同步过程分为两个阶段**

1. 全量复制：

slave接收到master生成的RDB文件，先清空自身的旧数据，然后执行RDB恢复过程，然后告知master已经恢复完毕。

2. 部分复制（增量复制）

主节点发送数据给从节点过程中，主节点还会进行一些写操作，这时候的数据存储在复制缓冲区中。master把自己之前创建的复制缓冲区的数据发送到slave，slave接收到aof指令后执行重写操作，恢复数据。

**主从复制会存在以下问题：**

- 一旦主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。

- 主节点的写能力受到单机的限制。

- 主节点的存储能力受到单机的限制。

**哨兵：**

哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。

**作用：**

**监控**

不断的检查master和slave是否正常运行。

master存活检测、master与slave运行情况检测

**通知（提醒）**

当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。

**自动故障转移**

断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址