技术文档收录
ASCII
Tcpdump
IPV4保留地址段
深入理解以太网网线原理 - 三帛的世界
Linux
WireGuard 一键安装脚本 | 秋水逸冰
SSH Config 那些你所知道和不知道的事 | Deepzz's Blog
Linux 让终端走代理的几种方法
ubuntu 20.04 server 版设置静态 IP 地址 - 链滴
Linux 挂载 Windows 共享磁盘的方法 - 技术学堂
将 SMB/CIFS 网络硬盘永久的挂载到 Ubuntu 上 - 简书
linux 获取当前脚本的绝对路径 | aimuke
[Linux] Linux 使用 / dev/urandom 生成随机数 - piaohua's blog
Linux 生成随机数的多种方法 | Just Do It
Linux 的 Centos7 版本下忘记 root 或者普通用户密码怎么办?
Git 强制拉取覆盖本地
SSH 安全加固指南 - FreeBuf 网络安全行业门户
Linux 系统安全强化指南 - FreeBuf 网络安全行业门户
Linux 入侵排查 - FreeBuf 网络安全行业门户
sshd_config 配置详解 - 简书
SSH 权限详解 - SegmentFault 思否
CentOS 安装 node.js 环境 - SegmentFault 思否
如何在 CentOS 7 上安装 Node.js 和 npm | myfreax
几款 ping tcping 工具总结
OpenVpn 搭建教程 | Jesse's home
openvpn 一键安装脚本 - 那片云
OpenVPN 解决 每小时断线一次 - 爱开源
OpenVPN 路由设置 – 凤曦的小窝
OpenVPN 设置非全局代理 - 镜子的记录簿
TinyProxy 使用帮助 - 简书
Ubuntu 下使用 TinyProxy 搭建代理 HTTP 服务器_Linux_运维开发网_运维开发技术经验分享
Linux 软件包管理工具 Snap 常用命令 - 简书
linux systemd 参数详解
Systemd 入门教程:命令篇 - 阮一峰的网络日志
记一次 Linux 木马清除过程
rtty:在任何地方通过 Web 访问您的终端
02 . Ansible 高级用法 (运维开发篇)
终于搞懂了服务器为啥产生大量的 TIME_WAIT!
巧妙的 Linux 命令,再来 6 个!
77% 的 Linux 运维都不懂的内核问题,这篇全告诉你了
运维工程师必备:请收好 Linux 网络命令集锦
一份阿里员工的 Java 问题排查工具单
肝了 15000 字性能调优系列专题(JVM、MySQL、Nginx and Tomcat),看不完先收
作业调度算法(FCFS,SJF,优先级调度,时间片轮转,多级反馈队列) | The Blog Of WaiterXiaoYY
看了这篇还不会 Linux 性能分析和优化,你来打我
2019 运维技能风向标
更安全的 rm 命令,保护重要数据
求你了,别再纠结线程池大小了!
Linux sudo 详解 | 失落的乐章
重启大法好!线上常见问题排查手册
sudo 使用 - 笨鸟教程的博客 | BY BenderFly
shell 在手分析服务器日志不愁? - SegmentFault 思否
sudo 与 visudo 的超细用法说明_陈发哥 007 的技术博客_51CTO 博客
ESXI 下无损扩展 Linux 硬盘空间 | Naonao Blog
Linux 学习记录:su 和 sudo | Juntao Tan 的个人博客
使用者身份切换 | Linux 系统教程(笔记)
你会使用 Linux 编辑器 vim 吗?
在 Windows、Linux 和 Mac 上查看 Wi-Fi 密码
linux 隐藏你的 crontab 后门 - 简书
Linux 定时任务详解 - Tr0y's Blog
linux 的 TCP 连接数量最大不能超过 65535 个吗,那服务器是如何应对百万千万的并发的?_一口 Linux 的博客 - CSDN 博客_tcp 连接数多少正常
万字长文 + 28 张图,一次性说清楚 TCP,运维必藏
为什么 p2p 模式的 tunnel 底层通常用 udp 而不是 tcp?
记一次服务器被入侵挖矿 - tlanyan
shell 判断一个变量是否为空方法总结 - 腾讯云开发者社区 - 腾讯云
系统安装包管理工具 | Escape
编译代码时动态地链接库 - 51CTO.COM
甲骨文 Oracle Cloud 添加新端口开放的方法 - WirelessLink 社区
腾讯云 Ubuntu 添加 swap 分区的方法_弓弧名家_玄真君的博客 - CSDN 博客
Oracle 开放全部端口并关闭防火墙 - 清~ 幽殇
谁再说不熟悉 Linux 命令, 就把这个给他扔过去!
即插即用,运维工程师必会正则表达式大全
Shell脚本编写及常见面试题
Samba 文件共享服务器
到底一台服务器上最多能创建多少个 TCP 连接 | plantegg
SSH 密钥登录 - SSH 教程 - 网道
在 Bash 中进行 encodeURIComponent/decodeURIComponent | Harttle Land
使用 Shell 脚本来处理 JSON - Tom CzHen's Blog
Docker
「Docker」 - 保存镜像 - 知乎
终于可以像使用 Docker 一样丝滑地使用 Containerd 了!
私有镜像仓库选型:Harbor VS Quay - 乐金明的博客 | Robin Blog
exec 与 entrypoint 使用脚本 | Mr.Cheng
Dockerfile 中的 CMD 与 ENTRYPOINT
使用 Docker 配置 MySQL 主从数据库 - 墨天轮
Alpine vs Distroless vs Busybox – 云原生实验室 - Kubernetes|Docker|Istio|Envoy|Hugo|Golang | 云原生
再见,Docker!
docker save 与 docker export 的区别 - jingsam
如何优雅的关闭容器
docker 储存之 tmpfs 、bind-mounts、volume | 陌小路的个人博客
Dockerfile 中 VOLUME 与 docker -v 的区别是什么 - 开发技术 - 亿速云
理解 docker 容器的退出码 | Vermouth | 博客 | docker | k8s | python | go | 开发
【Docker 那些事儿】容器监控系统,来自 Docker 的暴击_飞向星的客机的博客 - CSDN 博客
【云原生】Docker 镜像详细讲解_微枫 Micromaple 的博客 - CSDN 博客_registry-mirrors
【云原生】Helm 架构和基础语法详解
CMD 和 Entrypoint 命令使用变量的用法
实时查看容器日志 - 苏洋博客
Traefik 2 使用指南,愉悦的开发体验 - 苏洋博客
为你的 Python 应用选择一个最好的 Docker 映像 | 亚马逊 AWS 官方博客
【云原生】镜像构建实战操作(Dockerfile)
Docker Compose 中的 links 和 depends_on 的区别 - 编程知识 - 白鹭情
Python
Pipenv:新一代Python项目环境与依赖管理工具 - 知乎
Python list 列表实现栈和队列
Python 各种排序 | Lesley's blog
Python 中使用 dateutil 模块解析时间 - SegmentFault 思否
一个小破网站,居然比 Python 官网还牛逼
Python 打包 exe 的王炸 - Nuitka
Django - - 基础 - - Django ORM 常用查询语法及进阶
[Python] 小知識:== 和 is 的差異 - Clay-Technology World
Window
批处理中分割字符串 | 网络进行时
Windows 批处理基础命令学习 - 简书
在Windows上设置WireGuard
Windows LTSC、LTSB、Server 安装 Windows Store 应用商店
windows 重启 rdpclip.exe 的脚本
中间件
Nginx 中的 Rewrite 的重定向配置与实践
RabbitMQ 的监控
RabbitMq 最全的性能调优笔记 - SegmentFault 思否
为什么不建议生产用 Redis 主从模式?
高性能消息中间件——NATS
详解:Nginx 反代实现 Kibana 登录认证功能
分布式系统关注点:仅需这一篇,吃透 “负载均衡” 妥妥的
仅需这一篇,妥妥的吃透” 负载均衡”
基于 nginx 实现上游服务器动态自动上下线——不需 reload
Nginx 学习书单整理
最常见的日志收集架构(ELK Stack)
分布式之 elk 日志架构的演进
CAT 3.0 开源发布,支持多语言客户端及多项性能提升
Kafka 如何做到 1 秒处理 1500 万条消息?
Grafana 与 Kibana
ELK 日志系统之通用应用程序日志接入方案
ELK 简易 Nginx 日志系统搭建: ElasticSearch+Kibana+Filebeat
记一次 Redis 连接池问题引发的 RST
把 Redis 当作队列来用,你好大的胆子……
Redis 最佳实践:业务层面和运维层面优化
Redis 为什么变慢了?常见延迟问题定位与分析
好饭不怕晚,扒一下 Redis 配置文件的底 Ku
rabbitmq 集群搭建以及万级并发下的性能调优
别再问我 Redis 内存满了该怎么办了
Nginx 状态监控及日志分析
uWSGI 的安装及配置详解
uwsgi 异常服务器内存 cpu 爆满优化思路
Uwsgi 内存占用过多 - 简书
Nginx 的 limit 模块
Nginx 内置模块简介
Redis 忽然变慢了如何排查并解决?_redis_码哥字节_InfoQ 写作社区
领导:谁再用 redis 过期监听实现关闭订单,立马滚蛋!
Nginx 限制 IP 访问频率以及白名单配置_问轩博客
Nginx $remote_addr 和 $proxy_add_x_forwarded_for 变量详解
Caddy 部署实践
一文搞定 Nginx 限流
数据库
SqlServer 将数据库中的表复制到另一个数据库_MsSql_脚本之家
SQL Server 数据库同步,订阅、发布、复制、跨服务器
sql server 无法删除本地发布 | 辉克's Blog
SQLite全文检索
SQL 重复记录查询的几种方法 - 简书
SQL SERVER 使用订阅发布同步数据库(转)
Mysql 查看用户连接数配置及每个 IP 的请求情况 - 墨天轮
优化 SQL 的 21 条方案
SQL Server 连接时好时坏的奇怪问题
MS SQL 执行大脚本文件时,提示 “内存不足” 的解决办法 - 阿里云开发者社区
防火墙-iptables
iptables 常用规则:屏蔽 IP 地址、禁用 ping、协议设置、NAT 与转发、负载平衡、自定义链
防火墙 iptables 企业防火墙之 iptables
Linux 防火墙 ufw 简介
在 Ubuntu 中用 UFW 配置防火墙
在 Ubuntu20.04 上怎样使用 UFW 配置防火墙 - 技术库存网
监控类
开箱即用的 Prometheus 告警规则集
prometheus☞搭建 | zyh
docker 部署 Prometheus 监控服务器及容器并发送告警 | chris'wang
PromQL 常用命令 | LRF 成长记
prometheus 中使用 python 手写 webhook 完成告警
持续集成CI/CD
GitHub Actions 的应用场景 | 记录干杯
GithubActions · Mr.li's Blog
工具类
GitHub 中的开源网络广告杀手,十分钟快速提升网络性能
SSH-Auditor:一款 SHH 弱密码探测工具
别再找了,Github 热门开源富文本编辑器,最实用的都在这里了 - srcmini
我最喜欢的 CLI 工具
推荐几款 Redis 可视化工具
内网代理工具与检测方法研究
环境篇:数据同步工具 DataX
全能系统监控工具 dstat
常用 Web 安全扫描工具合集
给你一款利器!轻松生成 Nginx 配置文件
教程类
Centos7 搭建神器 openvpn | 运维随笔
搭建 umami 收集个人网站统计数据 | Reorx’s Forge
openvpn安装教程
基于 gitea+drone 完成小团队的 CI/CD - 德国粗茶淡饭
将颜色应用于交替行或列
VMware Workstation 全系列合集 精简安装注册版 支持 SLIC2.6、MSDM、OSX 更新 16.2.3_虚拟机讨论区_安全区 卡饭论坛 - 互助分享 - 大气谦和!
在 OpenVPN 上启用 AD+Google Authenticator 认证 | 运维烂笔头
Github 进行 fork 后如何与原仓库同步:重新 fork 很省事,但不如反复练习版本合并 · Issue #67 · selfteaching/the-craft-of-selfteaching
卧槽,VPN 又断开了!!- 阿里云开发者社区
Grafana Loki 学习之踩坑记
zerotier 的 planet 服务器(根服务器)的搭建踩坑记。无需 zerotier 官网账号。
阿里云 qcow2 镜像转 vmdk,导入 ESXi - 唐际忠的博客
Caddy 入门 – 又见杜梨树
【Caddy2】最新 Caddy2 配置文件解析 - Billyme 的博客
Web 服务器 Caddy 2 | Haven200
手把手教你打造高效的 Kubernetes 命令行终端
Keras 作者:给软件开发者的 33 条黄金法则
超详细的网络抓包神器 Tcpdump 使用指南
使用 fail2ban 和 FirewallD 黑名单保护你的系统
linux 下 mysql 数据库单向同步配置方法分享 (Mysql)
MySQL 快速删除大量数据(千万级别)的几种实践方案
GitHub 上的优质 Linux 开源项目,真滴牛逼!
WireGuard 教程:使用 Netmaker 来管理 WireGuard 的配置 – 云原生实验室 - Kubernetes|Docker|Istio|Envoy|Hugo|Golang | 云原生
Tailscale 基础教程:Headscale 的部署方法和使用教程 – 云原生实验室 - Kubernetes|Docker|Istio|Envoy|Hugo|Golang | 云原生
Nebula Graph 的 Ansible 实践
改进你的 Ansible 剧本的 4 行代码
Caddy 2 快速简单安装配置教程 – 高玩梁的博客
切换至 Caddy2 | 某不科学的博客
Caddy2 简明教程 - bleem
树莓派安装 OpenWrt 突破校园网限制 | Asttear's Blog
OpenVPN 路由设置 – 凤曦的小窝
个性化编译 LEDE 固件
盘点各种 Windows/Office 激活工具
[VirtualBox] 1、NAT 模式下端口映射
VirtualBox 虚拟机安装 openwrt 供本机使用
NUC 折腾笔记 - 安装 ESXi 7 - 苏洋博客
锐捷、赛尔认证 MentoHUST - Ubuntu 中文
How Do I Use A Client Certificate And Private Key From The IOS Keychain? | OpenVPN
比特记事簿: 笔记: 使用电信 TR069 内网架设 WireGuard 隧道异地组网
利用 GitHub API 获取最新 Releases 的版本号 | 这是只兔子
docsify - 生成文档网站简单使用教程 - SegmentFault 思否
【干货】Chrome 插件 (扩展) 开发全攻略 - 好记的博客
一看就会的 GitHub 骚操作,让你看上去像一位开源大佬
【计算机网络】了解内网、外网、宽带、带宽、流量、网速_墩墩分墩 - CSDN 博客
mac-ssh 配置 | Sail
如何科学管理你的密码
VirtualBox NAT 端口映射实现宿主机与虚拟机相互通信 | Shao Guoliang 的博客
CentOS7 配置网卡为静态 IP,如果你还学不会那真的没有办法了!
laisky-blog: 近期折腾 tailscale 的一些心得
使用 acme.sh 给 Nginx 安装 Let’ s Encrypt 提供的免费 SSL 证书 · Ruby China
acme 申请 Let’s Encrypt 泛域名 SSL 证书
从 nginx 迁移到 caddy
使用 Caddy 替代 Nginx,全站升级 https,配置更加简单 - Diamond-Blog
http.proxy - Caddy 中文文档
动手撸个 Caddy(二)| Caddy 命令行参数最全教程 | 飞雪无情的总结
Caddy | 学习笔记 - ijayer
Caddy 代理 SpringBoot Fatjar 应用上传静态资源
使用 graylog3.0 收集 open××× 日志进行审计_年轻人,少吐槽,多搬砖的技术博客_51CTO 博客
提高国内访问 github 速度的 9 种方法! - SegmentFault 思否
VM16 安装 macOS 全网最详细
2022 目前三种有效加速国内 Github
How to install MariaDB on Alpine Linux | LibreByte
局域网内电脑 - ipad 文件共享的三种方法 | 岚
多机共享键鼠软件横向测评 - 尚弟的小笔记
VLOG | ESXI 如何升级到最新版,无论是 6.5 还是 6.7 版本都可以顺滑升级。 – Vedio Talk - VLOG、科技、生活、乐分享
远程修改 ESXi 6.7 管理 IP 地址 - 腾讯云开发者社区 - 腾讯云
几乎不要钱自制远程 PLC 路由器方案
traefik 简易入门 | 个人服务器运维指南 | 山月行
更完善的 Docker + Traefik 使用方案 - 苏洋博客
MicroSD·TF 卡终极探秘 ·MLC 颗粒之谜 1 三星篇_microSD 存储卡_什么值得买
macOS 绕过公证和应用签名方法 - 走客
MiscSecNotes / 内网端口转发及穿透. md at master · JnuSimba/MiscSecNotes
我有特别的 DNS 配置和使用技巧 | Sukka's Blog
SEO:初学者完整指南
通过 OpenVPN 实现流量审计
OpenVPN-HOWTO
OpenVPN Server · Devops Roadmap
Linux 运维必备的 13 款实用工具, 拿好了~
linux 平台下 Tomcat 的安装与优化
Linux 运维跳槽必备的 40 道面试精华题
Bash 脚本进阶,经典用法及其案例 - alonghub - 博客园
推荐几个非常不错的富文本编辑器 - 走看看
在 JS 文件中加载 JS 文件的方法 - 月光博客
#JavaScript 根据需要动态加载脚本并设置自定义参数
笔记本电脑 BIOS 修改及刷写教程
跨平台加密 DNS 和广告过滤 personalDNSfilter · LinuxTOY
AdGuard Home 安装及使用指北
通过 Amazon S3 协议挂载 OSS
记一次云主机如何挂载对象存储
本文档发布于https://mrdoc.fun
-
+
首页
把 Redis 当作队列来用,你好大的胆子……
> 本文由 [简悦 SimpRead](http://ksria.com/simpread/) 转码, 原文地址 [www.tuicool.com](https://www.tuicool.com/articles/7NbInmI) 前言 经常听到很多人讨论,关于「把 Redis 当作队列来用是否合适」的问题。 有些人表示赞成,他们认为 Redis 很轻量,用作队列很方便。 也些人则反对,认为 Redis 会「丢」数据,最好还是用「专业」的队列中间件更稳妥。 究竟哪种方案更好呢? 这篇文章,我就和你聊一聊把 Redis 当作队列,究竟是否合适这个问题。 我会从简单到复杂,一步步带你梳理其中的细节,把这个问题真正的讲清楚。 看完这篇文章后,我希望你对这个问题你会有全新的认识。 在文章的最后,我还会告诉你关于「技术选型」的思路,文章有点长,希望你可以耐心读完。 ![](https://img2.tuicool.com/meiUZbA.png!web) 一、从最简单的开始:List 队列 首先,我们先从最简单的场景开始讲起。 如果你的业务需求足够简单,想把 Redis 当作队列来使用,肯定最先想到的就是使用 List 这个数据类型。 因为 List 底层的实现就是一个「链表」,在头部和尾部操作元素,时间复杂度都是 O(1),这意味着它非常符合消息队列的模型。 如果把 List 当作队列,你可以这么来用。 生产者使用 LPUSH 发布消息: ``` 127.0.0.1:6379> LPUSH queue msg1 ``` 消费者这一侧,使用 RPOP 拉取消息: ``` (integer) 1 ``` 这个模型非常简单,也很容易理解。 ![](https://img0.tuicool.com/iYbQ3ab.jpg!web) 但这里有个小问题,当队列中已经没有消息了,消费者在执行 RPOP 时,会返回 NULL。 ``` 127.0.0.1:6379> LPUSH queue msg2 ``` 而我们在编写消费者逻辑时,一般是一个「死循环」,这个逻辑需要不断地从队列中拉取消息进行处理,伪代码一般会这么写: ``` (integer) 2 ``` 如果此时队列为空,那消费者依旧会频繁拉取消息,这会造成「CPU 空转」,不仅浪费 CPU 资源,还会对 Redis 造成压力。 怎么解决这个问题呢? 也很简单,当队列为空时,我们可以「休眠」一会,再去尝试拉取消息。代码可以修改成这样: ``` 127.0.0.1:6379> RPOP queue ``` 这就解决了 CPU 空转问题。 这个问题虽然解决了,但又带来另外一个问题:当消费者在休眠等待时,有新消息来了,那消费者处理新消息就会存在「延迟」。 假设设置的休眠时间是 2s,那新消息最多存在 2s 的延迟。 要想缩短这个延迟,只能减小休眠的时间。但休眠时间越小,又有可能引发 CPU 空转问题。 鱼和熊掌不可兼得。 那如何做,既能及时处理新消息,还能避免 CPU 空转呢? Redis 是否存在这样一种机制:如果队列为空,消费者在拉取消息时就「阻塞等待」,一旦有新消息过来,就通知我的消费者立即处理新消息呢? 幸运的是,Redis 确实提供了「阻塞式」拉取消息的命令:BRPOP / BLPOP,这里的 B 指的是阻塞(Block)。 ![](https://img1.tuicool.com/AnQjEvE.jpg!web) 现在,你可以这样来拉取消息了: ``` "msg1" ``` 使用 BRPOP 这种阻塞式方式拉取消息时,还支持传入一个「超时时间」,如果设置为 0,则表示不设置超时,直到有新消息才返回,否则会在指定的超时时间后返回 NULL。 这个方案不错,既兼顾了效率,还避免了 CPU 空转问题,一举两得。 注意:如果设置的超时时间太长,这个连接太久没有活跃过,可能会被 Redis Server 判定为无效连接,之后 Redis Server 会强制把这个客户端踢下线。所以,采用这种方案,客户端要有重连机制。 解决了消息处理不及时的问题,你可以再思考一下,这种队列模型,有什么缺点? 我们一起来分析一下: * 不支持重复消费: 消费者拉取消息后,这条消息就从 List 中删除了,无法被其它消费者再次消费,即不支持多个消费者消费同一批数据 * 消息丢失: 消费者拉取到消息后,如果发生异常宕机,那这条消息就丢失了 第一个问题是功能上的,使用 List 做消息队列,它仅仅支持最简单的,一组生产者对应一组消费者,不能满足多组生产者和消费者的业务场景。 第二个问题就比较棘手了,因为从 List 中 POP 一条消息出来后,这条消息就会立即从链表中删除了。也就是说,无论消费者是否处理成功,这条消息都没办法再次消费了。 这也意味着,如果消费者在处理消息时异常宕机,那这条消息就相当于丢失了。 针对这 2 个问题怎么解决呢?我们一个个来看。 二、发布 / 订阅模型:Pub/Sub 从名字就能看出来,这个模块是 Redis 专门是针对「发布 / 订阅」这种队列模型设计的。 它正好可以解决前面提到的第一个问题:重复消费。 即多组生产者、消费者的场景,我们来看它是如何做的。 Redis 提供了 PUBLISH / SUBSCRIBE 命令,来完成发布、订阅的操作。 ![](https://img0.tuicool.com/VfUreym.jpg!web) 假设你想开启 2 个消费者,同时消费同一批数据,就可以按照以下方式来实现。 首先,使用 SUBSCRIBE 命令,启动 2 个消费者,并「订阅」同一个队列。 ``` 127.0.0.1:6379> RPOP queue ``` 此时,2 个消费者都会被阻塞住,等待新消息的到来。 之后,再启动一个生产者,发布一条消息。 ``` "msg2" ``` 这时,2 个消费者就会解除阻塞,收到生产者发来的新消息。 ``` 127.0.0.1:6379> RPOP queue ``` 看到了么,使用 Pub/Sub 这种方案,既支持阻塞式拉取消息,还很好地满足了多组消费者,消费同一批数据的业务需求。 除此之外,Pub/Sub 还提供了「匹配订阅」模式,允许消费者根据一定规则,订阅「多个」自己感兴趣的队列。 ``` (nil) // 没消息了 ``` 这里的消费者,订阅了 queue.* 相关的队列消息。 之后,生产者分别向 queue.p1 和 queue.p2 发布消息。 ``` while true: ``` 这时再看消费者,它就可以接收到这 2 个生产者的消息了。 ``` msg = redis.rpop("queue") ``` ![](https://img2.tuicool.com/aIVNba7.jpg!web) 我们可以看到,Pub/Sub 最大的优势就是,支持多组生产者、消费者处理消息。 讲完了它的优点,那它有什么缺点呢? 其实,Pub/Sub 最大问题是: **丢数据** 。 如果发生以下场景,就有可能导致数据丢失: * 消费者下线 * Redis 宕机 * 消息堆积 究竟是怎么回事? 这其实与 Pub/Sub 的实现方式有很大关系。 Pub/Sub 在实现时非常简单,它没有基于任何数据类型,也没有做任何的数据存储,它只是单纯地为生产者、消费者建立「数据转发通道」,把符合规则的数据,从一端转发到另一端。 一个完整的发布、订阅消息处理流程是这样的: * 消费者订阅指定队列,Redis 就会记录一个映射关系:队列 -> 消费者 * 生产者向这个队列发布消息,那 Redis 就从映射关系中找出对应的消费者,把消息转发给它 ![](https://img1.tuicool.com/EzABFre.jpg!web) 看到了么,整个过程中,没有任何的数据存储,一切都是实时转发的。 这种设计方案,就导致了上面提到的那些问题。 例如,如果一个消费者异常挂掉了,它再重新上线后,只能接收新的消息,在下线期间生产者发布的消息,因为找不到消费者,都会被丢弃掉。 如果所有消费者都下线了,那生产者发布的消息,因为找不到任何一个消费者,也会全部「丢弃」。 所以,当你在使用 Pub/Sub 时,一定要注意: 消费者必须先订阅队列,生产者才能发布消息,否则消息会丢失。 这也是前面讲例子时,我们让消费者先订阅队列,之后才让生产者发布消息的原因。 另外,因为 Pub/Sub 没有基于任何数据类型实现,所以它也不具备「数据持久化」的能力。 也就是说,Pub/Sub 的相关操作,不会写入到 RDB 和 AOF 中,当 Redis 宕机重启,Pub/Sub 的数据也会全部丢失。 最后,我们来看 Pub/Sub 在处理「消息积压」时,为什么也会丢数据? 当消费者的速度,跟不上生产者时,就会导致数据积压的情况发生。 如果采用 List 当作队列,消息积压时,会导致这个链表很长,最直接的影响就是,Redis 内存会持续增长,直到消费者把所有数据都从链表中取出。 但 Pub/Sub 的处理方式却不一样,当消息积压时,有可能会导致 **消费失败和消息丢失!** 这是怎么回事? 还是回到 Pub/Sub 的实现细节上来说。 每个消费者订阅一个队列时,Redis 都会在 Server 上给这个消费者在分配一个「缓冲区」,这个缓冲区其实就是一块内存。 当生产者发布消息时,Redis 先把消息写到对应消费者的缓冲区中。 之后,消费者不断地从缓冲区读取消息,处理消息。 ![](https://img2.tuicool.com/AR7JjmU.jpg!web) 但是,问题就出在这个缓冲区上。 因为这个缓冲区其实是有「上限」的(可配置),如果消费者拉取消息很慢,就会造成生产者发布到缓冲区的消息开始积压,缓冲区内存持续增长。 如果超过了缓冲区配置的上限,此时,Redis 就会「强制」把这个消费者踢下线。 这时消费者就会消费失败,也会丢失数据。 如果你有看过 Redis 的配置文件,可以看到这个缓冲区的默认配置:client-output-buffer-limit pubsub 32mb 8mb 60。 它的参数含义如下: * 32mb:缓冲区一旦超过 32MB,Redis 直接强制把消费者踢下线 * 8mb + 60:缓冲区超过 8MB,并且持续 60 秒,Redis 也会把消费者踢下线 Pub/Sub 的这一点特点,是与 List 作队列差异比较大的。 从这里你应该可以看出, List 其实是属于「拉」模型,而 Pub/Sub 其实属于「推」模型。 List 中的数据可以一直积压在内存中,消费者什么时候来「拉」都可以。 但 Pub/Sub 是把消息先「推」到消费者在 Redis Server 上的缓冲区中,然后等消费者再来取。 当生产、消费速度不匹配时,就会导致缓冲区的内存开始膨胀,Redis 为了控制缓冲区的上限,所以就有了上面讲到的,强制把消费者踢下线的机制。 好了,现在我们总结一下 Pub/Sub 的优缺点: * 支持发布 / 订阅,支持多组生产者、消费者处理消息 * 消费者下线,数据会丢失 * 不支持数据持久化,Redis 宕机,数据也会丢失 * 消息堆积,缓冲区溢出,消费者会被强制踢下线,数据也会丢失 有没有发现,除了第一个是优点之外,剩下的都是缺点。 所以,很多人看到 Pub/Sub 的特点后,觉得这个功能很「鸡肋」。 也正是以上原因,Pub/Sub 在实际的应用场景中用得并不多。 目前只有哨兵集群和 Redis 实例通信时,采用了 Pub/Sub 的方案,因为哨兵正好符合即时通讯的业务场景。 我们再来看一下,Pub/Sub 有没有解决,消息处理时异常宕机,无法再次消费的问题呢? 其实也不行,Pub/Sub 从缓冲区取走数据之后,数据就从 Redis 缓冲区删除了,消费者发生异常,自然也无法再次重新消费。 好,现在我们重新梳理一下,我们在使用消息队列时的需求。 当我们在使用一个消息队列时,希望它的功能如下: * 支持阻塞等待拉取消息 * 支持发布 / 订阅模式 * 消费失败,可重新消费,消息不丢失 * 实例宕机,消息不丢失,数据可持久化 * 消息可堆积 Redis 除了 List 和 Pub/Sub 之外,还有符合这些要求的数据类型吗? 其实,Redis 的作者也看到了以上这些问题,也一直在朝着这些方向努力着。 Redis 作者在开发 Redis 期间,还另外开发了一个开源项目 disque。 这个项目的定位,就是一个基于内存的分布式消息队列中间件。 但由于种种原因,这个项目一直不温不火。 终于,在 Redis 5.0 版本,作者把 disque 功能移植到了 Redis 中,并给它定义了一个新的数据类型: **Stream** 。 下面我们就来看看,它能符合上面提到的这些要求吗? 三、趋于成熟的队列:Stream 我们来看 Stream 是如何解决上面这些问题的。 我们依旧从简单到复杂,依次来看 Stream 在做消息队列时,是如何处理的? 首先,Stream 通过 XADD 和 XREAD 完成最简单的生产、消费模型: * XADD:发布消息 * XREAD:读取消息 生产者发布 2 条消息: ``` // 没有消息,继续循环 ``` 使用 XADD 命令发布消息,其中的「*」表示让 Redis 自动生成唯一的消息 ID。 这个消息 ID 的格式是「时间戳 - 自增序号」。 消费者拉取消息: ``` if msg == null: ``` 如果想继续拉取消息,需要传入上一条消息的 ID: ``` continue ``` 没有消息,Redis 会返回 NULL。 ![](https://img2.tuicool.com/eIzaYbM.jpg!web) 以上就是 Stream 最简单的生产、消费。 这里不再重点介绍 Stream 命令的各种参数,我在例子中演示时,凡是大写的单词都是「固定」参数,凡是小写的单词,都是可以自己定义的,例如队列名、消息长度等等,下面的例子规则也是一样,为了方便你理解,这里有必要提醒一下。 下面我们来看,针对前面提到的消息队列要求,Stream 都是如何解决的? **1、Stream 是否支持「阻塞式」拉取消息?** 可以的,在读取消息时,只需要增加 BLOCK 参数即可。 ``` // 处理消息 ``` 这时,消费者就会阻塞等待,直到生产者发布新的消息才会返回。 **2、Stream 是否支持发布 / 订阅模式?** 也没问题,Stream 通过以下命令完成发布订阅: * XGROUP:创建消费者组 * XREADGROUP:在指定消费组下,开启消费者拉取消息 下面我们来看具体如何做? 首先,生产者依旧发布 2 条消息: ``` handle(msg) ``` 之后,我们想要开启 2 组消费者处理同一批数据,就需要创建 2 个消费者组: ``` while true: ``` 消费者组创建好之后,我们可以给每个「消费者组」下面挂一个「消费者」,让它们分别处理同一批数据。 第一个消费组开始消费: ``` msg = redis.rpop("queue") ``` 同样地,第二个消费组开始消费: ``` // 没有消息,休眠2s ``` 我们可以看到,这 2 组消费者,都可以获取同一批数据进行处理了。 这样一来,就达到了多组消费者「订阅」消费的目的。 ![](https://img0.tuicool.com/2yEvIrU.jpg!web) 3、消息处理时异常,Stream 能否保证消息不丢失,重新消费? 除了上面拉取消息时用到了消息 ID,这里为了保证重新消费,也要用到这个消息 ID。 当一组消费者处理完消息后,需要执行 XACK 命令告知 Redis,这时 Redis 就会把这条消息标记为「处理完成」。 ``` if msg == null: ``` ![](https://img2.tuicool.com/Abe6JjE.jpg!web) 如果消费者异常宕机,肯定不会发送 XACK,那么 Redis 就会依旧保留这条消息。 待这组消费者重新上线后,Redis 就会把之前没有处理成功的数据,重新发给这个消费者。这样一来,即使消费者异常,也不会丢失数据了。 ``` sleep(2) ``` **4、Stream 数据会写入到 RDB 和 AOF 做持久化吗?** Stream 是新增加的数据类型,它与其它数据类型一样,每个写操作,也都会写入到 RDB 和 AOF 中。 我们只需要配置好持久化策略,这样的话,就算 Redis 宕机重启,Stream 中的数据也可以从 RDB 或 AOF 中恢复回来。 **5、消息堆积时,Stream 是怎么处理的?** 其实,当消息队列发生消息堆积时,一般只有 2 个解决方案: * 生产者限流:避免消费者处理不及时,导致持续积压 * 丢弃消息:中间件丢弃旧消息,只保留固定长度的新消息 而 Redis 在实现 Stream 时,采用了第 2 个方案。 在发布消息时,你可以指定队列的最大长度,防止队列积压导致内存爆炸。 ``` continue ``` 当队列长度超过上限后,旧消息会被删除,只保留固定长度的新消息。 这么来看,Stream 在消息积压时,如果指定了最大长度,还是有可能丢失消息的。 除了以上介绍到的命令,Stream 还支持查看消息长度(XLEN)、查看消费者状态(XINFO)等命令,使用也比较简单,你可以查询官方文档了解一下,这里就不过多介绍了。 好了,通过以上介绍,我们可以看到,Redis 的 Stream 几乎覆盖到了消息队列的各种场景,是不是觉得很完美? #### 既然它的功能这么强大,这是不是意味着,Redis 真的可以作为专业的消息队列中间件来使用呢? 但是还「差一点」,就算 Redis 能做到以上这些,也只是「趋近于」专业的消息队列。 原因在于 Redis 本身的一些问题,如果把其定位成消息队列,还是有些欠缺的。 到这里,就不得不把 Redis 与专业的队列中间件做对比了。 下面我们就来看一下,Redis 在作队列时,到底还有哪些欠缺? 四、与专业的消息队列对比 其实,一个专业的消息队列,必须要做到两大块: * 消息不丢 * 消息可堆积 前面我们讨论的重点,很大篇幅围绕的是第一点展开的。 这里我们换个角度,从一个消息队列的「使用模型」来分析一下,怎么做,才能保证数据不丢? 使用一个消息队列,其实就分为三大块: **生产者、队列中间件、消费者。** ![](https://img0.tuicool.com/F3EfQfJ.jpg!web) 消息是否会发生丢失,其重点也就在于以下 3 个环节: * 生产者会不会丢消息? * 消费者会不会丢消息? * 队列中间件会不会丢消息? **1、生产者会不会丢消息?** 当生产者在发布消息时,可能发生以下异常情况: * 消息没发出去:网络故障或其它问题导致发布失败,中间件直接返回失败 * 不确定是否发布成功:网络问题导致发布超时,可能数据已发送成功,但读取响应结果超时了 如果是情况 1,消息根本没发出去,那么重新发一次就好了。 如果是情况 2,生产者没办法知道消息到底有没有发成功?所以,为了避免消息丢失,它也只能继续重试,直到发布成功为止。 生产者一般会设定一个最大重试次数,超过上限依旧失败,需要记录日志报警处理。 也就是说,生产者为了避免消息丢失,只能采用失败重试的方式来处理。 但发现没有?这也意味着消息可能会重复发送。 是的,在使用消息队列时,要保证消息不丢,宁可重发,也不能丢弃。 那消费者这边,就需要多做一些逻辑了。 对于敏感业务,当消费者收到重复数据数据时,要设计幂等逻辑,保证业务的正确性。 从这个角度来看,生产者会不会丢消息,取决于生产者对于异常情况的处理是否合理。 所以,无论是 Redis 还是专业的队列中间件,生产者在这一点上都是可以保证消息不丢的。 **2、消费者会不会丢消息?** 这种情况就是我们前面提到的,消费者拿到消息后,还没处理完成,就异常宕机了,那消费者还能否重新消费失败的消息? 要解决这个问题,消费者在处理完消息后,必须「告知」队列中间件,队列中间件才会把标记已处理,否则仍旧把这些数据发给消费者。 这种方案需要消费者和中间件互相配合,才能保证消费者这一侧的消息不丢。 无论是 Redis 的 Stream,还是专业的队列中间件,例如 RabbitMQ、Kafka,其实都是这么做的。 所以,从这个角度来看,Redis 也是合格的。 **3、队列中间件会不会丢消息?** 前面 2 个问题都比较好处理,只要客户端和服务端配合好,就能保证生产端、消费端都不丢消息。 但是,如果队列中间件本身就不可靠呢? 毕竟生产者和消费这都依赖它,如果它不可靠,那么生产者和消费者无论怎么做,都无法保证数据不丢。 在这个方面,Redis 其实没有达到要求。 Redis 在以下 2 个场景下,都会导致数据丢失。 * AOF 持久化配置为每秒写盘,但这个写盘过程是异步的,Redis 宕机时会存在数据丢失的可能 * 主从复制也是异步的,主从切换时,也存在丢失数据的可能(从库还未同步完成主库发来的数据,就被提成主库) 基于以上原因我们可以看到, **Redis 本身的无法保证严格的数据完整性。** 所以,如果把 Redis 当做消息队列,在这方面是有可能导致数据丢失的。 再来看那些专业的消息队列中间件是如何解决这个问题的? 像 RabbitMQ 或 Kafka 这类专业的队列中间件,在使用时,一般是部署一个集群,生产者在发布消息时,队列中间件通常会写「多个节点」,以此保证消息的完整性。这样一来,即便其中一个节点挂了,也能保证集群的数据不丢失。 也正因为如此,RabbitMQ、Kafka 在设计时也更复杂。毕竟,它们是专门针对队列场景设计的。 但 Redis 的定位则不同,它的定位更多是当作缓存来用,它们两者在这个方面肯定是存在差异的。 最后,我们来看消息积压怎么办? **4、消息积压怎么办?** 因为 Redis 的数据都存储在内存中,这就意味着一旦发生消息积压,则会导致 Redis 的内存持续增长,如果超过机器内存上限,就会面临被 OOM 的风险。 所以,Redis 的 Stream 提供了可以指定队列最大长度的功能,就是为了避免这种情况发生。 但 Kafka、RabbitMQ 这类消息队列就不一样了,它们的数据都会存储在磁盘上,磁盘的成本要比内存小得多,当消息积压时,无非就是多占用一些磁盘空间,相比于内存,在面对积压时也会更加「坦然」。 综上,我们可以看到,把 Redis 当作队列来使用时,始终面临的 2 个问题: * Redis 本身可能会丢数据 * 面对消息积压,Redis 内存资源紧张 到这里,Redis 是否可以用作队列,我想这个答案你应该会比较清晰了。 如果你的业务场景足够简单,对于数据丢失不敏感,而且消息积压概率比较小的情况下,把 Redis 当作队列是完全可以的。 而且,Redis 相比于 Kafka、RabbitMQ,部署和运维也更加轻量。 如果你的业务场景对于数据丢失非常敏感,而且写入量非常大,消息积压时会占用很多的机器资源,那么我建议你使用专业的消息队列中间件。 五、总结 好了,总结一下。这篇文章我们从「Redis 能否用作队列」这个角度出发,介绍了 List、Pub/Sub、Stream 在做队列的使用方式,以及它们各自的优劣。 之后又把 Redis 和专业的消息队列中间件做对比,发现 Redis 的不足之处。 最后,我们得出 Redis 做队列的合适场景。 这里我也列了一个表格,总结了它们各自的优缺点。 后记 最后,我想和你再聊一聊关于 **「技术方案选型」** 的问题。 你应该也看到了,这篇文章虽然始于 Redis,但并不止于 Redis。 我们在分析 Redis 细节时,一直在提出问题,然后寻找更好的解决方案,在文章最后,又聊到一个专业的消息队列应该怎么做。 其实,我们在讨论技术选型时,就是一个关于如何取舍的问题。 而这里我想传达给你的信息是, 在面对技术选型时,不要不经过思考就觉得哪个方案好,哪个方案不好 。 你需要根据具体场景具体分析,这里我把这个分析过程分为 2 个层面: * 业务功能角度 * 技术资源角度 这篇文章所讲到的内容,都是以业务功能角度出发做决策的。 但这里的第二点,从技术资源角度出发,其实也很重要。 技术资源的角度是说, **你所处的公司环境、技术资源能否匹配这些技术方案。** 这个怎么解释呢? 简单来讲,就是你所在的公司、团队,是否有匹配的资源能 hold 住这些技术方案。 我们都知道 Kafka、RabbitMQ 是非常专业的消息中间件,但它们的部署和运维,相比于 Redis 来说,也会更复杂一些。 如果你在一个大公司,公司本身就有优秀的运维团队,那么使用这些中间件肯定没问题,因为有足够优秀的人能 hold 住这些中间件,公司也会投入人力和时间在这个方向上。 但如果你是在一个初创公司,业务正处在快速发展期,暂时没有能 hold 住这些中间件的团队和人,如果贸然使用这些组件,当发生故障时,排查问题也会变得很困难,甚至会阻碍业务的发展。 而这种情形下,如果公司的技术人员对于 Redis 都很熟,综合评估来看,Redis 也基本可以满足业务 90% 的需求,那当下选择 Redis 未必不是一个好的决策。 所以, 做技术选型不只是技术问题,还与人、团队、管理、组织结构有关。 也正是因为这些原因,当你在和别人讨论技术选型问题时,你会发现每个公司的做法都不相同。 毕竟每个公司所处的环境和文化不一样,做出的决策当然就会各有差异。 如果你不了解这其中的逻辑,那在做技术选型时,只会趋于表面现象,无法深入到问题根源。 而一旦你理解了这个逻辑,那么你在看待这个问题时,不仅对于技术会有更加深刻认识,对技术资源和人的把握,也会更加清晰。 希望你以后在做技术选型时,能够把这些因素也考虑在内,这对你的技术成长之路也是非常有帮助的。 作者丨 Magic Kaito 来源丨公众号:水滴与银弹(ID:waterdrop_bullet) dbaplus 社群欢迎广大技术人员投稿,投稿邮箱: editor@dbaplus.cn ![](https://img2.tuicool.com/qQVjqiZ.jpg!web)
Jonny
May 4, 2022, 11:28 a.m.
155
0 条评论
转发文档
收藏文档
上一篇
下一篇
手机扫码
复制链接
手机扫一扫转发分享
复制链接
如遇文档失效,可评论告知,便后续更新!
【腾讯云】2核2G云服务器新老同享 99元/年,续费同价
【阿里云】2核2G云服务器新老同享 99元/年,续费同价(不要✓自动续费)
【腾讯云】2核2G云服务器新老同享 99元/年,续费同价
【阿里云】2核2G云服务器新老同享 99元/年,续费同价(不要✓自动续费)
Markdown文件
Word文件
PDF文档
PDF文档(打印)
分享
链接
类型
密码
更新密码
有效期