Redis

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker.

NoSQL概述

为什么要用NoSQL

1. 单机MySQL的时代

graph LR
    APP --> DAL
    DAL --> MySQL

90年代，网站访问量一般不会很大，单个数据库完全足够，多数为静态网页，所以服务器无太大压力

这种情况下，整个网站的瓶颈是：

• 数据量如果太大，一个机器放不下
• 数据的索引(B+ Tree)，一个机器内存也放不下
• 访问量（读写混合），一个服务器承受不了

2. Memcached（缓存） + MySQL + 垂直拆分（读写分离）

graph LR
    APP --> DAL
    DAL --> Cache
    Cache --> MySQL1
    MySQL1 --> |同步|MySQL2写内容
    Cache --> MySQL2写内容
    Cache --> MySQL3
    MySQL3 --> |同步|MySQL2写内容

网站80%的情况都是在读，每次都要去查询数据库的话就十分麻烦，所以我们希望减轻数据库的压力，可以使用缓存来保证效率

发现过程：优化数据结构和索引 --> 文件缓存(I/O) --> Memcached（当时最热门的技术）

有了缓存，数据库的读的问题得到了很大的解决

3. 分库分表 + 水平拆分 + MySQL集群

慢慢地开始使用分库分表来解决数据库的写的压力，MySQL集群，很好的满足了当时那个年代的需求

4. 当今年代

2010-2020这十年之间，世界已经发生了翻天覆地的变化，例如现在的手机定位，音乐，热榜都在每天实时快速动态刷新。由于数据量很多，变化很快，MySQL等关系型数据库就不够用了。MySQL有的使用它来存储一些较大的文件，例如博客，图片，数据库表很大，效率就低了。在大数据的I/O压力下，表的结构几乎没法更改（例如有1亿的表中再加一列）

回到最初的问题，为什么要用NoSQL？

由于用户的信息，社交网络，地理位置，用户自己产生的数据，用户日志等待爆发式增长，这时候我们就需要NoSQL数据库，NoSQL可以很好的处理以上情况。

什么是NoSQL

NoSQL(NoSQL = Not Only SQL )，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在处理web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。

很多的数据类型用户的个人信息，社交网络，地理位置，这些数据类型的储存不需要一个固定的格式，不需要多余的扩展就可以横向扩展（Map<String, Object>），使用键值对来控制。

NoSQL特点

1. 方便扩展（数据之间没有关系，很好扩展）
2. 大数据量，高性能（Redis一秒可以写8万次，读取11万次，NoSQL的缓存记录级，是一种细粒度的缓存，性能会比较高）
3. 数据类型是多样性的（不需要事先设计数据库，随去随用，如果是数据量很大的表，很多人就无法设计了）

传统RDBMS和NoSQL对比：

传统的RDBMS：

• 结构化组织
• SQL
• 数据和关系都存在单独的表中
• 数据操作语言，数据定义语言
• 严格的一致性
• 基础的事务

NoSQL：

• 不仅仅是数据
• 没有固定的查询语言
• 键值对存储，列存储，文档存储，图形数据库（社交关系）
• 最终一致性
• CAP定理和BASE（异地多活）
• 高性能，高可用，高可扩

大数据时代的3V：主要是描述问题的

1. 海量(Volume)
2. 多样(Variety)
3. 实时(Velocity)

大数据时代的3高：主要是对程序的要求

1. 高并发
2. 高可扩（随时水平拆分，机器不够用可以加一台服务器解决）
3. 高性能

真正在公司中的实践是：NoSQL + RDBMS一起使用

NoSQL的四大分类

KV键值对：

• 新浪：Redis
• 美团：Redis + Tair
• 阿里巴巴，百度：Redis + Memcached

文档型数据库(bson格式)：

• MongoDB：它是一个基于分布式文件存储的数据库，C++编写，主要用来处理大量的文档；它还是一个介于关系型数据库和非关系型数据库中间的产品；MongoDB是非关系型数据库中功能最丰富，最想关系型数据库的
• ConthDB

列存储数据库：

• HBase
• 分布式文件系统

图关系数据库：

• Neo4j
• InfoGrid

