Kaito's Blog

致力成为一枚silver bullet.

0%

大家好,我是 Kaito。

我经常听到很多人讨论,关于「把 Redis 当作队列来用是否合适」的问题。

有些人表示赞成,他们认为 Redis 很轻量,用作队列很方便。

也些人则反对,认为 Redis 会「丢」数据,最好还是用「专业」的队列中间件更稳妥。

究竟哪种方案更好呢?

这篇文章,我就和你聊一聊把 Redis 当作队列,究竟是否合适这个问题。

我会从简单到复杂,一步步带你梳理其中的细节,把这个问题真正的讲清楚。

看完这篇文章后,我希望你对这个问题你会有全新的认识。

在文章的最后,我还会告诉你关于「技术选型」的思路,文章有点长,希望你可以耐心读完。

阅读全文 »

大家好,我是 Kaito。

这篇文章,我想和你聊一聊在使用 Redis 时,可能会踩到的「坑」。

如果你在使用 Redis 时,也遇到过以下这些「诡异」的场景,那很大概率是踩到「坑」了:

  • 明明一个 key 设置了过期时间,怎么变成不过期了?
  • 使用 O(1) 复杂度的 SETBIT 命令,Redis 竟然被 OOM 了?
  • 执行 RANDOMKEY 随机拿出一个 key,竟然也会阻塞 Redis?
  • 同样的命令,为什么主库查不到数据,从库却可以查到?
  • 从库内存为什么比主库用得还多?
  • 写入到 Redis 的数据,为什么莫名其妙丢了?

究竟是什么原因,导致的这些问题呢?

这篇文章,我就来和你盘点一下,使用 Redis 时可能会踩到「坑」,以及如何去规避。

阅读全文 »

大家好,我是 Kaito。

这篇文章我想和你聊一聊 Redis 的最佳实践。

你的项目或许已经使用 Redis 很长时间了,但在使用过程中,你可能还会或多或少地遇到以下问题:

  • 我的 Redis 内存为什么增长这么快?
  • 为什么我的 Redis 操作延迟变大了?
  • 如何降低 Redis 故障发生的频率?
  • 日常运维 Redis 需要注意什么?
  • 部署 Redis 时,如何做好资源规划?
  • Redis 监控重点要关注哪些指标?

尤其是当你的项目越来越依赖 Redis 时,这些问题就变得尤为重要。

此时,你迫切需要一份「最佳实践指南」

这篇文章,我将从以下七个维度,带你「全面」分析 Redis 的最佳实践优化:

  • 内存
  • 性能
  • 高可靠
  • 日常运维
  • 资源规划
  • 监控
  • 安全

在文章的最后,我还会给你一个完整的最佳实践清单,不管你是业务开发人员,还是 DBA 运维人员,这个清单将会帮助你更加「优雅」地用好 Redis。

这篇文章干货很多,希望你可以耐心读完。

阅读全文 »

大家好,我是 Kaito。

这篇文章我想和你聊一聊 Redis 的架构演化之路。

现如今 Redis 变得越来越流行,几乎在很多项目中都要被用到,不知道你在使用 Redis 时,有没有思考过,Redis 到底是如何稳定、高性能地提供服务的?

你也可以尝试回答一下以下这些问题:

  • 我使用 Redis 的场景很简单,只使用单机版 Redis 会有什么问题吗?
  • 我的 Redis 故障宕机了,数据丢失了怎么办?如何能保证我的业务应用不受影响?
  • 为什么需要主从集群?它有什么优势?
  • 什么是分片集群?我真的需要分片集群吗?

如果你对 Redis 已经有些了解,肯定也听说过数据持久化、主从复制、哨兵这些概念,它们之间又有什么区别和联系呢?

如果你存在这样的疑惑,这篇文章,我会从 0 到 1,再从 1 到 N,带你一步步构建出一个稳定、高性能的 Redis 集群。

在这个过程中,你可以了解到 Redis 为了做到稳定、高性能,都采取了哪些优化方案,以及为什么要这么做?

掌握了这些原理,这样平时你在使用 Redis 时,就能够做到「游刃有余」。

这篇文章干货很多,希望你可以耐心读完。

阅读全文 »

Redis 作为优秀的内存数据库,其拥有非常高的性能,单个实例的 OPS 能够达到 10W 左右。但也正因此如此,当我们在使用 Redis 时,如果发现操作延迟变大的情况,就会与我们的预期不符。

你也许或多或少地,也遇到过以下这些场景:

  • 在 Redis 上执行同样的命令,为什么有时响应很快,有时却很慢?
  • 为什么 Redis 执行 SET、DEL 命令耗时也很久?
  • 为什么我的 Redis 突然慢了一波,之后又恢复正常了?
  • 为什么我的 Redis 稳定运行了很久,突然从某个时间点开始变慢了?

如果你并不清楚 Redis 内部的实现原理,那么在排查这种延迟问题时就会一头雾水。

如果你也遇到了以上情况,那么,这篇文章将会给你一个「全面」的问题排查思路,并且针对这些导致变慢的场景,我还会给你一个高效的解决方案。

在正文开始之前,我需要提醒你的是,这篇文章很长,涵盖的 Redis 知识点也非常广,全篇文章接近 2W 字,如果此时你的阅读环境不适合专注阅读,我建议你先收藏此文章,然后在合适的时间专注阅读这篇文章。

如果你能耐心且认真地读完这篇文章,我可以保证,你对 Redis 的性能调优将会有非常大的收获。

如果你准备好了,那就跟着我的思路开始吧!

阅读全文 »

这篇文章首发在极客时间App《Redis核心技术与实战》专栏

写这篇文章的背景:

