redis学习笔记

1 redis入门

1.1 Redis简介

中国被世界黑的最惨的一天
2007年10月30日，北京奥运会门票面向境内公众第二阶段预售正式启动。上午一开始，公众提交申请空前踊跃。上午9时至10时，官方票务网站的浏览量达到了800万次，票务呼叫中心热线从9时至10时的呼入量超过了380万人次。由于瞬间访问数量过大，技术系统应对不畅，造成很多申购者无法及时提交申请，为此北京奥组委票务中心对广大公众未能及时、便捷地实现奥运门票预订表示歉意。
不可回避的问题
奥运会门票预售系统开放第一天，上午9点正式开始售票到中午12点，3个小时内，票务网站被浏览次数达到2000万次。

一个神奇的网站


大型翻车现场

问题现象

• 海量用户
• 高并发

罪魁祸首——关系型数据库

• 性能瓶颈：磁盘IO性能低下
• 扩展瓶颈：数据关系复杂，扩展性差，不便于大规模集群

解决思路

• 降低磁盘IO次数，越低越好 ------ 内存存储
• 去除数据间关系，越简单越好 ------- 不存储关系，仅存储数据

Nosql
NoSQL：即Not-Only SQL（泛指非关系型的数据库），作为关系型数据库的补充。Nosql作用：应对基于海量用户和海量数据前提下的数据处理问题。
特征：

• 可扩容，可伸缩
• 大数据量下高性能
• 灵活的数据模型
• 高可用

常见Nosql 数据库：

• Redis
• memcache
• HBase
• MongoDB

解决方案（电商场景）

Redis
概念：Redis (REmote DIctionaryServer) 是用C 语言开发的一个开源的高性能键值对（key-value）数据库。
特征：
1.数据间没有必然的关联关系
2.内部采用单线程机制进行工作
3.高性能。官方提供测试数据，50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。
4.多数据类型支持

• 字符串类型 string
• 列表类型 list
• 散列类型 hash
• 集合类型 set
• 有序集合类型 sorted_set

5.持久化支持。可以进行数据灾难恢复

Redis 的应用

• 为热点数据加速查询（主要场景），如热点商品、热点新闻、热点资讯、推广类等高访问量信息等
• 任务队列，如秒杀、抢购、购票排队等
• 即时信息查询，如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息（聊天室、网站）、设备信号等
• 时效性信息控制，如验证码控制、投票控制等
• 分布式数据共享，如分布式集群架构中的session 分离
• 消息队列
• 分布式锁

1.2 Redis 的基本操作

命令行模式工具使用思考

• 功能性命令
• 清除屏幕信息
• 帮助信息查阅
• 退出指令

信息添加

• 功能：设置key，value 数据
• 命令

set key value

• 范例

set name itheima

信息查询

• 功能：根据key 查询对应的value，如果不存在，返回空（nil）
• 命令

get key

• 范例

get name

清除屏幕信息

• 功能：清除屏幕中的信息
• 命令

clear

退出客户端命令行模式

• 功能：退出客户端
• 命令

quit
exit
ESC

帮助

• 功能：获取命令帮助文档，获取组中所有命令信息名称
• 命令

help 命令名称
help @组名

2 Redis 数据类型

2.1 数据存储类型介绍

作为缓存使用
1.原始业务功能设计

• 秒杀
• 618活动
• 双11活动
• 排队购票

2.运营平台监控到的突发高频访问数据

• 突发时政要闻，被强势关注围观

3.高频、复杂的统计数据

• 在线人数
• 投票排行榜

附加功能
系统功能优化或升级

• 单服务器升级集群
• Session 管理
• Token 管理

Redis 数据类型（5种常用）

• string String
• hash HashMap
• list LinkedList
• set HashSet
• sorted_set TreeSet

2.2 string

redis数据存储格式

• redis自身是一个Map，其中所有的数据都是采用key : value 的形式存储
• 数据类型指的是存储的数据的类型，也就是value 部分的类型，key 部分永远都是字符串

string 类型

• 存储的数据：单个数据，最简单的数据存储类型，也是最常用的数据存储类型
• 存储数据的格式：一个存储空间保存一个数据
• 存储内容：通常使用字符串，如果字符串以整数的形式展示，可以作为数字操作使用

string 类型数据的基本操作

• 添加/修改数据

set key value

• 获取数据

get key

• 删除数据

del key

string 类型数据的基本操作

• 添加/修改多个数据

mset key1 value1 key2 value2 …

• 获取多个数据

mget key1 key2 …

• 获取数据字符个数（字符串长度）

strlen key

• 追加信息到原始信息后部（如果原始信息存在就追加，否则新建）

append key value

string 类型数据的基础操作

string 类型数据的扩展操作
业务场景
大型企业级应用中，分表操作是基本操作，使用多张表存储同类型数据，但是对应的主键id 必须保证统一性，不能重复。Oracle 数据库具有sequence 设定，可以解决该问题，但是MySQL数据库并不具有类似的机制，那么如何解决？

解决方案

• 设置数值数据增加指定范围的值

incr key
incrby key increment
incrbyfloat key increment

• 设置数值数据减少指定范围的值

decr key
decrby key increment

string 作为数值操作

• string在redis内部存储默认就是一个字符串，当遇到增减类操作incr，decr时会转成数值型进行计算。
• redis所有的操作都是原子性的，采用单线程处理所有业务，命令是一个一个执行的，因此无需考虑并发带来的数据影响。
• 注意：按数值进行操作的数据，如果原始数据不能转成数值，或超越了redis数值上限范围，将报错。9223372036854775807（java中long型数据最大值，Long.MAX_VALUE）

Tips 1：

• redis用于控制数据库表主键id，为数据库表主键提供生成策略，保障数据库表的主键唯一性
• 此方案适用于所有数据库，且支持数据库集群

业务场景
“最强女生”启动海选投票，只能通过微信投票，每个微信号每4 小时只能投1票。
电商商家开启热门商品推荐，热门商品不能一直处于热门期，每种商品热门期维持3天，3天后自动取消热门。
新闻网站会出现热点新闻，热点新闻最大的特征是时效性，如何自动控制热点新闻的时效性。

解决方案