Redis概述

Redis是什么

Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

免费和开源，是当下最热门的NoSQL技术之一，也被人们称之为结构化数据库。

Redis能干什么

1. 内存存储，持久化。由于内存中是断电即失，所以说持久化很重要(rdb, aof)
2. 效率高，可以用于告诉缓存
3. 发布订阅系统
4. 地图信息分析
5. 计时器，计数器（浏览量）
6. $\cdots$

Redis的特性

1. 多样的数据类型
2. 持久化
3. 支持集群
4. 支持事务
5. $\cdots$

Redis的基础知识

redis默认有16个数据库，默认使用的是第0个数据库

可以使用select进行切换数据库

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 切换至第三个数据库
select 3

# 查看DB大小
DBSIZE

# 查看DB所有的key
keys *

# 清空当前数据库
flushdb

# 清空所有数据库
FLUSHALL

redis是基于内存操作，CPU不是redis性能瓶颈，redis的瓶颈是根据机器的内存和网络带宽，既然可以用单线程来实现，就使用单线程了。

redis是C语言写的，官方提供的数据为100000+的每秒查询率(QPS)，完全不比同样是使用key-value的Memcache差

Redis为什么单线程还这么快？

• 误区1：高性能的服务器一定是多线程的
• 误区2：多线程（CPU上下文会切换，消耗资源）一定比单线程效率高

redis是将所有的数据全部放在内存中的，所以说使用单线程去操作效率就是最高的，多线程（CPU上下文会切换；耗时的操作！！），对于内存系统来说，如果没有上下文切换，效率就是最高的。多从读写都是在一个CPU上的，在内存情况下，这个就是最佳的方案

五大数据类型

Redis是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件MQ。

它支持多种类型的数据结构，如字符串（strings），散列（hashes），列表（lists），集合（sets），有序集合（sorted sets）与范围查询， bitmaps，hyperloglogs和地理空间（geospatial）索引半径查询。

Redis内置了复制（replication），LUA脚本（Lua scripting），LRU驱动事件（LRU eviction），事务（transactions）和不同级别的磁盘持久化（persistence），并通过 Redis哨兵（Sentinel）和自动分区（Cluster）提供高可用性（high availability）。

Redis中常用命令

String(字符串)

string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象。

string类型是Redis最基本的数据类型，string类型的值最大能存储 512MB。

String类似的使用场景：value除了字符串还可以是数字！

• 计数器
• 统计多单位的数量
• 分数数
• 对象缓存存储

List(列表)

Redis列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

list类型经常会被用于消息队列的服务，以完成多程序之间的消息交换。

常用命令：lpush、rpush、lpop、rpop、lrange等。

列表最多可存储 $2^{32} - 1$ 元素(4294967295，每个列表可存储40多亿)。

总结：

• 实际上是一个链表，before Node after，左右都可以插入值
• 如果key不存在，创建新的链表
• 如果key存在，新增内容
• 如果移除了所有值，为空链表，代表不存在
• 在两边插入或改动值，效率最高，中间元素，相对来说效率会低一些
• 既可以作为消息队列（Lpush Rpop），也可以作为栈（Lpush Lpop）

Set(集合)

Redis的Set是String类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。

Redis中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。

常用命令：sadd、spop、smembers、sunion等。

集合中最大的成员数为 $2^{32} - 1$ (4294967295, 每个集合可存储40多亿个成员)。

应用场景：

1. 利用交集求共同好友。
2. 利用唯一性，可以统计访问网站的所有独立IP。
3. 好友推荐的时候根据tag求交集，大于某个threshold（临界值的）就可以推荐。

Hash(哈希)

Redis hash是一个string类型的field（字段）和value（值）的映射表，hash特别适合用于存储对象。类似于java的HashMap。

常用命令：hget、hset、hgetall等。

Redis中每个hash可以存储 $2^{32} - 1$ 键值对（40多亿）。

应用场景：

1. 存储一些结构化的数据，比如用户的昵称、年龄、性别、积分等，存储一个用户信息对象数据。

Hash更适合与对象的存储，而String更加适合字符串的存储

Zset(有序集合)

