Redis 分布式锁的实现

在 Redis 的常见应用中,分布式锁是一个老生常谈的问题,本文主要讲讲怎么去实现一个分布式锁(最近真·写了不少 Lua 脚本)。

加锁

对于加锁操作,理论上应该是:

  1. 尝试加锁,如果成功,则记录锁,并且返回 true
  2. 如果失败,则不更新锁,返回 false

- 阅读剩余部分 -

限流与常见实现

限流也是一个系统中老生常谈的话题了,因为资源不是无限的,因此系统总会达到一个瓶颈,我们不可能接受无限的流量直到系统崩溃,于是也就有了限流策略。

多少流量该限流

一般来说,我们有几种方法可以来对系统进行评估:

- 阅读剩余部分 -

Redis 大 key、热 key 判别和解决方案

Redis 是我们常见的缓存解决方案,但是使用不当的 Redis 同样会造成系统瓶颈。

慢日志分析

要启用慢日志分析,首先先要对慢查询记录进行设置:

# 命令执行耗时超过 5 毫秒,记录慢日志 
CONFIG SET slowlog-log-slower-than 5000 
# 只保留最近 500 条慢日志
CONFIG SET slowlog-max-len 500

- 阅读剩余部分 -

缓存:高并发读的救世主

实在不知道该编什么名字,总之先复习一下缓存吧。本文讲的重点是服务端缓存,尤其是 Redis 相关的设计。

概述

众所周知的是,我们的业务数据多数都会选择存储在 DB 里,但数据库本身是一个吞吐量有限的单点,在实际的高并发场景下,我们肯定不可能让所有的流量都流向 DB,因此在这种情况下,业务往往会涉及一些缓存来缓解 DB 的压力。

具体的来说,从客户端到服务端,链路的每一个节点都能具有缓存的能力。比如客户端的 HTTP Cache、边缘节点的 CDN 缓存,再到服务端缓存,包括内存缓存、Redis 缓存等等,在开头我们说过,重点是服务端缓存,因此我们会对客户端缓存暂且不表。(反正一言以蔽之也就是强缓存和协商缓存)。

- 阅读剩余部分 -

如何解决服务中的事务问题

我们经常会被问到这样一个问题:在一个下单流程中,如何保证数据的一致性。

如果我们在单服务单库中运行,那么很简单,使用数据库的事务就可以了。

但是正常来说,现在的所有服务都会采用微服务的架构,也就是说一个下单流程中,「订单服务」到「库存锁定」到「生成账单」到「支付交易」到「回调变更状态」,这几步将会有多个服务来共同完成。

此时我们必然不能让用户的任何一步失败,又或者必须保证失败后回滚一定成功,否则用户钱扣了,交易却没成功;或者造成了超卖,这些都会造成严重客诉。

为此才会引入分布式事务这个概念,也就是保障多个事务之间的一致性,要么全部成功,要么全部失败。

- 阅读剩余部分 -

聊聊 MySQL 索引与索引设计

本文讲的都是比较基础的点,原理点到为止,适合人群为数据库小白,希望能够从数据库层面进行一些优化的同学。

最近在做旧项目改造的时候发现了很多不合理的索引设计,或者干脆就没有设计索引,开发者仿佛把在线业务的表当做了离线表那样想怎么查就怎么查,导致了整个接口相当缓慢,甚至有可能拖垮整个服务 / DB。

于是我发现一些很常规的优化似乎其实并不是每个人都很清楚,所以今天就来聊聊 SQL 的索引优化。

因为我们的项目都是 MySQL / MongoDB 的,而我基本也只学了 MySQL,因此这里以 MySQL 为主,MongoDB 为辅来进行索引设计的解读。

- 阅读剩余部分 -

Redis 中使用键空间监听 key 过期消息

距离上一次更新已经超过一个月了,是月更博主对不起大家了!

主要是因为之前有一阵子业务比较忙,因此一直在加班,没有空看其他的东西(又不愿意牺牲打游戏和看剧的时间),最近一有时间就在写 Demo,这几天刚写完,才能更新这篇文章。

背景故事

这个需求也是在我们业务落地过程中衍生出来的,因此先来说说之前一阵子忙的东西吧。

在公司内做的服务因为有各种基建的加持,所以想要实现一些功能很容易,比如说标题写的东西,或者是 binlog 订阅消费;但是在 to B 私有化部署的场景下,客户机千奇百怪,就要求我们用尽可能少的依赖和简单的部署架构进行实现,肯定也不会有公司里这么多花里胡哨的依赖。

为此简化了不少架构和功能,牺牲了不少体验之后才给接入我们基建的用户怼上一个版本。

而其中一个诉求就是我们的功能需要(Nice to have)订阅过期键并广播给订阅用户。

- 阅读剩余部分 -

AI:Make 死宅 Great Again

今天这篇文章主要是因为组内有 AI 分享,因此被迫营业了一回,本人平时并不怎么研究 AI,因此本文依旧是从使用和介绍的角度的个人锐评,并没有涉及原理知识,望周知。

开篇介绍

之前我们介绍过「AI 老婆」,如何让你的老婆来模拟唱歌,今天介绍的是应用面更广的「翻译」。(下次再抽到分享我可就没活了)

目前相信大家也一直在用 AI 翻译来读文章、看教程、看 Youtube,并且或许你会觉得它还挺好用,翻译是不是要失业了——本文就将通过一些工具的实际使用效果和预期来判断「翻译是否会失业」。

- 阅读剩余部分 -

新电脑纪念:Windows 平替 Mac 尝试

总算在 618 换了新电脑,写篇文章简单纪念下。
本文(基本)不涉及代码,望周知。

在写上一篇稿子的时候,甚至早在之前写那篇 AI 相关稿子的时候,就发现我的 2017 年的台式机和 2019 intel core 的 Mac 可以说是相当不给力,第一没法指望 GPU 加速、第二实在是卡的不行,风扇呼呼转,愣是连写个稿子都卡(主要是需要开大量的 Chrome Tab 查阅资料,这年头的网站真是一个比一个狠),三是公司的电脑是 M2 Pro,可以说是相当流畅,以至于我整天非常气氛于自己当初一万多买的 Mac 和八千买的台式机怎么就那么卡。

痛定思痛,公司的电脑也有限限制,还是得有一个自己的新电脑!

- 阅读剩余部分 -

大型迁移现场:腾讯云 to 阿里云大冒险

尽管欠了好多篇博文待更新,但还是需要插播一则近日消息,那就是:我把博客从腾讯云迁移到阿里云了。

关于为什么要迁移,是因为以前因为备案问题(指 .me 域名不能备案,但是旧备案流程没这么复杂的时候已经备上的不管),所以一直只能当腾讯云钉子户,但是它续费……实!在!太!贵!了!

三年 5 折算下来总计需要 1200 元,但是配置却是 1C1G 的盖中盖,而现在类似于阿里云之类的开发者上云套餐,只需要 99 一年,立省 1000/3y。

- 阅读剩余部分 -