• 设置数据具有指定的生命周期

setex key seconds value
psetex key milliseconds value

Tips 2：

• redis控制数据的生命周期，通过数据是否失效控制业务行为，适用于所有具有时效性限定控制的操作
• 数据操作不成功的反馈与数据正常操作之间的差异
  • 表示运行结果是否成功
    • (integer) 0 → false失败
    • (integer) 1 → true成功
  • 表示运行结果值
    • (integer) 3 → 3 3个
    • (integer) 1 → 1 1个
• 数据未获取到
  （nil）等同于null
• 数据最大存储量
  512MB
• 数值计算最大范围（java中的long的最大值）
  9223372036854775807

string 类型应用场景
业务场景
主页高频访问信息显示控制，例如新浪微博大V主页显示粉丝数与微博数量

解决方案

• 在redis中为大V用户设定用户信息，以用户主键和属性值作为key，后台设定定时刷新策略即可
  eg: user🆔3506728370:fans → 12210947
  eg: user🆔3506728370:blogs → 6164
  eg: user🆔3506728370:focuss → 83

• 在redis中以json格式存储大V用户信息，定时刷新（也可以使用hash类型）
  eg: user🆔3506728370 → {“id”:3506728370,“name”:“春晚”,“fans”:12210862,“blogs”:6164, “focus”:83}

Tips 3：

• redis应用于各种结构型和非结构型高热度数据访问加速

key 的设置约定

• 数据库中的热点数据key命名惯例
  

2.3 hash 类型

存储的困惑
对象类数据的存储如果具有较频繁的更新需求操作会显得笨重

hash 类型

• 新的存储需求：对一系列存储的数据进行编组，方便管理，典型应用存储对象信息
• 需要的存储结构：一个存储空间保存多个键值对数据
• hash类型：底层使用哈希表结构实现数据存储

hash类型数据的基本操作

• 添加/修改数据

hset key field value

• 获取数据

hget key field
hgetall key

• 删除数据

hdel key field1 [field2]

• 添加/修改多个数据

hmset key field1 value1 field2 value2 …

• 获取多个数据

hmget key field1 field2 …

• 获取哈希表中字段的数量

hlen key

• 获取哈希表中是否存在指定的字段

hexists key field

• 获取哈希表中所有的字段名或字段值

hkeys key
hvals key

• 设置指定字段的数值数据增加指定范围的值

hincrby key field increment
hincrbyfloat key field increment

hash类型数据操作的注意事项

• hash类型下的value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应的值为（nil）
• 每个hash 可以存储2³²-1 个键值对
• hash类型十分贴近对象的数据存储形式，并且可以灵活添加删除对象属性。但hash设计初衷不是为了存储大量对象而设计的，切记不可滥用，更不可以将hash作为对象列表使用
• hgetall操作可以获取全部属性，如果内部field过多，遍历整体数据效率就很会低，有可能成为数据访问瓶颈

hash类型应用场景
业务场景
电商网站购物车设计与实现

业务分析

• 仅分析购物车的redis存储模型
  添加、浏览、更改数量、删除、清空
• 购物车于数据库间持久化同步（不讨论）
• 购物车于订单间关系（不讨论）
  提交购物车：读取数据生成订单
  商家临时价格调整：隶属于订单级别
• 未登录用户购物车信息存储（不讨论）
  cookie存储

解决方案

• 以客户id作为key，每位客户创建一个hash存储结构存储对应的购物车信息

• 将商品编号作为field，购买数量作为value进行存储

• 添加商品：追加全新的field与value

• 浏览：遍历hash

• 更改数量：自增/自减，设置value值

• 删除商品：删除field

• 清空：删除key

• 此处仅讨论购物车中的模型设计

• 购物车与数据库间持久化同步、购物车与订单间关系、未登录用户购物车信息存储不进行讨论

当前设计是否加速了购物车的呈现
当前仅仅是将数据存储到了redis中，并没有起到加速的作用，商品信息还需要二次查询数据库

• 每条购物车中的商品记录保存成两条field
• field1专用于保存购买数量
  命名格式：商品id:nums
  保存数据：数值
• field2专用于保存购物车中显示的信息，包含文字描述，图片地址，所属商家信息等
  命名格式：商品id:info
  保存数据：json

hsetnx key field value

Tips 4：

• redis应用于购物车数据存储设计

业务场景
双11活动日，销售手机充值卡的商家对移动、联通、电信的30元、50元、100元商品推出抢购活动，每种商品抢购上限1000张

解决方案

• 以商家id作为key
• 将参与抢购的商品id作为field
• 将参与抢购的商品数量作为对应的value
• 抢购时使用降值的方式控制产品数量
• 实际业务中还有超卖等实际问题，这里不做讨论

Tips 5：

• redis应用于抢购，限购类、限量发放优惠卷、激活码等业务的数据存储设计

2.4 list类型

• 数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分
• 需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序
• list类型：保存多个数据，底层使用双向链表存储结构实现
  
  
  list 类型数据基本操作
• 添加/修改数据

lpush key value1 [value2] …
rpush key value1 [value2] …

• 获取数据

lrange key start stop
lindex key index
llen key

• 获取并移除数据

lpop key
rpop key

list 类型数据扩展操作

• 规定时间内获取并移除数据

blpop key1 [key2] timeout
brpop key1 [key2] timeout
brpoplpush source destination timeout

业务场景
微信朋友圈点赞，要求按照点赞顺序显示点赞好友信息如果取消点赞，移除对应好友信息

解决方案

• 移除指定数据

lrem key count value

Tips 6：

• redis应用于具有操作先后顺序的数据控制

list 类型数据操作注意事项

• list中保存的数据都是string类型的，数据总容量是有限的，最多2³² -1 个元素(4294967295)。
• list具有索引的概念，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式进行入栈出栈操作。
• 获取全部数据操作结束索引设置为-1。
• list可以对数据进行分页操作，通常第一页的信息来自于list，第2页及更多的信息通过数据库的形式加载。

list类型应用场景
业务场景
twitter、新浪微博、腾讯微博中个人用户的关注列表需要按照用户的关注顺序进行展示，粉丝列表需要将最近关注的粉丝列在前面