Redis zset和set一样也是string类型元素的集合，且不允许重复的成员。

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

zset的成员是唯一的，但分数(score)却可以重复。

sorted set是插入有序的，即自动排序。

常用命令：zadd、zrange、zrem、zcard等。

当你需要一个有序的并且不重复的集合列表时，那么可以选择sorted set数据结构。

应用举例：

1. 例如存储全班同学的成绩，其集合value可以是同学的学号，而score就可以是成绩。
2. 排行榜应用，根据得分列出topN的用户等。
3. 普通消息，重要消息带权重进行判断

三种特殊数据类型

Geospatial(地理位置)

Redis在3.2版本中加入了地理空间(geospatial)以及索引半径查询的功能。

主要用在需要地理位置的应用上，将指定的地理空间位置（纬度、经度、名称）添加到指定的key中。这些数据将会存储到sorted set这样的目的是为了方便使用GEORADIUS或者GEORADIUSBYMEMBER命令对数据进行半径查询等操作

GEO底层的实习原理其实就是Zset！也可以使用zset命令来操作geo

geoadd

geoadd：添加地理位置

1

GEOADD key longitude latitude member [longitude latitude member ...]

功能说明: 将指定的地理空间位置（纬度、经度、名称）添加到指定的key中。这些数据将会存储到sorted set这样的目的是为了方便使用GEORADIUS或者GEORADIUSBYMEMBER命令对数据进行半径查询等操作

时间复杂度：每一个元素添加是O(log(N)) ，N是sorted set的元素数量

注意：

• 有效的经度从-180度到180度。
• 有效的纬度从-85.05112878度到85.05112878度。

当坐标位置超出上述指定范围时，该命令将会返回一个错误

geopos

geopos：获取指定城市的地理位置经纬

从key里返回所有给定位置元素的位置（经度和纬度）

1

GEOPOS key member [member ...]

geodist

geodist：返回两个坐标之间的距离

返回两个给定位置之间的距离。如果两个位置之间的其中一个不存在，那么命令返回空值。

1

GEODIST key member1 member2 [unit]

指定单位的参数unit必须是以下单位的其中一个：

• m 表示单位为米。
• km 表示单位为千米。
• mi 表示单位为英里。
• ft 表示单位为英尺。

如果用户没有显式地指定单位参数，那么GEODIST默认使用米作为单位。

GEODIST命令在计算距离时会假设地球为完美的球形，在极限情况下，这一假设最大会造成0.5%的误差。

georadius

georadius：获得所有附近的人的地址,定位 通过半径来查询

以给定的经纬度为中心，返回键包含的位置元素当中，与中心的距离不超过给定最大距离的所有位置元素。

1

GEORADIUS key longitude latitude radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count]

在给定以下可选项时，命令会返回额外的信息：

• WITHDIST: 在返回位置元素的同时，将位置元素与中心之间的距离也一并返回。距离的单位和用户给定的范围单位保持一致。
• WITHCOORD: 将位置元素的经度和维度也一并返回。
• WITHHASH: 以52位有符号整数的形式，返回位置元素经过原始geohash编码的有序集合分值。这个选项主要用于底层应用或者调试，实际中的作用并不大。

georadiusbymember

georadiusbymember：找出位于指定元素周围的其他元素

1

GEORADIUSBYMEMBER key member radius m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count]

这个命令和GEORADIUS命令一样，都可以找出位于指定范围内的元素，但是GEORADIUSBYMEMBER的中心点是由给定的位置元素决定的，而不是像GEORADIUS那样，使用输入的经度和纬度来决定中心点

指定成员的位置被用作查询的中心。

geohash

geohash：将二维的经纬度转换为一维的字符串

1

GEOHASH key member [member ...]

该命令将返回11个字符的geohash字符串

Hyperloglog

Redis在2.8.9版本添加了HyperLogLog结构。

Redis HyperLogLog是用来做基数统计的算法，HyperLogLog的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的，并且是很小的。

例如网页的浏览数，一个人访问一个网站多次，但是还是算作一个人。传统的方式，set保存用户的id，然后就可以统计set中的元素数量作为标准判断。这个方式如果保存大量的用户id，就会比较麻烦，我们的目的是为了计数，而不是保存用户id。

