redis工程实战介绍（含面试题）

---

redis是多线程还是单线程,为什么是单线程

这种问法其实并不严谨，为啥这么说呢?

Redis的版本很多3.x、4.x、6.x，版本不同架构也是不同的，不限定版本问是否单线程也不太严谨。

1. 版本3.x ，最早版本，也就是大家口口相传的redis是单线程，阳哥2016年讲解的redis就是3.X的版本。

2. 版本4.x，严格意义来说也不是单线程，而是负责处理客户端请求的线程是单线程，但是开始加了点多线程的东西(异步删除)。—貌似

3. 2020年5月版本的6.0.x后及2022年出的7.0版本后，告别了大家印象中的单线程，用一种全新的多线程来解决问题。—实锤

其实纯单线程也会有问题

正常情况下使用 del 指令可以很快的删除数据，而当被删除的 key 是一个非常大的对象时，例如时包含了成千上万个元素的 hash 时，那么 del 指令就会造成 Redis 主线程卡顿。

这就是redis3.x单线程时代最经典的故障，大key删除的头疼问题，

由于redis是单线程的，del bigKey …

等待很久这个线程才会释放，类似加了一个synchronized锁，你可以想象高并发下，程序堵成什么样子？

解决方案：

• 使用惰性删除可以有效避免redis卡顿问题

• 比如当我（Redis）需要删除一个很大的数据时，因为是单线程原子命令操作，这就会导致 Redis 服务卡顿，

• 于是在 Redis 4.0 中就新增了多线程的模块，当然此版本中的多线程主要是为了解决删除数据效率比较低的问题的。

聊聊redis的多线程特性和IO多路复用

对于redis主要的性能瓶颈是内存或者网络带宽并非CPU

• 这是因为，redis一直被大家熟知的就是他的单线程架构，虽然有些命令可以用后台线程或子进程执行（比如数据删除，快照生成，aof重写）但是从网络io处理到实际的读写命令处理，都是由单个线程完成的
• 为了应对这个问题：采用多个io线程来处理网络请求，提高网络请求处理的并行度，redis6/7就是采用这种方法
• 但是reids的多io线程只是用来处理网络请求的，，这是因为redis处理请求时，网络处理经常是瓶颈，通过多个io线程并行处理网络操作，可以提升实例的整体处理性能，而继续使用单线程执行命令操作，就不用为了保证Lua脚本，事务的原子性，额外开发多线程，这样一来，redis线程模型实现就简单了

IO多路复用是什么？

• 一种同步的IO模型，实现一个线程监视多个文件句柄，一旦某个文件句柄就绪就能够通知到对应的应用程序进行相应的对鞋操作，没有文件句柄时会阻塞应用程序，从而释放CPU资源
• I/O：网络I/O，尤其在操作系统层面指数据在内核态和用户态之间的读写操作
• 多路：多个客户端连接（即socket）
• 复用：复用一个或几个线程
• IO多路复用：也就是说一个或一组线程处理多个TCP连接，使用单进程就能实现同时处理多个客户端的连接，无需创建或者维护过多的进程/线程

io多路复用模型

目的是尽量多的提高服务器的吞吐能力。

大家都用过nginx，nginx使用epoll接收请求，ngnix会有很多链接进来， epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。redis类似同理，这就是IO多路复用原理，有请求就响应，没请求不打扰。

redis如此快的原因

IO多路复用+epoll函数使用，才是redis为什么这么快的直接原因，而不是仅仅单线程命令+redis安装在内存中。

linux bash执行

通过redis提供的管道–pipe命令插入100w的数据 请结合自己的机器地址

插入成功

海量数据里查询某一固定前缀的key

SCAN 返回一个包含两个元素的数组，

第一个元素是用于进行下一次迭代的新游标，

第二个元素则是一个数组， 这个数组中包含了所有被迭代的元素。如果新游标返回零表示迭代已结束。

SCAN的遍历顺序

如果生产上限值keys * ，flushdb，flushall等危险命令以防止误操作

bigkey如何处理

• 内存不均，集群迁移困难
• 超时删除，大key删除阻塞主线程
• 网络流量阻塞

memory usage 命令使用过吗，如何发现bigkey

第一种

