限流与常见实现
限流也是一个系统中老生常谈的话题了，因为资源不是无限的，因此系统总会达到一个瓶颈，我们不可能接受无限的流量直到系统崩溃，于是也就有了限流策略。
多少流量该限流
一般来说，我们有几种方法可以来对系统进行评估：
标签 知识 下的文章
缓存：高并发读的救世主
实在不知道该编什么名字，总之先复习一下缓存吧。本文讲的重点是服务端缓存，尤其是 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，并且或许你会觉得它还挺好用，翻译是不是要失业了——本文就将通过一些工具的实际使用效果和预期来判断「翻译是否会失业」。
瞎逼逼：谈谈容器日志采集
本文为日志采集漫谈，并不涉及技术选型，没有开源产品比对，望周知。
因为我并不是日志采集系统的开发人员，本文现学现炒，班门弄斧，如有问题欢迎留言（轻喷）。
故事还得从本周我搞了个 panic 开始说起，在我发布失败要排查为什么失败了时，我惊讶的发现我竟然要上容器才能看到 panic 日志，我工作这么久还是很少见到这种场面的，经过和基建同学的深入畅谈，我要上容器这件事情合不合理抛开不谈，但我意识到，虽然大家都有日志采集，但似乎每家公司的实现却都略有差异，因此今天就来讲讲关于日志采集的一些个人想法。
在过去的文章中，我们提到过好几次关于系统的稳定性建设，而稳定性建设的第一步，就是要采集数据，关于采集数据的每一个环节，我们都可以花很多篇幅去讲解，今天我们要介绍的「日志（Log）」就是其中的一环。（另外两个重要的方向是「链路追踪（Trace）」和「度量（Metrics）」）
瞎逼逼：研发效能度量的得与失
之前曾经说过关于更新成本较大，之后如果有一些只是思考而不是落地实践后验证的产物的话更新可能会快一点，因此有了本期——以后就叫「瞎逼逼」系列了。
「瞎逼逼」系列不严谨，只是个人的一些简单粗暴学习后的粗浅的看法，请注意。
故事开始：工时计件制
众所周知，程序员不是一个计件工种，但程序员的工资又高，因此，老板们总得有一个考核办法，能够让牛马们心悦诚服的接受自己的工作成果。
最低端的不懂技术的老板，会像工厂组长那样，研究一个程序员每天的打卡时间：这个公式可能是「下班时间 - 上班时间 - 午休时间 = 工作时长 = 你对工作的上心程度」，如果粒度更细的话，可以计算你每次进出门的打卡记录差值，也可以在厕所装上计时器，再完美的扣除「带薪拉屎」的时间。
禁用第三方 Cookie 战记：我的第三方 Cookie 怎么办
本文适用人群：受到第三方 Cookie 影响，想要一些第三方 Cookie 解决方案的战友
本文可能会是我插图最多的文章之一，因为要解释清楚各种概念，可能需要引用很多张图片辅助消化。
尽管 Google 在 2022 / 2023 疯狂铺垫自己要禁用第三方 Cookie，大家马上改造，但实际上大部分人的工作还是在死线前后死亡冲刺。Google 官方宣称禁用第三方 Cookie 是为了「减少跨网站跟踪，同时确保让每个人都能免费访问在线内容和服务的功能」，但实际上好处还没感受到，却带来了一大堆麻烦。
Story Start
DNS 科普·DNS 安全
上回我们说到 DNS 的基本知识以及 DNS 劫持的科普，那么 DNS 安全上又有哪些措施呢？
加密通信
如同 HTTP 通信一样，默认的 DNS 查询同样也是明文的，那么必然也可能遭受到攻击，比如下图中表示了一次中间人攻击（图源 cloudflare）：
那么同样的，我们也可以通过加密流量的方式来保证数据的可靠性。对于 DNS 来说，主要有 DoT 和 DoH 两种。