如果允许容错，那么一定可以使用Hyperloglog；如果不允许容错，就使用set或者自己的数据类型即可。

Bitmap

就是通过一个bit位来表示某个元素对应的值或者状态,其中的key就是对应元素本身。我们知道8个bit可以组成一个Byte，所以bitmap本身会极大的节省储存空间。

Bitmap可以用来统计用户信息，活跃与不活跃用户，登陆与未登录用户，打卡与365天打卡等等，两个状态的都可以用Bitmap来记录。

setbit

1
2

# 设置或者清空key的value(字符串)在offset处的bit值(只能只0或者1)
SETBIT key offset value

getbit

1
2

# 对 key 所储存的字符串值，获取指定偏移量上的位(bit)
GETBIT key offset

• 返回值：字符串值指定偏移量上的位(bit)。当偏移量OFFSET比字符串值的长度大，或者key不存在时，返回0

bitcount

1
2

# 计算给定key的字符串值中，被设置为 1 的比特位的数量
BITCOUNT key [start] [end]

• 不存在的key被当成是空字符串来处理，因此对一个不存在的key进行BITCOUNT操作，结果为0
• 返回值：1比特位的数量

Redis基本事务操作

redis事务本质：一组命令的集合！一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行！一次性，顺序性，排他性，执行一系列的命令

1

------- 队列 set set set 执行 -------

Redis事务没有隔离级别的概念！所有的命令在事务中并没有直接被执行！只有发起执行命令的时候才会执行！

Redis单条命令是保证原子性的，但是它的事务不保证原子性！

redis的事务有三个阶段：

1. 开启事务(multi)
2. 命令入队(…)
3. 执行事务(exec)

正常执行事务

放弃事务

编译型异常

即代码有问题，命令有错。事务中所有的命令都不会被执行！

运行时异常

如果事务队列中存在语法型错误（例如除数为0），那么执行命令的时候，其他命令是可以执行的，错误命令抛出异常

Redis监控(实现乐观锁)

• 悲观锁：很悲观，认为什么时候都会出问题，无论做什么都会加锁
• 乐观锁：很乐观，认为什么时候都不会出问题，所以不会上锁。更新数据的时候去判断一下，在此期间是否有人修改过这个数据

在Redis中使用watch命令可以决定事务是执行还是回滚。一般而言，可以在multi命令之前使用watch命令监控某些键值对，然后使用multi命令开启事务，执行各类对数据结构进行操作的命令，这个时候这些命令就会进入队列。

当Redis使用exec命令执行事务的时候，它首先会去比对被watch命令所监控的键值对，如果没有发生变化，那么它会执行事务队列中的命令，提交事务；如果发生变化，那么它不会执行任何事务中的命令，而去事务回滚。无论事务是否回滚，Redis都会去取消执行事务前的watch命令，这个过程如下图所示：

使用watch可以当作redis的乐观锁操作！

Redis.conf详解

INCLUDES

可以把多个配置文件都导入进来

NETWORK(网络)

1
2
3

bind node1  # 绑定的ip
protected-mode yes   # 保护模式 默认开启
port 6379 # 端口设置

GENERAL(通用)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

daemonize yes # 以守护进程的方式运行 默认no  我们需要手动修改yes ！

pidfile /var/run/redis_6379.pid # 如果以后台的方式运行，我们就需要指定一个pid文件

# 日志
# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)  # 生产环境用
# warning (only very important / critical messages are logged)
loglevel notice
logfile "" # 日志的文件位置名
databases 16 # 数据库数量，默认16个
always-show-logo yes  # 是否总是显示logo  那个魔方一样的

SNAPSHOTTING(快照)

持久化，在规定的时间内，执行了多少次操作，就会持久化到文件(.rdb.aof)

redis是内存数据库，如果没有持久化，那么数据断电即失。

1
2
3
4
5
6
7
8
9
10
11
12

save 900 1  # 如果900秒15分钟内 至少1个key修改 我们就进行持久化操作
save 300 10 # 如果300秒5分钟内 至少10个key修改 我们就 进行持久化操作
save 60 10000 # 如果60秒内 至少10000个key修改(高迸发) 进行持久化操作
# 我们之后学习持久化，会自己定义这个测试