新闻、资讯类网站如何将最新的新闻或资讯按照发生的时间顺序展示？
企业运营过程中，系统将产生出大量的运营数据，如何保障多台服务器操作日志的统一顺序输出？

解决方案

• 依赖list的数据具有顺序的特征对信息进行管理
• 使用队列模型解决多路信息汇总合并的问题
• 使用栈模型解决最新消息的问题

Tips 7：

• redis应用于最新消息展示

2.5 set 类型

• 新的存储需求：存储大量的数据，在查询方面提供更高的效率
• 需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询
• set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的
  

set类型数据的基本操作

• 添加数据

sadd key member1 [member2]

• 获取全部数据

smembers key

• 删除数据

srem key member1 [member2]

• 获取集合数据总量

scard key

• 判断集合中是否包含指定数据

sismember key member

set类型数据的扩展操作
业务场景
每位用户首次使用今日头条时会设置3项爱好的内容，但是后期为了增加用户的活跃度、兴趣点，必须让用户对其他信息类别逐渐产生兴趣，增加客户留存度，如何实现？

业务分析

• 系统分析出各个分类的最新或最热点信息条目并组织成set集合
• 随机挑选其中部分信息
• 配合用户关注信息分类中的热点信息组织成展示的全信息集合

解决方案

• 随机获取集合中指定数量的数据

srandmember key [count]

• 随机获取集合中的某个数据并将该数据移出集合

spop key [count]

Tips 8：

• redis应用于随机推荐类信息检索，例如热点歌单推荐，热点新闻推荐，热卖旅游线路，应用APP推荐，大V推荐等

业务场景
公司对旗下新的网站做推广，统计网站的PV（访问量）,UV（独立访客）,IP（独立IP）。
PV：网站被访问次数，可通过刷新页面提高访问量
UV：网站被不同用户访问的次数，可通过cookie统计访问量，相同用户切换IP地址，UV不变
IP：网站被不同IP地址访问的总次数，可通过IP地址统计访问量，相同IP不同用户访问，IP不变

解决方案

• 利用set集合的数据去重特征，记录各种访问数据
• 建立string类型数据，利用incr统计日访问量（PV）
• 建立set模型，记录不同cookie数量（UV）
• 建立set模型，记录不同IP数量（IP）

Tips 11：

• redis应用于同类型数据的快速去重

业务场景
黑名单
资讯类信息类网站追求高访问量，但是由于其信息的价值，往往容易被不法分子利用，通过爬虫技术，快速获取信息，个别特种行业网站信息通过爬虫获取分析后，可以转换成商业机密进行出售。例如第三方火车票、机票、酒店刷票代购软件，电商刷评论、刷好评。
同时爬虫带来的伪流量也会给经营者带来错觉，产生错误的决策，有效避免网站被爬虫反复爬取成为每个网站都要考虑的基本问题。在基于技术层面区分出爬虫用户后，需要将此类用户进行有效的屏蔽，这就是黑名单的典型应用。
ps:不是说爬虫一定做摧毁性的工作，有些小型网站需要爬虫为其带来一些流量。

白名单
对于安全性更高的应用访问，仅仅靠黑名单是不能解决安全问题的，此时需要设定可访问的用户群体，依赖白名单做更为苛刻的访问验证。

解决方案

• 基于经营战略设定问题用户发现、鉴别规则
• 周期性更新满足规则的用户黑名单，加入set集合
• 用户行为信息达到后与黑名单进行比对，确认行为去向
• 黑名单过滤IP地址：应用于开放游客访问权限的信息源
• 黑名单过滤设备信息：应用于限定访问设备的信息源
• 黑名单过滤用户：应用于基于访问权限的信息源

Tips 12：

• redis应用于基于黑名单与白名单设定的服务控制

2.6 sorted_set类型

• 新的存储需求：数据排序有利于数据的有效展示，需要提供一种可以根据自身特征进行排序的方式
• 需要的存储结构：新的存储模型，可以保存可排序的数据
• sorted_set类型：在set的存储结构基础上添加可排序字段
  
  sorted_set类型数据的基本操作
• 添加数据

zadd key score1 member1 [score2 member2]

• 获取全部数据

zrange key start stop [WITHSCORES]
zrevrange key start stop [WITHSCORES]

• 删除数据

zrem key member [member …]

• 按条件获取数据

zrangebyscore key min max [WITHSCORES] [LIMIT]
zrevrangebyscore key max min [WITHSCORES]

• 条件删除数据

zremrangebyrank key start stop
zremrangebyscore key min max

注意：

• min与max用于限定搜索查询的条件

• start与stop用于限定查询范围，作用于索引，表示开始和结束索引

• offset与count用于限定查询范围，作用于查询结果，表示开始位置和数据总量

• 获取集合数据总量

zcard key
zcount key min max

• 集合交、并操作
• zinterstore destination numkeys key [key …]
• zunionstore destination numkeys key [key …]

业务场景
票选广东十大杰出青年，各类综艺选秀海选投票
各类资源网站TOP10（电影，歌曲，文档，电商，游戏等）
聊天室活跃度统计
游戏好友亲密度

业务分析

• 为所有参与排名的资源建立排序依据

解决方案

• 获取数据对应的索引（排名）

zrank key member
zrevrank key member

• score值获取与修改

zscore key member
zincrby key increment member

Tips 13：

• redis应用于计数器组合排序功能对应的排名

sorted_set类型数据操作的注意事项

• score保存的数据存储空间是64位，如果是整数范围是-9007199254740992~9007199254740992
• score保存的数据也可以是一个双精度的double值，基于双精度浮点数的特征，可能会丢失精度，使用时候要慎重
• sorted_set底层存储还是基于set结构的，因此数据不能重复，如果重复添加相同的数据，score值将被反复覆盖，保留最后一次修改的结果

sorted_set类型应用场景
业务场景
基础服务+增值服务类网站会设定各位会员的试用，让用户充分体验会员优势。例如观影试用VIP、游戏VIP体验、云盘下载体验VIP、数据查看体验VIP。当VIP体验到期后，如果有效管理此类信息。即便对于正式VIP用户也存在对应的管理方式。
网站会定期开启投票、讨论，限时进行，逾期作废。如何有效管理此类过期信息。

