Redis非关系型数据库

Redis

  Redis是一个使用C语言编写的、开源的高性能非关系型NoSQL键值对数据库。

  Redis 可以存储键和五种不同类型的值之间的映射，键的类型只能为字符串String，值支持五种数据类型：String字符串、List列表、Set集合、Hash散列表、ZSet有序集合。

  与传统数据库不同，Redis的数据是存在内存中，所以读写速度非常快，因此被广泛用于缓存方向，每秒可以处理超过10万次读写操作，另外Redis 也经常用来做分布式锁。

1、Redis优缺点

优点：

• 读写性能优异，Redis读的速度是110000次/s，写的速度是81000次/s。
• 支持数据持久化、支持AOF和RDB两种持久化方式。
• 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
• 数据结构丰富，除了支持String类型的Value外还支持hash、set、zset、list等数据结构。
• 支持主从复制、主机会自动将数据同步到从机，可以支持读写分离。

缺点：

• 数据库容量收到物理内存的限制，不能用作海量数据的高性能读写。

• Redis 不具备自动容错和回复功能，主机从机的宕机会导致前端读写部分失败。

• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂，后期运维较为麻烦。

2、持久化

  持久化：将内存中的数据持久化到磁盘当中，防止服务器宕机了内存数据丢失。

  持久化机制：RDB (默认)、AOF

RDB 快照持久化 (默认)

  RDB是Redis默认的数据持久化方式，按照一定的时间将内存的数据以快照的形式保存到硬盘当中，产生的数据文件为 dump.rdb。可以通过配置文件中的save参数来定义快照的周期。

优点：

• 只有一个文件dump.rdb，方便持久化。
• 容灾性好，一个文件可以保存到安全的磁盘。
• 性能最大化，可以fork一个子进程来完成写操作，让主进程继续处理指令，保证了Redis的高性能。
• 相对于数据集比较大时，比AOF的启动回复效率要高。

缺点：

• 数据安全性低，RDB是间隔一段时间进行持久化，如果持久化间隔时间中Redis发生故障，会发生数据丢失，所以更适合保存不是很严谨的数据。

AOF 指令持久化

  AOF： 将Redis执行的每次写操作指令以Redis命令单独记录到日志文件为 .aof文件，当重启Redis会重新将持久化的日志文件中回复数据。

  当两种方式同时开启时，数据回复会优先选择 AOF方式。

优点：

• 数据安全，AOF持久化可以配置appendfsync属性，没进行一次写操作就记录到aof文件中一次。
• 通过append模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
• AOF机制的rewrite模式：文件过大时会对命名进行合并重写，当aof文件没被rewrite之前，可以删除其中的某些误操作的命名。

缺点：

• AOF 文件比RDB文件大，且回复速度慢。
• 数据集较大的时候，比RDB启动回复效率低。

  一般来说，最好同时使用两种持久化方式，会优先载入AOF文件回复原始数据，通常情况下AOF保存的数据要比RDB完整一些。

  如果对数据要去不是很严谨，可以承受部分数据的丢失，那么就可以支持RDB。

  如果只支持AOF持久化，也不推荐，因为定时生成RDB快照非常便于进行数据库备份，而且RDB回复数据速度要快。

3、主从架构

  主从架构 (master-slave)，一主多从，主负责写操作，并且将数据复制到其他的Slave节点，从节点负责读操作，所有的读请求全部走从节点，这样也可以很轻松实现水平扩容，支撑读高并发。

  redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发

Redis replication机制

• Redis 采用异步方式复制数据到Slave节点，从2.8开始Slave node会周期性地确认自己每次复制的数据量。
• 一个Master node是可以配置多个Slave node的。
• Slave node也可以连接其他Slave node。
• Slave node在复制的时候，不会阻塞Master node的工作。
• Slave node在复制的时候，也不会阻塞自己的查询操作，它会用旧的数据集来提供服务，但是当复制完成需要删除旧的数据集，加载新数据集的时候会暂停对外的服务。

原理：

  当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node。

  如果这是 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，

  同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， master 会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中，

  接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。

  slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据。

• 当从库和主库建立MS关系后，会向主数据库发送SYNC命令
• 主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程)，并将期间接收到的写命令缓存起来
• 当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis
• 从Redis接收到后，会载入快照文件并且执行收到的缓存的命令
• 之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致

缺点：

  所有的Slave节点的复制和同步都是由Master节点来处理，会造成Master节点的压力太大。

4、哨兵模式

哨兵：Sentinel，是Redis集群架构中非常重要的一个组件。

• 集群监控：负责监控Redis Master和Slave进程是否正常工作。

• 消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息给系统管理员。

• 故障转移：如果某个Master node挂掉了，会自动通过分布选举机制判定，并转移到Slave node

• 配置中心：如果故障转移发生了，会通知Client客户端新的Master地址。

  

哨兵用于实现集群模式的高可用，本身也是分布式的，作为一个哨兵集群去运行，相互协同工作。

• 故障转移时，判断一个Master node是否宕机了，需要大部分的哨兵同意才行，涉及到了选举机制的问题。
• 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制的重要组成部分的故障转移系统本身还是一个单点的，那就非常坑了。

  哨兵至少需要三个实例，才能保持本身的健壮性。

  哨兵+主从部署架构，是不保存数据百分百不丢失的，只能保证Redis集群的高可用性。

  对于哨兵+主从部署架构，需要在测试环境和生产环境中充分的进行测试。