给出每种数据结构Top 1 bigkey，同时给出每种数据类型的键值个数+平均大小

想查询大于10kb的所有key，–bigkeys参数就无能为力了，需要用到memory usage来计算每个键值的字节数

redis-cli --bigkeys -a 111111

redis-cli -h 127.0.0.1 -p 6379 -a 111111 --bigkeys

删除bigkey

官网

• string：一般用del，如果过于庞大用unlink

bigkey调优，惰性释放lazyfree了解过吗

1. 可以把要删除的缓存值或者是要更新的数据库值暂存到消息队列中（例如使用Kafka/RabbitMQ等）。
2. 当程序没有能够成功地删除缓存值或者是更新数据库值时，可以从消息队列中重新读取这些值，然后再次进行删除或更新。
3. 如果能够成功地删除或更新，我们就要把这些值从消息队列中去除，以免重复操作，此时，我们也可以保证数据库和缓存的数据一致了，否则还需要再次进行重试
4. 如果重试超过的一定次数后还是没有成功，我们就需要向业务层发送报错信息了，通知运维人员。

先删除缓存，再更新数据库，会出现什么问题

**问题：**当A线程来更新数据，此时缓存已经掉了，准备更新数据库的时候，这个时候还没更新完，此时，B线程来进行查询，他发现缓存读不到，就去查数据库（这个时候是旧值），就将这个旧值又写回了redis了。A这个时候懵了，我删的怎么又变回去了，这个时候A更新完数据库，就发现数据库和redis数据不一致了

双检加锁策略

多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个 互斥锁来锁住它。

其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。

c

下载地址

是什么

c [kə’næl]，中文翻译为 水道/管道/沟渠/运河，主要用途是用于 MySQL 数据库增量日志数据的订阅、消费和解析，是阿里巴巴开发并开源的，采用Java语言开发；

历史背景是早期阿里巴巴因为杭州和美国双机房部署，存在跨机房数据同步的业务需求，实现方式主要是基于业务 trigger（触发器） 获取增量变更。从2010年开始，阿里巴巴逐步尝试采用解析数据库日志获取增量变更进行同步，由此衍生出了c项目；

作用

• 数据库镜像
• 数据库实时备份
• 索引构建和实时维护（拆分异构索引、倒排索引）
• 业务cache刷新
• 带业务逻辑的增量数据处理

c工作原理

MySQL的主从将经过如下步骤：

1、当 master 主服务器上的数据发生改变时，则将其改变写入二进制事件日志文件中；

2、salve 从服务器会在一定时间间隔内对 master 主服务器上的二进制日志进行探测，探测其是否发生过改变，

如果探测到 master 主服务器的二进制事件日志发生了改变，则开始一个 I/O Thread 请求 master 二进制事件日志；

3、同时 master 主服务器为每个 I/O Thread 启动一个dump Thread，用于向其发送二进制事件日志；

4、slave 从服务器将接收到的二进制事件日志保存至自己本地的中继日志文件中；

5、salve 从服务器将启动 SQL Thread 从中继日志中读取二进制日志，在本地重放，使得其数据和主服务器保持一致；

6、最后 I/O Thread 和 SQL Thread 将进入睡眠状态，等待下一次被唤醒；

官网地址

官网

mysql

查看mysql版本

当前主机二进制日志

查看show variables like ‘log_bin’

开启mysql的binlog写入功能

编辑my.ini，请事先备份文件

重启mysql

再次查看log_bin

授权c连接mysql账号

默认是没有c账户，此处新建并授权

c服务端

（注意默认linux服务器已经有java8的环境，因为c是java写的需要java运行环境）

下载

注意发布时间+版本，2022.8.11后发布的才用

解压

配置

• 修改/myc/conf/example路径下instance.properties文件 换成自己的mysql主机master的IP地址

启动

在/opt/myc/bin路径下执行

查看

c客户端（java编写业务程序）

sql脚本

建module

c_demo02

改pom

配置文件

注意使用自己的mysql密码

启动类

业务类

redisUtils

RedisCClientExample

亿级系统中常见的四种统计

聚合统计

排序统计

二值统计

基数统计

因为主要的目标高效、巨量地进行计数，所以对存储的数据的内容并不太关心。