在极客时间App学习《Redis核心技术与实战》专栏时,由于我在评论区持续输出了高质量的内容,之后被此专栏邀请,为专栏供稿加餐内容。这是一篇帮助专栏读者如何高效学习的方法论分享。

另外一篇发表在此专栏的文章:《我是如何学习Redis的?高效学习Redis的路径和方法分享》

你好,我是Kaito。

上一次,我分享了我总结的Redis学习路径,在留言区的交流和互动中,我有了很多新的收获。今天,我想再分享一下我对学习这件事儿的认识以及我的学习方法,包括领先一步的心理建设、事半功倍的学习方法以及提升效率的小技巧。

领先一步:保持好奇+不设限

我认为,任何领域的学习,在研究具体的方法之前,我们都需要先在心理上领先别人一步。什么意思呢?其实就是要建立并保持好奇心,并且不给自己设限。

我发现,很多人是缺乏好奇心的,突出表现在只知其然,不知其所以然,不善于思考和挖掘问题。

给你举个小例子。刚开始接触Redis时,你肯定听说过一句话,Redis是单线程,高性能。很多人听完也就过去了,但是有好奇心的人,会进一步思考:“单线程如何处理多个客户端的网络请求呢?采用单线程的话,只能用到一个CPU核心,怎么达到高性能呢?”

顺着这个思路去学习的话,你就会发现,Redis虽然采用了单线程,但是它使用了多路复用技术,可以处理多个客户端的网络请求。而且,它的数据都存储在内存中,再加上高效的数据结构,所以处理每个请求的速度极快。

你看,带着好奇心去看问题,最终我们得到的远远超出想象。所以,我们要永远保持好奇心和深入探究的精神,它是我们不断进步的核心驱动力。

阅读全文 »

这篇文章首发在极客时间App《Redis核心技术与实战》专栏

写这篇文章的背景:

在极客时间App学习《Redis核心技术与实战》专栏时,由于我在评论区持续输出了高质量的内容,之后被此专栏邀请,为专栏供稿加餐内容。这是一篇帮助专栏读者如何高效学习Redis的知识总结分享。


你好,我是Kaito。

很荣幸受到极客时间编辑的邀请,来和你分享一下我学习Redis的方法,希望可以帮助你更加高效地学习Redis。

我先做个自我介绍。

从毕业到现在,我已经工作7年了,目前是北京的一家移动互联网公司的资深研发工程师。我之前主导设计过垂直爬虫采集平台,后来开发面向用户的后端服务系统,现在在从事基础架构和数据库中间件方面的研发工作,主要聚焦在跨数据中心数据层的灾备与多活方面的研发。主要技术栈是Golang。

阅读全文 »

之前我们提到,为了保证Redis的高可用,主要需要以下几个方面:

  • 数据持久化
  • 主从复制
  • 自动故障恢复
  • 集群化

我们简单理一下这几个方案的特点,以及它们之间的联系。

数据持久化本质上是为了做数据备份,有了数据持久化,当Redis宕机时,我们可以把数据从磁盘上恢复回来,但在数据恢复之前,服务是不可用的,而且数据恢复的时间取决于实例的大小,数据量越大,恢复起来越慢。Redis的持久化过程可以参考Redis持久化是如何做的?RDB和AOF对比分析

而主从复制则是部署多个副本节点,多个副本节点实时复制主节点的数据,当主节点宕机时,我们有完整的副本节点可以使用。另一方面,如果我们业务的读请求量很大,主节点无法承受所有的读请求,多个副本节点可以分担读请求,实现读写分离,这样可以提高Redis的访问性能。Redis主从复制的原理可以参考Redis的主从复制是如何做的?复制过程中也会产生各种问题?

但有个问题是,当主节点宕机时,我们虽然有完整的副本节点,但需要手动操作把从节点提升为主节点继续提供服务,如果每次主节点故障,都需要人工操作,这个过程既耗时耗力,也无法保证及时性,高可用的程度将大打折扣。如何优化呢?

阅读全文 »

在上一篇文章:Redis为什么变慢了?常见延迟问题定位与分析,主要分析了Redis常见的导致变慢的场景以及问题定位和分析,主要是由业务使用不合理和运维不当导致的。

我们在了解了导致Redis变慢的原因之后,针对性地优化,就可以让Redis稳定发挥出更高性能。

这篇文章我们就来总结一下,在使用Redis时的最佳实践方式,主要包含两个层面:业务层面、运维层面

由于我之前写过很多UGC后端服务,在大量场景下用到了Redis,这个过程中也踩过很多坑,所以在使用过程中也总结了一套合理的使用方法。

后来做基础架构,开发Codis、Redis相关的中间件,在这个阶段关注领域从使用层面下沉到Redis的开发和运维,更多聚焦在Redis的内部实现和运维过程中产生的各种问题,在这块也积累了一些经验。

下面就针对这两块,分享一下我认为比较合理的Redis使用和运维方法,不一定最全面,也可能与你使用Redis的方法不同,但以下这些方法都是我在踩坑之后总结的实际经验,供你参考。

阅读全文 »

重要提示:本篇文章写于2020年,后来内容经过迭代和完善,有了V2版本,内容更全面、细节更丰富,请直接看2021年写的这篇文章:Redis为什么变慢了?一文讲透如何排查Redis性能问题 | 万字长文

Redis作为内存数据库,拥有非常高的性能,单个实例的QPS能够达到10W左右。但我们在使用Redis时,经常时不时会出现访问延迟很大的情况,如果你不知道Redis的内部实现原理,在排查问题时就会一头雾水。

很多时候,Redis出现访问延迟变大,都与我们的使用不当或运维不合理导致的。

这篇文章我们就来分析一下Redis在使用过程中,经常会遇到的延迟问题以及如何定位和分析。

阅读全文 »