Redis原理

Redis（Remote Dictionary Server )，是一个开源的使用C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。

一、数据类型

Redis所有的数据结构都是以唯一的key字符串作为名称，然后通过这个唯一key值来获取相应的value数据。

Redis提供丰富多样的数据类型：string、 hash、 set、 sorted set、bitmap、hyperloglog

1.1 string类型

string 类型是 Redis 中最基本的数据类型，最常用的数据类型。

string 类型支持任何格式的字符串，应用最多的就是存储 json 或其他对象格式化的字符串。

string 类型的值为整数形式时，redis 可以把它当做是整数一样进行自增（incr）自减（decr）操作。

示例表名：user

set user:id:1001:email 123456@qq.com
set user:id:1002:email 123457@qq.com

key值分段设计法：key设计为 表名:主键名:主键值:字段名

string 类型应用场景：

• 存储 MySQL 中某个字段的值。
• 存储对象。
• 生成自增id。

1.2 hash 类型

hash 类型很像一个关系型数据库的数据表，hash 的 Key 是一个唯一值，Value 部分是一个 hashmap 的结构。

示例表名：user

hmset user:1001 name aa email 123456@qq.com
hmset user:1002 name bb email 123457@qq.com

 

hash 类型应用场景：

• hash 类型十分适合存储对象类数据。

1.3 list类型

list 是按照插入顺序排序的字符串链表，可以在头部和尾部插入新的元素（双向链表实现，两端添加元素的时间复杂度为 O(1)）。

list 类型应用场景：

• 消息队列：list 数据类型是实现队列服务的最经济，最简单的方式。

• 最新内容：list 结构的数据查询两端附近的数据性能非常好，所以适合一些需要获取最新数据的场景，比如新闻类应用的 “最近新闻”。

1.4 set类型

set 类型是一个集合（没有排序，不重复）。

sadd user:wade james melo paul kobe
sadd user:james wade melo paul kobe
sadd user:paul wade james melo kobe
sadd user:melo wade james paul kobe

set 类型应用场景：

• 共同好友列表：社交类应用中，获取两个人或多个人的共同好友，两个人或多个人共同关注的微博这样类似的功能。

1.5 sorted set类型

sorted set类型：在 set 的基础上给集合中每个元素关联了一个分数，往有序集合中插入数据时会自动根据这个分数排序。

zadd user:kobe 80 james 90 wade  85 melo  90 paul

 

sorted set类型应用场景：

• 在集合类型的场景上加入排序就是有序集合的应用场景了。比如根据好友的“亲密度”排序显示好友列表。

二、集群模式

2.1 主从模式

?

主从模式特点：

• 主数据库可读写操作，自动将变更数据同步给从数据库。
• 从数据库只读，并且接收主数据库同步过来的数据。
• 一个master可以拥有多个slave，但是一个slave只能对应一个master。
• master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务。
• master挂了以后，不会在slave节点中重新选一个master。

2.2 Sentinel模式

?

Sentinel模式特点：

• sentinel模式是建立在主从模式的基础上。
• master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master。
• 当master重新启动后，它将不再是master而是做为slave接收新的master的同步数据。
• 一个sentinel或sentinel集群可以管理多个主从Redis，sentinel之间也会自动监控。

2.3 集群模式

?

cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

集群模式特点：

• 多个redis节点网络互联，数据共享。
• 所有的节点都是一主一从（也可以是一主多从），其中从不提供服务，仅作为备用。
• 不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为。
• 支持在线增加、删除节点。
• 客户端可以连接任何一个主节点进行读写。

三、持久化机制

Redis提供了持久化的机制，分别是RDB(Redis DataBase)和AOF(Append Only File)。

3.1 持久化流程

1. 客户端向服务端发送写操作(数据在客户端的内存中)。
2. 服务端接收到写请求的数据(数据在服务端的内存中)。
3. 服务端调用write这个系统调用，将数据往磁盘上写(数据在系统内存的缓冲区中)。
4. 操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。
5. 磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。

3.2 RDB机制

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘（默认的持久化方式），文件名为dump.rdb。

RDB三种触发机制：

• save方式：该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。
• bgsave方式：执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
• 自动方式：自动触发是由我们的配置文件来完成的。

?

?

RDB优点：

• RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
• 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB缺点：

• 在快照持久化期间修改的数据不会被保存，可能丢失数据。

3.3 AOF机制

AOF：redis将每一个收到的写命令都通过write函数追加到AOF文件中，通俗的理解就是日志记录。

AOF文件过大会执行bgrewriteaof命令，将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。

?

?

AOF三种触发机制：

• always：实时同步，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。
• everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失。
• no：从不同步

AOF优点：

• AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
• AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
• AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
• AOF日志文件的命令通过非常可读的方式进行记录，适合做灾难性的误删除的紧急恢复。

AOF缺点：

• 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
• AOF开启后，AOF TPS会比RDB TPS低。

Redis原理

原文：https://www.cnblogs.com/linwenhai/p/14619018.html