也就是说它只能用于统计巨量数量，不太涉及具体的统计对象的内容和精准性。

统计单日一个页面的访问量(PV)，单次访问就算一次。

统计单日一个页面的用户访问量(UV)，即按照用户为维度计算，单个用户一天内多次访问也只算一次。

多个key的合并统计，某个门户网站的所有模块的PV聚合统计就是整个网站的总PV。

去重统计的方案

• hashset
• bitmap 如果数据显较大亿级统计,使用bitmaps同样会有这个问题。

bitmap是通过用位bit数组来表示各元素是否出现，每个元素对应一位，所需的总内存为N个bit。

基数计数则将每一个元素对应到bit数组中的其中一位，比如bit数组010010101(按照从零开始下标，有的就是1、4、6、8)。

新进入的元素只需要将已经有的bit数组和新加入的元素进行按位或计算就行。这个方式能大大减少内存占用且位操作迅速。

But，假设一个样本案例就是一亿个基数位值数据，一个样本就是一亿

如果要统计1亿个数据的基数位值,大约需要内存100000000/8/1024/1024约等于12M,内存减少占用的效果显著。

这样得到统计一个对象样本的基数值需要12M。

如果统计10000个对象样本(1w个亿级),就需要117.1875G将近120G，可见使用bitmaps还是不适用大数据量下(亿级)的基数计数场景

• hyperloglog

淘宝网站首页亿级UV的redis统计方案

按照ipv4的结构来说明，每个ipv4的地址最多是15个字节(ip = “192.168.111.1”，最多xxx.xxx.xxx.xxx)

controller

美团地图位置附近的酒店推送

service

日活统计 连续签到打卡 最近一周的活跃用户 统计指定用户一年之中的登陆天数

布隆过滤器BloomFilter

它实际上是一个很长的二进制数组(00000000)+一系列随机hash算法映射函数，主要用于判断一个元素是否在中。

通常我们会遇到很多要判断一个元素是否在某个中的业务场景，一般想到的是将中所有元素保存起来，然后通过比较确定。

• 安全链接网址，全球上10亿的网址判断

手写一个布隆过滤器

• 白名单初始化

• checkUtils

• service

• controller

总结：主要看service中的代码，让过滤器去拦住那些没有的key数据，来解决缓存击穿的问题，相当于再加了一层拦截保护。

京东签到送京豆

小厂方法

方确但是难以落地实现，o(╥﹏╥)o。

签到用户量较小时这么设计能行，但京东这个体量的用户（估算3000W签到用户，一天一条数据，一个月就是9亿数据）

对于京东这样的体量，如果一条签到记录对应着当日用记录，那会很恐怖…

如何解决这个痛点？

1. 一条签到记录对应一条记录，会占据越来越大的空间。

2. 一个月最多31天，刚好我们的int类型是32位，那这样一个int类型就可以搞定一个月，32位大于31天，当天来了位是1没来就是0。

3. 一条数据直接存储一个月的签到记录，不再是存储一天的签到记录。

大厂方法 基于redis的bitmaps实现签到日历，建表+按位-redis bitmap 在签到统计时，每个用户一天的签到用1个bit位就能表示，

一个月（假设是31天）的签到情况用31个bit位就可以，一年的签到也只需要用365个bit位，根本不用太复杂的类型

解决方案

采用定时器将参与聚划算活动的特价商品新增进入redis中

控制类

• 采用双检加锁策略 多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个 互斥锁来锁住它。

是什么

解决方案

方案一 空对象缓存或者缺省值 如果发生了缓存穿透，我们可以针对要查询的数据，在Redis里存一个和业务部门商量后确定的缺省值(比如，零、负数、defaultNull等)。

比如，键uid:abcdxxx，值defaultNull作为案例的key和value

先去redis查键uid:abcdxxx没有，再去mysql查没有获得 ，这就发生了一次穿透现象。

but，可以增强回写机制

mysql也查不到的话也让redis存入刚刚查不到的key并保护mysql。

第一次来查询uid:abcdxxx，redis和mysql都没有，返回null给调用者，但是增强回写后第二次来查uid:abcdxxx，此时redis就有值了。