stop-writes-on-bgsave-error yes # 持久化出错了，是否还要继续工作，默认 要！

rdbcompression yes # 是否压缩rdb文件，需要消耗cpu资源

rdbchecksum yes # 保存reb文件的时候，进行错误校验，错误的话修复

dir ./ # rdb文件保存的目录，默认当前目录下

REPLICATION(复制)

详情见后面的主从复制

SECURITY(安全)

可以在这里设置redis密码，默认是没有密码的

1

requirepass foobared  # 默认密码为空 如果需要设置123则:requirepass 123  

通常通过指令设置：

1
2
3
4
5
6
7
8
9
10
11

node1:6379> config set requirepass "123456" # 设置密码123456
OK
node1:6379> config get requirepass  # 发现所有命令没权限了
(error) NOAUTH Authentication required.
node1:6379> ping
(error) NOAUTH Authentication required.
node1:6379> auth 123456  # 使用密码进行登陆
OK
node1:6379> config get requirepass  # 获取redis密码
1) "requirepass"
2) "123456"

CLIENTS(限制)

1
2
3
4
5
6
7
8
9
10

maxclients 10000 # 设置能连接上redis的最大客户端的数量
maaxmemory <bytes> # redis 配置最大的内存容量
maxmemory-policy noeviction # 内存达到上限之后的处理策略
||
1、volatile-lru：只对设置了过期时间的key进行LRU（默认值） 
2、allkeys-lru ： 删除lru算法的key   
3、volatile-random：随机删除即将过期key   
4、allkeys-random：随机删除   
5、volatile-ttl ： 删除即将过期的
6、noeviction ： 永不过期，返回错误

APPEND ONLY MODE

aof配置，具体的配置在Redis持久化中说明

1
2
3
4
5
6

appendonly no  #默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用！
appendfilename "appendonly.aof"  # 持久化的文件的名字

# appendfsync always  # 每次修改都会 sync 消耗性能
appendfsync everysec  # 每秒执行一次 sync，可能会丢失这一秒的数据
# appendfsync no      # 不执行 sync 操作系统自己同步数据，速度最快，但一般也不用。

Redis持久化

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据状态也会消失，所以redis提供了持久化功能。幸好Redis还为我们提供了持久化的机制，分别是RDB(Redis DataBase)和AOF(Append Only File)

RDB(Redis DataBase)

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写到一个临时文件中，等待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是很敏感，那么RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化的数据，可能丢失。

我们默认的就是RDB，一般情况下不需要修改这个配置。RDB保存的文件是dump.rdb，在配置文件中配置的

触发机制：

1. save的规则满足的情况下，会自动触发rdb规则
2. 执行flushall命令，也会触发我们的rdb规则！
3. 退出redis，也会产生rdb文件！

备份就自动生成一个dump.rdb文件

如何恢复rdb文件：

1. 只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据！
2. 查看需要存在的位置

1
2
3

node1:6379> CONFIG GET dir
1) "dir" 
2) "/export/server/redis-3.2.8-bin/datas" # 如果在这个目录下存在dump.rdb文件，启动就会自动恢复其中的数据

优点：

1. 大规模的数据恢复
2. 对数据的完整性要不高！

缺点：

1. 需要一定的时间间隔进程操作！(当然你也可以自己去修改配置)。如果redis意外宕机了，这个最后一次修改数据就没有的了！
2. fork进程的时候，会占用一定的内存空间！

AOF(Append Only File)

全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。

以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作(万一是大数据就很慢)

Aof保存的是appendonly.aof文件

1

appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用！

一般的话，我们只要每秒保存即可

1
2
3

# appendfsync always
appendfsync everysec
# appendfsync no

是否要用append重写，默认no即可。aof默认就是文件的无限追加，文件会越来越大！

1
2
3
4

# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.
# 如果有延迟问题，请将此选项转换为“yes”。否则就让它保持原样 “no”从耐久性的角度来看，这是最安全的选择。
no-appendfsync-on-rewrite no

1
2