解决方案

• 对于基于时间线限定的任务处理，将处理时间记录为score值，利用排序功能区分处理的先后顺序
• 记录下一个要处理的时间，当到期后处理对应任务，移除redis中的记录，并记录下一个要处理的时间
• 当新任务加入时，判定并更新当前下一个要处理的任务时间
• 为提升sorted_set的性能，通常将任务根据特征存储成若干个sorted_set。例如1小时内，1天内，周内，月内，季内，年度等，操作时逐级提升，将即将操作的若干个任务纳入到1小时内处理的队列中
• 获取当前系统时间 time

Tips 14：

• redis应用于定时任务执行顺序管理或任务过期管理

业务场景
任务/消息权重设定应用
当任务或者消息待处理，形成了任务队列或消息队列时，对于高优先级的任务要保障对其优先处理，如何实现任务权重管理。

解决方案

• 对于带有权重的任务，优先处理权重高的任务，采用score记录权重即可
  多条件任务权重设定
  如果权重条件过多时，需要对排序score值进行处理，保障score值能够兼容2条件或者多条件，例如外贸订单优先于国内订单，总裁订单优先于员工订单，经理订单优先于员工订单
• 因score长度受限，需要对数据进行截断处理，尤其是时间设置为小时或分钟级即可（折算后）
• 先设定订单类别，后设定订单发起角色类别，整体score长度必须是统一的，不足位补0。第一排序规则首位不得是0
  • 例如外贸101，国内102，经理004，员工008。
  • 员工下的外贸单score值为101008（优先）
  • 经理下的国内单score值为102004
    Tips 15：
• redis应用于即时任务/消息队列执行管理

2.7 数据类型实践案例

业务场景
人工智能领域的语义识别与自动对话将是未来服务业机器人应答呼叫体系中的重要技术，百度自研用户评价语义识别服务，免费开放给企业试用，同时训练百度自己的模型。现对试用用户的使用行为进行限速，限制每个用户每分钟最多发起10次调用

解决方案

• 设计计数器，记录调用次数，用于控制业务执行次数。以用户id作为key，使用次数作为value
• 在调用前获取次数，判断是否超过限定次数
• 不超过次数的情况下，每次调用计数+1
• 业务调用失败，计数-1
• 为计数器设置生命周期为指定周期，例如1秒/分钟，自动清空周期内使用次数

解决方案改良

• 取消最大值的判定，利用incr操作超过最大值抛出异常的形式替代每次判断是否大于最大值
• 判断是否为nil，
  如果是，设置为Max-次数
  如果不是，计数+1
  业务调用失败，计数-1
• 遇到异常即+操作超过上限，视为使用达到上限

Tips 16：

• redis应用于限时按次结算的服务控制
  
  业务场景
  使用微信的过程中，当微信接收消息后，会默认将最近接收的消息置顶，当多个好友及关注的订阅号同时发送消息时，该排序会不停的进行交替。同时还可以将重要的会话设置为置顶。一旦用户离线后，再次打开微信时，消息该按照什么样的顺序显示？

业务分析

解决方案

• 依赖list的数据具有顺序的特征对消息进行管理，将list结构作为栈使用
• 对置顶与普通会话分别创建独立的list分别管理
• 当某个list中接收到用户消息后，将消息发送方的id从list的一侧加入list（此处设定左侧）
• 多个相同id发出的消息反复入栈会出现问题，在入栈之前无论是否具有当前id对应的消息，先删除对应id
• 推送消息时先推送置顶会话list，再推送普通会话list，推送完成的list清除所有数据
• 消息的数量，也就是微信用户对话数量采用计数器的思想另行记录，伴随list操作同步更新

Tips 17：

• redis应用于基于时间顺序的数据操作，而不关注具体时间

2.8 解决方案列表

• Tips 1：redis用于控制数据库表主键id，为数据库表主键提供生成策略，保障数据库表的主键唯一性
• Tips 2：redis控制数据的生命周期，通过数据是否失效控制业务行为，适用于所有具有时效性限定控制的操作
• Tips 3：redis应用于各种结构型和非结构型高热度数据访问加速
• Tips 4：redis应用于购物车数据存储设计
• Tips 5：redis应用于抢购，限购类、限量发放优惠卷、激活码等业务的数据存储设计
• Tips 6：redis应用于具有操作先后顺序的数据控制
• Tips 7：redis应用于最新消息展示
• Tips 8：redis应用于随机推荐类信息检索，例如热点歌单推荐，热点新闻推荐，热卖旅游线路，应用APP推荐，大V推荐等- - Tips 9：redis应用于同类信息的关联搜索，二度关联搜索，深度关联搜索
• Tips 10：redis应用于同类型不重复数据的合并、取交集操作
• Tips 11：redis应用于同类型数据的快速去重
• Tips 12：redis应用于基于黑名单与白名单设定的服务控制
• Tips 13：redis应用于计数器组合排序功能对应的排名
• Tips 14：redis应用于定时任务执行顺序管理或任务过期管理
• Tips 15：redis应用于及时任务/消息队列执行管理
• Tips 16：redis应用于按次结算的服务控制
• Tips 17：redis应用于基于时间顺序的数据操作，而不关注具体时间

3 Redis 通用指令

3.1 key通用操作

key 特征

• key是一个字符串，通过key获取redis中保存的数据

key应该设计哪些操作？

• 对于key自身状态的相关操作，例如：删除，判定存在，获取类型等
• 对于key有效性控制相关操作，例如：有效期设定，判定是否有效，有效状态的切换等
• 对于key快速查询操作，例如：按指定策略查询key
• …
  key 基本操作
• 删除指定key

del key

• 获取key是否存在

exists key

• 获取key的类型

type key

key 扩展操作（时效性控制）

• 为指定key设置有效期

expire key seconds
pexpirekey milliseconds
expireatkey timestamp
pexpireatkey milliseconds-timestamp

• 获取key的有效时间

ttl key
pttl key

• 切换key从时效性转换为永久性

persist key

key 扩展操作（查询模式）

• 查询key

keys pattern

查询模式规则

•  匹配任意数量的任意符号?     配合一个任意符号[]     匹配一个指定符号
  