可以直接从Redis中读取default缺省值返回给业务应用程序，避免了把大量请求发送给mysql处理，打爆mysql。

但是，此方法架不住黑客的恶意攻击，有缺陷…，只能解决key相同的情况

方案二

google布隆过滤器Guava解决缓存穿透 Guava中布隆过滤器的实现算是比较权威的，所以实际项目中我们可以直接使用guava布隆过滤器

• 依赖添加

工厂类

redis锁

业务类

官网：https://redis.io/docs/manual/patterns/distributed-locks/

pom

redisconfig

contoller

service

• 启动3台docker容器的redis的master主机
• pom

• 配置文件

• 启动类

• 业务类 cacheConfiguration

redispoolproperties

redisproperties

redisRingleProperties

controller

reids的默认内容是多少？在哪里配置，以及如何修改

查看redis的最大占用内存

在64位系统下，设置为0表示的是不限制redis 的内存使用

在生产环境下一般推荐redis设置内存为最大物理内存的四分之三

超出内存使用上线会报OOM错误，所以需要内存淘汰

使用redis的八种淘汰策略 【MEMORY MANAGEMENT】

lru算法和lfu算法的区别

区别 LRU：最近最少使用页面置换算法，淘汰最长时间未被使用的页面，看页面最后一次被使用到发生调度的时间长短，首先淘汰最长时间未被使用的页面

LFU：最近最不常用页面置换算法，淘汰一定时期内被访问次数最少的页，看一定时间段内页面被使用的频率，淘汰一定时期内被访问次数最少的页

例子 某次时期Time为10分钟,如果每分钟进行一次调页,主存块为3,若所需页面走向为2 1 2 1 2 3 4

假设到页面4时会发生缺页中断

若按LRU算法,应换页面1(1页面最久未被使用，因为第二个块中1在最前面)，但按LFU算法应换页面3(十分钟内,页面3只使用了一次) 可见LRU关键是看页面最后一次被使用到发生调度的时间长短,而LFU关键是看一定时间段内页面被使用的频率!

八种淘汰策略

配置建议，避免存储bigkey 开启惰性淘汰，lazyfree-lazy-eviction=yes

• 各种节假日，发红包+抢红包100%高并发业务要求，不能用mysql来做,

• 一个总的大红包，会有可能拆分成多个小红包，总金额= 分金额1+分金额2+分金额3…分金额N

• 每个人只能抢一次，你需要有记录，比如100块钱，被拆分成10个红包发出去，

• 总计有10个红包，抢一个少一个，总数显示(10/6)直到完，需要记录那些人抢到了红包，重复抢作弊不可以。

• 有可能还需要你计时，完整抢完，从发出到全部over，耗时多少？

• 红包过期，或者群主人品差，没人抢红包，原封不动退回。

• 红包过期，剩余金额可能需要回退到发红包主账户下。

关键点：

• 发红包， list
• 抢红包， 抢，不加锁，且原子性，还需要能支持高并发 lpop 出list即可
• 记红包， 记录每个人抢了多少 hash 同一个用户不可以抢夺2次红包
• 拆红包 算法，所有人抢到金额之和等于红包金额，不能超过，也不能少于，每个人至少抢到一分钱，保证所有人抢到金额的几率相等

抢红包业务通用算法-二倍均值法

剩余红包金额为M，剩余人数为N，那么有如下公式：

每次抢到的金额 = 随机区间 （0， (剩余红包金额M ÷ 剩余人数N ) X 2）

这个公式，保证了每次随机金额的平均值是相等的，不会因为抢红包的先后顺序而造成不公平。

举个栗子：

假设有10个人，红包总额100元。

第1次：

100÷10 X2 = 20, 所以第一个人的随机范围是（0，20 )，平均可以抢到10元。假设第一个人随机到10元，那么剩余金额是100-10 = 90 元。

第2次：

90÷9 X2 = 20, 所以第二个人的随机范围同样是（0，20 )，平均可以抢到10元。假设第二个人随机到10元，那么剩余金额是90-10 = 80 元。

第3次：

80÷8 X2 = 20, 所以第三个人的随机范围同样是（0，20 )，平均可以抢到10元。 以此类推，每一次随机范围的均值是相等的。

不考虑小数