Redis

Redis

1、概念

Redis是一个开源的、内存数据结构存储，用作数据库、缓存和消息代理。Redis提供数据结构，如字符串、散列、列表、集、带有范围查询的排序集、位图、超日志、地理空间索引和流。

2、特点

Redis 与其他 key - value 缓存产品有以下三个特点：

• Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
• Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
• Redis支持数据的备份，即master-slave模式的数据备份。

Redis与其他key-value存储有什么不同？

Redis有着更为复杂的数据结构（set，list，tuple）并且提供对他们的原子性（一个事务是一个不可分割的最小工作单位,要么都成功要么都失败）操作，这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明，无需进行额外的抽象。
Redis运行在内存中但是可以持久化（RDS，AOF）到磁盘，所以在对不同数据集进行高速读写时需要权衡内存，因为数据量不能大于硬件内存。在内存数据库方面的另一个优点是，相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样Redis可以做很多内部复杂性很强的事情。同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，因为他们并不需要进行随机访问。

3、优势

• 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s （单线程）。
• 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
• 原子 – Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。
• 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

4、持久化原理

redis主要有两种持久化的方式，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。

4.1 RDB

我们可以配置Redis的持久化策略，例如数据集中每N秒钟有超过M次更新，就将数据写入磁盘；或者可以手工调用命令SAVE或BGSAVE。
SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数，但它们调用的方式各有不同：

• SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
• BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。
• RDB持久化配置
  Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率

save 900 1             #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10           #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

过程

• Redis forks一个子进程
• 子进程开始将数据写到临时RDB文件中。
• 当子进程完成写RDB文件，用新文件替换老文件。
• 这种方式可以使Redis使用copy-on-write技术。
  

优缺点：
1、rds只有一个文件，一旦系统出现灾难性故障，我们可以非常容易的进行恢复
2、性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
3、系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失，由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

4.2 AOF

快照模式并不十分健壮，当系统停止，或者无意中Redis被kill掉，最后写入Redis的数据就会丢失。这对某些应用也许不是大问题，但对于要求高可靠性的应用来说，Redis就不是一个合适的选择
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，都以以文本的方式记录，可以打开文件看到详细的操作记录。

AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

• appendfsync always #每次有数据修改发生时都会写入AOF文件。
• appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
• appendfsync no #从不同步。高效但是数据不会被持久化。

优缺点：
1、由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。
2、对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

5、高效能原理

详细可见

Redis的高并发和快速原因
1.redis是基于内存的，内存的读写速度非常快；
2.redis是单线程的，省去了很多上下文切换（先把前一个任务的 CPU 上下文（也就是 CPU 寄存器和程序计数器）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。）线程的时间；
3.redis使用多路复用技术，可以处理并发的连接。
为什么使用单线程
由于redis是基于内存的，cpu不会成为其瓶劲，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

6、集群

就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。

Redis需要集群的原因

• 防止单点故障，一个机器宕机，服务就用不了
• 提高读写能力

6.1 主从复制

主从复制模型中，有多个redis节点。 其中，有且仅有一个为主节点Master。从节点Slave可以有多个。只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。其中master提供读写，slave只提供读，这样间接提高了master的写能力

6.2 哨兵模式

当主节点宕机了，整个集群就没有可写的节点了。由于从节点上备份了主节点的所有数据，那在主节点宕机的情况下，如果能够将从节点变成一个主节点，是不是就可以解决这个问题了呢？这个就是Sentinel哨兵的作用。

哨兵作用

• 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
• 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会进行选举，将其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

1、监控

一个Sentine可以监控一个或者多个master（各个集群相互独立）及master下面的所有slave，会定期检查master和slave的健康情况。其中监控同一个master的sentine之间也有联系，他们之间组成一个sentine网络（当只有一个sentinel的时候，如果这个sentinel挂掉了，那么就无法实现自动故障切换），在sentinel网络中，只要还有一个sentinel活着，就可以实现故障切换。

2、故障切换

（1）投票（半数原则）
当任何一个Sentinel发现被监控的Master下线时，会通知其它的Sentinel开会，投票确定该Master是否下线（半数以上，所以sentinel通常配奇数个）。
（2）选举
当Sentinel确定Master下线后，会在所有的Slaves中，选举一个新的节点，升级成Master节点。
其它Slaves节点，转为该节点的从节点。
（3）原Master重新上线
当原Master节点重新上线后，自动转为当前Master节点的从节点。

6.3 Redis Cluster

哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，集群会需要十几秒甚至几十秒的时间用于判断主节点下线，并选举一个从节点成为新的主节点。
Redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置简单。高可用集群相较于哨兵集群，至少不会出现主节点下线后，整个集群在一段时间内处于不可用状态，直到选举出主节点。因为高可用集群有多个主节点，当我们需要向整个Redis服务写入大批量数据时，数据会根据写入的key算出一个hash值，将数据落地到不同的主节点上，所以当一个主节点下线后，落地到其他主节点的写请求还是正常的。

Redis集群节点间的通信机制

Redis Cluster节点间采取gossip协议进行通信，维护集群的元数据(集群节点信息，主从角色，节点数量，各节点共享的数据等)有两种方式：集中式和gossip