keys * 查询所有
keys it* 查询所有以it开头
keys *heima 查询所有以heima结尾
keys ??heima 查询所有前面两个字符任意，后面以heima结尾
keys user:? 查询所有以user:开头，最后一个字符任意
keys u[st]er:1 查询所有以u开头，以er:1结尾，中间包含一个字母，s或t

key 其他操作

• 为key改名

rename key newkey
renamenx key newkey

• 对所有key排序

sort

• 其他key通用操作

help @generic

3.2 数据库

key 的重复问题

• key是由程序员定义的
• redis在使用过程中，伴随着操作数据量的增加，会出现大量的数据以及对应的key
• 数据不区分种类、类别混杂在一起，极易出现重复或冲突

解决方案

• redis为每个服务提供有16个数据库，编号从0到15
• 每个数据库之间的数据相互独立

db 基本操作

• 切换数据库

select index

• 其他操作

quit
ping
echo message

• 数据移动

move key db

• 数据清除

dbsize
flushdb
flushall

4 Redis 持久化

4.1 持久化简介

意外的断电

自动备份

什么是持久化
利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

为什么要进行持久化
防止数据的意外丢失，确保数据安全性

持久化过程保存什么

• 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据
• 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

4.2 RDB

RDB启动方式
谁，什么时间，干什么事情
命令执行

• 谁：redis操作者（用户）
• 什么时间：即时（随时进行）
• 干什么事情：保存数据

RDB启动方式——save指令

• 命令

save

• 作用 手动执行一次保存操作

RDB启动方式——save指令相关配置

• dbfilename dump.rdb
  说明：设置本地数据库文件名，默认值为dump.rdb
  经验：通常设置为dump-端口号.rdb
• dir
  说明：设置存储.rdb文件的路径
  经验：通常设置成存储空间较大的目录中，目录名称data
• rdbcompression yes
  说明：设置存储至本地数据库时是否压缩数据，默认为yes，采用LZF 压缩
  经验：通常默认为开启状态，如果设置为no，可以节省CPU 运行时间，但会使存储的文件变大（巨大）
• rdbchecksum yes
  说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行
  经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

RDB启动方式——save指令工作原理


注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。

数据量过大，单线程执行方式造成效率过低如何处理？
后台执行

• 谁：redis操作者（用户）发起指令；redis服务器控制指令执行
• 什么时间：即时（发起）；合理的时间（执行）
• 干什么事情：保存数据

RDB启动方式——bgsave指令

• 命令

bgsave

• 作用
  手动启动后台保存操作，但不是立即执行

RDB启动方式——bgsave指令工作原理

注意：bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。

RDB启动方式——bgsave指令相关配置

• dbfilename dump.rdb
• dir
• rdbcompression yes
• rdbchecksum yes
• stop-writes-on-bgsave-error yes
  说明：后台存储过程中如果出现错误现象，是否停止保存操作
  经验：通常默认为开启状态

反复执行保存指令，忘记了怎么办？不知道数据产生了多少变化，何时保存？
自动执行

• 谁：redis服务器发起指令（基于条件）
• 什么时间：满足条件
• 干什么事情：保存数据

RDB启动方式——save配置

• 配置

save second changes

• 作用
  满足限定时间范围内key的变化数量达到指定数量即进行持久化
• 参数
  second：监控时间范围
  changes：监控key的变化量
• 位置
  在conf文件中进行配置
• 范例

save 900 1
save 300 10
save 60 10000

RDB启动方式——save配置原理

注意：save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系
save配置启动后执行的是bgsave操作

RDB三种启动方式对比

rdb特殊启动形式

• 全量复制
  在主从复制中详细讲解
• 服务器运行过程中重启

debug reload

• 关闭服务器时指定保存数据

shutdown save

默认情况下执行shutdown命令时，自动执行bgsave(如果没有开启AOF持久化功能)

RDB优点

• RDB是一个紧凑压缩的二进制文件，存储效率较高
• RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
• RDB恢复数据的速度要比AOF快很多
• 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

RDB缺点

• RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
• bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
• Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

4.3 AOF

AOF概念

• AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程
• AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

AOF写数据过程

AOF写数据三种策略(appendfsync)