auto-aof-rewrite-percentage 100 # 重写的基准是100 增幅100%就重新覆盖一次
auto-aof-rewrite-min-size 64mb  # 最小值是64MB 

如果这个aof文件大于64M，太大了。fork一个新的进程来将文件进行重写！

aof机制默认是不开启的，我们要把他改成yes来开启。我们只需要将appendoly 改为yes就开启了aof！重启服务，shutdown再登录就可以生效了。

如果这个aof文件有错误，这时候redis是启动不起来的，我们需要修复这个aof文件，redis 给我们提供了一个工具redis-check-aof --fix

优点：

1. 每一次修复都同步，文件的完整会更好。
2. 每秒同步一次，可能会丢失一秒的数据。
3. 从不同步，效率最高的。

缺点：

1. 相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢！
2. Aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化！

Redis发布订阅

Redis发布订阅（pub/sub）是一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息。微信、微博、关注系统！Redis客户端可以订阅任意数量的频道。

订阅/发布消息图：

当有新消息通过PUBLISH命令发送给频道channel1时，这个消息就会被发送给订阅它的三个客户端：

发布订阅命令

这些命令被广泛用于构建即时通信应用，比如网络聊天室（chatroom）和实时广播、实时提醒等

发布订阅测试

1
2
3
4
5
6
7
8
9
10
11

# 订阅端
node1:6379> SUBSCRIBE tyokyo320  # 订阅1个频道，频道名tyokyo320
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "tyokyo320"
3) (integer) 1

# 等待读取推送信息
1) "message"      # 消息
2) "tyokyo320"    # 来自哪个频道
3) "hello world"  # 消息内容             

1
2
3

# 发布端
node1:6379> PUBLISH tyokyo320 "hello world" # 发布者发布消息"hello world" 到频道"tyokyo320"
(integer) 1

Redis发布订阅原理

Redis是使用C实现的，通过分析Redis源码里的pubsub.c文件，了解发布和订阅机制的底层实现，籍此加深对Redis的理解。

Redis通过PUBLISH、SUBSCRIBE和PSUBSCRIBE等命令实现发布和订阅功能。通过SUBSCRIBE命令订阅某频道后，redis-server里维护了一个字典，字典的键就是一个个channel(频道)，而字典的值则是一个链表，链表中保存了所有订阅这个channel的客户端。SUBSCRIBE命令的关键，就是将客户端添加到给定channel的订阅链表中。

通过PUBLISH命令向订阅者发送消息，redis-server会使用给定的频道作为键，在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者。

Pub/Sub从字面上理解就是发布（Publish）与订阅（Subscribe），在Redis中你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法是用作实时消息系统，比如普通的即时聊天，群聊等功能。

使用场景：

1. 实时消息系统
2. 实时聊天（频道当做聊天室，将消息回显给所有人即可）
3. 订阅、关注的系统都可以

稍微复杂的场景我们就会使用消息中间件MQ

Redis主从复制

主从复制的概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（master/leader)，后者称为从节点(slave/follower)；数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。

默认情况下，每台Redis服务器都是主节点(因为你还没有配置主从)；且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

主从复制的作用主要包括：

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4. 高可用(集群)基石：除了上述作用用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的(可能宕机，1主2从)，原因如下：

1. 从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大
2. 从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存。一般来说，单台Redis最大使用内存不应该超过20G

只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis！

环境配置（单机多集群）

只配置从库，不用配置主库

1
2
3
4
5
6
7
8

node1:6379> info replication  # 查看当前库的信息
# Replication
role:master         # 角色 master
connected_slaves:0  # 没有从机
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_o

接下来配置的是单机多集群，就是一台虚拟机上开多个窗口，实现多集群的意义，正常我们是应该配置多机多集群的，这样效果会好点。

复制3个配置文件，然后修改对应的信息

1. 端口
2. pid名字
3. log文件名字
4. dump.rdg名字

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 步骤：
# 在一台虚拟机上，克隆3个窗口，复制3份conf文件