• always(每次）
  每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。
• everysec（每秒）
  每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置
  在系统突然宕机的情况下丢失1秒内的数据
• no（系统控制）
  由操作系统控制每次同步到AOF文件的周期，整体过程不可控

AOF功能开启

• 配置

appendonly yes | no

• 作用
  是否开启AOF持久化功能，默认为不开启状态
• 配置

appendfsync always | everysec | no

• 作用
  AOF写数据策略

AOF相关配置

• 配置

appendfilename filename

• 作用
  AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof
• 配置

dir

• 作用
  AOF持久化文件保存路径，与RDB持久化文件保持一致即可

AOF写数据遇到的问题
如果连续执行如下指令该如何处理

AOF重写
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写作用

• 降低磁盘占用量，提高磁盘利用率
• 提高持久化效率，降低持久化写时间，提高IO性能
• 降低数据恢复用时，提高数据恢复效率

AOF重写规则

• 进程内已超时的数据不再写入文件
• 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令
  如del key1、hdelkey2、sremkey3、set key4 111、set key4 222等
• 对同一数据的多条写命令合并为一条命令
  如lpushlist1 a、lpushlist1 b、lpushlist1 c 可以转化为：lpushlist1 a b c。
  为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

AOF重写方式

• 手动重写

bgrewriteaof

• 自动重写

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage

AOF手动重写——bgrewriteaof指令工作原理

AOF自动重写方式

• 自动重写触发条件设置

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percent

• 自动重写触发比对参数（运行指令info Persistence获取具体信息）

aof_current_size
aof_base_size

• 自动重写触发条件
  
  AOF工作流程
  
  
  
  AOF缓冲区同步文件策略，由参数appendfsync控制
  系统调用write和fsync说明：
• write操作会触发延迟写（delayedwrite）机制，Linux在内核提供页缓冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，列如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
• fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞知道写入硬盘完成后返回，保证了数据持久化。

除了write、fsync、Linx还提供了sync、fdatasync操作，具体API说明参见：

4.4 RDB与AOF区别

RDB与AOF的选择之惑

• 对数据非常敏感，建议使用默认的AOF持久化方案
  • AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
• 注意：由于AOF文件存储体积较大，且恢复速度较慢
  • 注意：由于AOF文件存储体积较大，且恢复速度较慢
• 数据呈现阶段有效性，建议使用RDB持久化方案
  • 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
  • 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
• 综合比对
  • RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
  • 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
  • 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
  • 灾难恢复选用RDB
  • 双保险策略，同时开启RDB 和AOF，重启后，Redis优先使用AOF 来恢复数据，降低丢失数据的量

5 Redis 事务

5.1 事务简介

什么是事务
Redis执行指令过程中，多条连续执行的指令被干扰，打断，插队
redis事务就是一个命令执行的队列，将一系列预定义命令包装成一个整体（一个队列）。当执行时，一次性按照添加顺序依次执行，中间不会被打断或者干扰。
一个队列中，一次性、顺序性、排他性的执行一系列命令

5.2 事务的基本操作

• 开启事务

multi

• 作用
  设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中
• 执行事务

exec

• 作用
  设定事务的结束位置，同时执行事务。与multi成对出现，成对使用
  注意：加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行exec命令才开始执行

事务定义过程中发现出了问题，怎么办？

• 取消事务

discard

• 作用
  终止当前事务的定义，发生在multi之后，exec之前
  
  事务的注意事项
  定义事务的过程中，命令格式输入错误怎么办？
• 语法错误
  指命令格式正确，但是无法正确的执行。例如对list进行incr操作
• 处理结果
  如果定义的事务中所包含的命令存在语法错误，整体事务中所有命令均不会执行。包括那些语法正确的命令。

定义事务的过程中，命令执行出现错误怎么办？

• 运行错误
  指命令格式正确，但是无法正确的执行。例如对list进行incr操作
• 处理结果
  能够正确运行的命令会执行，运行错误的命令不会被执行

注意：已经执行完毕的命令对应的数据不会自动回滚，需要程序员自己在代码中实现回滚。

手动进行事务回滚

• 记录操作过程中被影响的数据之前的状态
  • 单数据：string
  • 多数据：hash、list、set、zset
• 多数据：hash、list、set、zset
  • 多数据：hash、list、set、zset
  • 多数据：hash、list、set、zset

5.3 锁

基于特定条件的事务执行
业务场景

天猫双11热卖过程中，对已经售罄的货物追加补货，4个业务员都有权限进行补货。补货的操作可能是一系
列的操作，牵扯到多个连续操作，如何保障不会重复操作？

业务分析

• 多个客户端有可能同时操作同一组数据，并且该数据一旦被操作修改后，将不适用于继续操作
• 在操作之前锁定要操作的数据，一旦发生变化，终止当前操作

基于特定条件的事务执行——锁
解决方案

• 对 key 添加监视锁，在执行exec前如果key发生了变化，终止事务执行

watch key1 [key2……]

• 取消对所有 key 的监视

unwatch

Tips 18：

• redis 应用基于状态控制的批量任务执行

基于特定条件的事务执行
业务场景

天猫双11热卖过程中，对已经售罄的货物追加补货，且补货完成。客户购买热情高涨，3秒内将所有商品购
买完毕。本次补货已经将库存全部清空，如何避免最后一件商品不被多人同时购买？【超卖问题】

业务分析

• 使用watch监控一个key有没有改变已经不能解决问题，此处要监控的是具体数据
• 虽然redis是单线程的，但是多个客户端对同一数据同时进行操作时，如何避免不被同时修改？

基于特定条件的事务执行——分布式锁
解决方案

• 使用 setnx 设置一个公共锁

setnx lock-key value

利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功

• 对于返回设置成功的，拥有控制权，进行下一步的具体业务操作
• 对于返回设置失败的，不具有控制权，排队或等待

操作完毕通过del操作释放锁
注意：上述解决方案是一种设计概念，依赖规范保障，具有风险性

Tips 19：

• redis 应用基于分布式锁对应的场景控制

基于特定条件的事务执行
业务场景
依赖分布式锁的机制，某个用户操作时对应客户端宕机，且此时已经获取到锁。如何解决？

业务分析

• 由于锁操作由用户控制加锁解锁，必定会存在加锁后未解锁的风险
• 需要解锁操作不能仅依赖用户控制，系统级别要给出对应的保底处理方案

基于特定条件的事务执行——分布式锁改良
解决方案

• 使用 expire 为锁key添加时间限定，到时不释放，放弃锁

expire lock-key second
pexpire lock-key milliseconds

由于操作通常都是微秒或毫秒级，因此该锁定时间不宜设置过大。具体时间需要业务测试后确认。

• 例如：持有锁的操作最长执行时间127ms，最短执行时间7ms。
• 测试百万次最长执行时间对应命令的最大耗时，测试百万次网络延迟平均耗时
• 锁时间设定推荐：最大耗时120%+平均网络延迟110%
• 如果业务最大耗时<<网络平均延迟，通常为2个数量级，取其中单个耗时较长即可

6 Redis 删除策略

6.1 过期数据

Redis中的数据特征

• Redis是一种内存级数据库，所有数据均存放在内存中，内存中的数据可以通过TTL指令获取其状态
  • XX ：具有时效性的数据
  • -1 ：永久有效的数据
  • -2 ：已经过期的数据 或 被删除的数据 或 未定义的数据

过期的数据真的删除了吗？
数据删除策略
1、定时删除
2、惰性删除
3、定期删除

6.2 数据删除策略

时效性数据的存储结构

数据删除策略的目标
在内存占用与CPU占用之间寻找一种平衡，顾此失彼都会造成整体redis性能的下降，甚至引发服务器宕机或
内存泄露

定时删除

• 创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作
• 优点：节约内存，到时就删除，快速释放掉不必要的内存占用
• 缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量
• 总结：用处理器性能换取存储空间（拿时间换空间）
  
  惰性删除
• 数据到达过期时间，不做处理。等下次访问该数据时
  • 如果未过期，返回数据
  • 发现已过期，删除，返回不存在
• 优点：节约CPU性能，发现必须删除的时候才删除
• 缺点：内存压力很大，出现长期占用内存的数据
• 总结：用存储空间换取处理器性能 expireIfNeeded() （拿时间换空间）
  
  定期删除
  两种方案都走极端，有没有折中方案？
• Redis启动服务器初始化时，读取配置server.hz的值，默认为10
• 每秒钟执行server.hz次serverCron() -> databasesCron() -> activeExpireCycle()
• activeExpireCycle()对每个expires[*]逐一进行检测，每次执行250ms/server.hz
  • 如果key超时，删除key
  • 如果一轮中删除的key的数量>W*25%，循环该过程
  • 如果一轮中删除的key的数量≤W25%，检查下一个expires[]，0-15循环
  • W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值
• 参数current_db用于记录activeExpireCycle() 进入哪个expires[*] 执行
• 如果activeExpireCycle()执行时间到期，下次从current_db继续向下执行
• 周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度
• 特点1：CPU性能占用设置有峰值，检测频度可自定义设置
• 特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理
• 总结：周期性抽查存储空间（随机抽查，重点抽查）

删除策略比对
1、定时删除

• 节约内存，无占用
• 不分时段占用CPU资源，频度高
• 拿时间换空间
  2、惰性删除
• 内存占用严重
• 延时执行，CPU利用率高
• 拿空间换时间
  3、定期删除
• 内存定期随机清理
• 每秒花费固定的CPU资源维护内存
• 随机抽查，重点抽查

6.3 逐出算法

新数据进入检测
当新数据进入redis时，如果内存不足怎么办？

• Redis使用内存存储数据，在执行每一个命令前，会调用freeMemoryIfNeeded()检测内存是否充足。如
  果内存不满足新加入数据的最低存储要求，redis要临时删除一些数据为当前指令清理存储空间。清理数据
  的策略称为逐出算法。
• 注意：逐出数据的过程不是100%能够清理出足够的可使用的内存空间，如果不成功则反复执行。当对所
  有数据尝试完毕后，如果不能达到内存清理的要求，将出现错误信息。

(error) OOM command not allowed when used memory >‘maxmemory’

影响数据逐出的相关配置

• 最大可使用内存

maxmemory

占用物理内存的比例，默认值为0，表示不限制。生产环境中根据需求设定，通常设置在50%以上。

• 每次选取待删除数据的个数

maxmemory-samples

选取数据时并不会全库扫描，导致严重的性能消耗，降低读写性能。因此采用随机获取数据的方式作为待检测删除数据

• 删除策略

maxmemory-policy

达到最大内存后的，对被挑选出来的数据进行删除的策略

影响数据逐出的相关配置

• 检测易失数据（可能会过期的数据集server.db[i].expires ）
  ① volatile-lru：挑选最近最少使用的数据淘汰
  ② volatile-lfu：挑选最近使用次数最少的数据淘汰
  ③ volatile-ttl：挑选将要过期的数据淘汰
  ④ volatile-random：任意选择数据淘汰
• 检测全库数据（所有数据集server.db[i].dict ）
  ⑤ allkeys-lru：挑选最近最少使用的数据淘汰
  ⑥ allkeys-lfu：挑选最近使用次数最少的数据淘汰
  ⑦ allkeys-random：任意选择数据淘汰
• 放弃数据驱逐
  ⑧ no-enviction（驱逐）：禁止驱逐数据（redis4.0中默认策略），会引发错误OOM（Out Of Memory）

数据逐出策略配置依据

• 使用INFO命令输出监控信息，查询缓存 hit 和 miss 的次数，根据业务需求调优Redis配置

7 Redis 核心配置

7.1 服务器基础配置

服务器端设定

• 设置服务器以守护进程的方式运行

daemonize yes|no

• 绑定主机地址

bind 127.0.0.1

• 设置服务器端口号

port 6379

• 设置数据库数量

databases 16

日志配置

• 设置服务器以指定日志记录级别

loglevel debug|verbose|notice|warning

• 日志记录文件名

logfile 端口号.log

注意：日志级别开发期设置为verbose即可，生产环境中配置为notice，简化日志输出量，降低写日志IO的频度

客户端配置

• 设置同一时间最大客户端连接数，默认无限制。当客户端连接到达上限，Redis会关闭新的连接

maxclients 0

• 客户端闲置等待最大时长，达到最大值后关闭连接。如需关闭该功能，设置为 0

timeout 300

多服务器快捷配置

• 导入并加载指定配置文件信息，用于快速创建redis公共配置较多的redis实例配置文件，便于维护

include /path/server-端口号.conf

8 高级数据类型

8.1 Bitmaps

Bitmaps类型的基础操作

• 获取指定key对应偏移量上的bit值

getbit key offset

• 设置指定key对应偏移量上的bit值，value只能是1或0

setbit key offset value

Bitmaps类型的扩展操作
业务场景
电影网站

• 统计每天某一部电影是否被点播
• 统计每天有多少部电影被点播
• 统计每周/月/年有多少部电影被点播
• 统计年度哪部电影没有被点播

业务分析

• 对指定key按位进行交、并、非、异或操作，并将结果保存到destKey中

bitop op destKey key1 [key2…]

 and：交
 or：并
 not：非
 xor：异或

• 统计指定key中1的数量

bitcount key [start end]

Tips 21：

• redis 应用于信息状态统计

8.2 HyperLogLog

统计独立UV

• 原始方案：set
  • 存储每个用户的id（字符串）
• 改进方案：Bitmaps
  • 存储每个用户状态（bit）
• 全新的方案：Hyperloglog

基数

• 基数是数据集去重后元素个数
• HyperLogLog 是用来做基数统计的，运用了LogLog的算法

LogLog算法

HyperLogLog类型的基本操作

• 添加数据

pfadd key element [element …]

• 统计数据

pfcount key [key …]

• 合并数据

pfmerge destkey sourcekey [sourcekey…]

Tips 22：

• redis 应用于独立信息统计

相关说明

• 用于进行基数统计，不是集合，不保存数据，只记录数量而不是具体数据
• 核心是基数估算算法，最终数值存在一定误差
• 误差范围：基数估计的结果是一个带有 0.81% 标准错误的近似值
• 耗空间极小，每个hyperloglog key占用了12K的内存用于标记基数
• pfadd命令不是一次性分配12K内存使用，会随着基数的增加内存逐渐增大
• Pfmerge命令合并后占用的存储空间为12K，无论合并之前数据量多少

8.3 GEO

火热的生活服务类软件


GEO类型的基本操作

• 添加坐标点

geoadd key longitude latitude member [longitude latitude member …]

• 获取坐标点

geopos key member [member …]

• 计算坐标点距离

geodist key member1 member2 [unit]

• 添加坐标点

georadius key longitude latitude radius m|km|ft|mi [withcoord] [withdist] [withhash] [count count]

• 获取坐标点

georadiusbymember key member radius m|km|ft|mi [withcoord] [withdist] [withhash] [count count]

• 计算经纬度

geohash key member [member …]

Tips 23：

• redis 应用于地理位置计算

9 主从复制

9.1 主从复制简介

互联网“三高”架构

• 高并发
• 高性能
• 高可用

你的“Redis”是否高可用
单机redis的风险与问题

• 问题1.机器故障
  • 现象：硬盘故障、系统崩溃
  • 本质：数据丢失，很可能对业务造成灾难性打击
  • 结论：基本上会放弃使用redis
• 问题2.容量瓶颈
  • 现象：内存不足，从16G升级到64G，从64G升级到128G，无限升级内存
  • 本质：穷，硬件条件跟不上
  • 结论：放弃使用redis
• 结论：

为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服
务器上，连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续
提供服务，实现Redis的高可用，同时实现数据冗余备份。

多台服务器连接方案

• 提供数据方：master
  主服务器，主节点，主库
  主客户端

• 接收数据方：slave
  从服务器，从节点，从库
  从客户端

• 需要解决的问题：
  数据同步

• 核心工作：
  master的数据复制到slave中

主从复制
主从复制即将master中的数据即时、有效的复制到slave中
特征：一个master可以拥有多个slave，一个slave只对应一个master
职责：

• master:
  • 写数据
  • 执行写操作时，将出现变化的数据自动同步到slave
  • 读数据（可忽略）
• slave:
  • 读数据
  • 写数据（禁止）

高可用集群

主从复制的作用

• 读写分离：master写、slave读，提高服务器的读写负载能力
• 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数
  量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
• 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
• 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
• 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

9.2 主从复制工作流程

总述

• 主从复制过程大体可以分为3个阶段
  • 建立连接阶段（即准备阶段）
  • 数据同步阶段
  • 命令传播阶段
    
    阶段一：建立连接阶段
• 建立slave到master的连接，使master能够识别slave，并保存slave端口号

主从连接（slave连接master）

• 方式一：客户端发送命令

slaveof

• 方式二：启动服务器参数

redis-server -slaveof

• 方式三：服务器配置

slaveof

主从断开连接

• 客户端发送命令

slaveof no one

• 说明：slave断开连接后，不会删除已有数据，只是不再接受master发送的数据

授权访问

阶段二：数据同步阶段工作流程

• 在slave初次连接master后，复制master中的所有数据到slave
• 将slave的数据库状态更新成master当前的数据库状态
  
  数据同步阶段master说明
  1、 如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行
  2、 复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已
  经存在丢失的情况，必须进行第二次全量复制，致使slave陷入死循环状态。

repl-backlog-size 1mb

3、 master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执
行bgsave命令和创建复制缓冲区

数据同步阶段slave说明
1、为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务

slave-serve-stale-data yes|no

2、数据同步阶段，master发送给slave信息可以理解master是slave的一个客户端，主动向slave发送
命令
3、多个slave同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，如果
master带宽不足，因此数据同步需要根据业务需求，适量错峰
4、slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是
slave。注意使用树状结构时，由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟
较大，数据一致性变差，应谨慎选择

阶段三：命令传播阶段

• 当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的
  状态，同步的动作称为命令传播
• master将接收到的数据变更命令发送给slave，slave接收命令后执行命令
• 主从复制过程大体可以分为3个阶段
  • 建立连接阶段（即准备阶段）
  • 数据同步阶段
  • 命令传播阶段

命令传播阶段的部分复制

服务器运行ID（runid）

• 概念：服务器运行ID是每一台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行id
• 组成：运行id由40位字符组成，是一个随机的十六进制字符
  例如：fdc9ff13b9bbaab28db42b3d50f852bb5e3fcdce
• 作用：运行id被用于在服务器间进行传输，识别身份
  如果想两次操作均对同一台服务器进行，必须每次操作携带对应的运行id，用于对方识别
• 实现方式：运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行ID发
  送给slave，slave保存此ID，通过info Server命令，可以查看节点的runid

复制缓冲区

• 概念：复制缓冲区，又名复制积压缓冲区，是一个先进先出（FIFO）的队列，用于存储服务器执行过的命
  令，每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区
  
  复制缓冲区内部工作原理
  
  
  
  
  
  
  

9.3 主从复制常见问题

10 哨兵模式

10.1 哨兵简介

主机“宕机”

哨兵


哨兵的作用

10.2 启用哨兵模式

配置哨兵

10.3 哨兵工作原理

主从切换

阶段一：监控阶段

阶段二：通知阶段

阶段三：故障转移阶段

主从切换总结

11 集群

11.1 集群简介

现状问题

集群架构

集群作用

11.2 Redis集群结构设计

数据存储设计



集群内部通讯设计

11.3 Cluster集群结构搭建

搭建方式

Cluster配置

Cluster节点操作命令

redis-trib命令

12 企业级解决方案

12.1 缓存预热

“宕机”
服务器启动后迅速宕机

问题排查

解决方案

总结

12.2 缓存雪崩

数据库服务器崩溃（1）

问题排查

问题分析

• 短时间范围内
• 大量key集中过期

解决方案（道）

12.3 缓存雪崩

解决方案（术）

总结

12.4 缓存击穿

数据库服务器崩溃（2）

问题排查

问题分析

解决方案（术）

总结

12.4 缓存穿透

数据库服务器崩溃（3）

问题排查

问题分析

解决方案（术）

总结

12.5 性能指标监控

监控指标






监控方式

benchmark

monitor

showlong