[root@node1 redis-3.2.8-bin]  # cd /export/server/redis-3.2.8-bin
[root@node1 redis-3.2.8-bin]  # cp redis.conf redis79.conf 
[root@node1 redis-3.2.8-bin]  # cp redis.conf redis80.conf   
[root@node1 redis-3.2.8-bin]  # cp redis.conf redis81.conf  

命令：vim redis79.conf
port 6379     # 84行  端口这里不用改 本身这个文件就是79端口  
daemonize yes # 128行 后台运行 要yes
pidfile /var/run/redis_6379.pid # 150行 这里pidfile也没问题
logfile "/export/server/redis-3.2.8-bin/logs/redis6379.log" # 163行 logfile加上后缀6379
dbfilename dump6379.rdb # 236行 dump.rdb改成 dump6379.rdb 否则会重名

# 至此第一个就保存好了。
# 第二个文件对应的改成6380和6381

修改完毕之后，在三个窗口分别启动我们3个redis服务器，可以通过进程查看（注意我们是一台虚拟机的3个窗口上）

1
2
3
4
5
6
7
8
9
10
11

# 窗口1 
[root@node1 redis-3.2.8-bin]# redis-server redis79.conf 
[root@node1 redis-3.2.8-bin]# redis-cli -h node1 -p 6379

# 窗口2 
[root@node1 redis-3.2.8-bin]# redis-server redis80.conf 
[root@node1 redis-3.2.8-bin]# redis-cli -h node1 -p 6380

# 窗口3 
[root@node1 redis-3.2.8-bin]# redis-server redis81.conf 
[root@node1 redis-3.2.8-bin]# redis-cli -h node1 -p 6381

然后可以查看进程信息：

1

ps -ef | grep redis

一主二从模式

前面说过，默认情况下，每台redis服务器都是主节点。(因为你还没有配置主从)。一般情况下，我们只配置从机就可以了。
认老大，一主（用79），二从（用80和81）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 在从机中查看信息
node1:6380> SLAVEOF node1 6379 # SLAVEOF host 6379  找谁当自己的老大
OK
node1:6380> info replication 
# Replication
role:slave  # 当前角色的从机
master_host:node1  # 可以看到主机的信息
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:15
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

1
2
3
4
5
6
7
8
9
10
11
12

# 在主机中查看信息
node1:6379> info replication
# Replication
role:master
connected_slaves:2  # 多了从机的配置
slave0:ip=192.168.88.161,port=6380,state=online,offset=253,lag=1  
slave1:ip=192.168.88.161,port=6381,state=online,offset=253,lag=1
master_repl_offset:267
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:266

两个从机都配置完了就有2个从机的配置

真实的从主配置应该在配置文件中配置，这样的话是永久的，我们这里使用的是命令，是暂时的。

配置文件中找到replicaof <masterio> <masterport>和masterauth <master-password>即可

细节

需要注意的是：主机可以写；从机不能写只能读。主机中的所有信息和数据，都会自动被从机保存

尝试在从机中写会得到​ (error) READONLY You can’t write against a read only slave.的错误！

当主节点崩了的时候，就不能写了。但是你从节点还在，还能读！

• 这还不是真正的高可用！在没有配置哨兵模式的情况下，主机宕机了，从机还是salve状态，不会自动选举一个新的主机。
• 真正的高可用是：主机宕机了，在剩下的2台从机中，应该选出1台主机

命令行模式下：

• 主机宕机了，再登录回来，主机再次写入的信息，从机依旧可以读取到主机写的信息！
• 从机宕机了，再重新连接，默认是新的主机，拿不到原主机在断开期间写的数据。但是如果此时你再次连接主机变成从机，立马就可以获取主机的所有数据！

主从复制的原理

Slave启动成功连接master后会发送一个sync同步命令。

Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。

• 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中
• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步

但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。我们的数据一定可以在从机中看到。

层层链路模式

上面这种模式有个缺点，当6379主机Master挂了之后，整个集群就只能读，不能写了。

我们现在来想一个新的模式，让6381认6380做老大。即：上一个主节点，连接下一个从节点。这种情况下也可以的完成主从复制：

问题：如果6379老大断开了，这个时候能不能选择一个老大出来呢？

在哨兵模式没有出来之前，我们都是手动设置的。

如果主机断开了连接，我们可以使用SLAVEOF no one，来让自己变成主机！其他节点就可以手动连接到这个最新的节点（手动）！但是如果这个时候老大6379恢复了，也只是光杆司令了。除非手动让6380再次跟从6379.

哨兵模式(Sentinel)

概述

主从切换技术的方法是：当主服务器宕机后需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

Redis从2.8开始正式提提供了sentinel（哨兵）架构解决这个问题。它能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。

其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

哨兵模式文件：redis-sentinel

这里的哨兵有两个作用：

1. 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器
2. 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。

当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

测试

假设目前的状态是1主2从，首先配置哨兵配置文件。哨兵模式有非常多，我们只写一个最简单的。新建文件sentinel.conf

1
2

# 哨兵 | 监视 | 被监控名称:自定义 | host | port | 1代表主机挂了，slave投票看谁成为主机，票数最多的就会成为主机
sentinel monitor myredis 127.0.0.1 6379 1

然后启动哨兵

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

[root@node1 bin]# redis-sentinel ../sentinel.conf


27661:X 26 Nov 18:37:58.600 * Increased maximum number of open files to 10032 (it was originally set to 1024).
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 3.2.8 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 27661
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

27661:X 26 Nov 18:37:58.600 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
27661:X 26 Nov 18:37:58.601 # Sentinel ID is b289eec7e609a7cad25fcb5e9891931fc10afc15
27661:X 26 Nov 18:37:58.601 # +monitor master myredis 127.0.0.1 6379 quorum 1  # 当前监控主机是6379
27661:X 26 Nov 18:37:58.601 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379  # 从机是6381
27661:X 26 Nov 18:37:58.602 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379  # 从机是6380

如果Master节点断开了，这个时候就会从从机中随机选择一个服务器（这里面有一个投票算法）！

如果原来的主机(6379)此时重新回来了，只能归并到新的主机下，作为从机，这就是哨兵模式的规则！

优点：

1. 哨兵集群，基于主从复制模式，所有的主从配置优点，他全有。
2. 主从可以切换，故障可以转换，系统的可用性就会更好
3. 哨兵模式就是主从模式的升级，手动到自动，更加健壮！

缺点：

1. Redis不好在线扩容的，集群容量一旦到达上限，在线扩容就会非常麻烦！
2. 实现哨兵模式的配置其实是很麻烦的，里面有很多选择！（我们这是这是开了一个最简单的哨兵模式）

Redis缓存穿透

Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。

另外的一些典型问题就是，缓存穿透(查不到)、缓存击穿(量太大，缓存过期)和缓存雪崩(缓存集体过期、redis宕机)。目前，业界也都有比较流行的解决方案。

缓存穿透概念

用户想要査询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库査询。发现也没有，于是本次査询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

解决方案1：布隆过滤器

布隆过滤器(Bloom filter)是一种数据结构，对所有可能査询的参数以hash形式存储，在控制层先进行校验，不符合则丟弃，从而避免了对底层存储系统的查询压力

解决方案2：缓存空对象

当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源

但是这种方法存在2个问题：

1. 如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键
2. 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

Redis缓存击穿

缓存击穿概念

这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。

例如：某时间对某一条微博热搜大量查询，服务器宕机(假设设置缓存60秒过期，60.1秒回复，这0.1秒的间隔 ==> 瞬间全部砸在mysql服务器上)

解决方案1：设置热点数据永不过期

从缓存层面来看，没有设置过期时间，所以不会出现热点key过期后产生的问题

解决方案2：加互斥锁

分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去査询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

Redis缓存雪崩

缓存雪崩，是指在某一个时间段，缓存集中过期失效。或者Redis宕机(停电了)！

产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴増，造成存储层也会挂掉的情况。

其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

例如：双十一：停掉一些服务，来保证主要的服务可用！

解决方案1：redis高可用

这个思想的含义是，既然 redis有可能挂掉，那我多增设几台 redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。（异地多活！）

解决方案2：限流降级

这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程査询数据和写缓存，其他线程等待

解决方案3：数据预热

数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀

参考

• 【狂神说Java】Redis最新超详细版教程通俗易懂