CodeSky 代码之空

又拖更了很久！最近要打的游戏有点多……

在一个多月以前开始倒霉的我加入了我们的性能排查专项，主要解决我们平台站点网络反应慢的问题。（再不更新就要忘光了）。

为了以防各位难以理解文章的脑回路，首先先来简单描述一下我们遇到的场景：

1. 内部平台，因此没有办法使用全球 CDN 像 C 端那样加速
2. 全球化 team，使用者遍布全球各地
3. 数据合规，因此在美国数据只能在美国，欧洲数据只能在欧洲

也因此处理内部网络问题更加困难，如果说在 C 端可以用「部分用户网络问题」来搪塞的话，内部系统一个老板 Case 就要一查到底了。

还是流水账更新的快啊。

上一篇文章 博客重建计划中我们提到了整个博客基本上都是 Cursor 负责研发，而我负责需求和验收工作。本质上是一种研发模式的变更，包括 Terminal 从 iTerm2 转而用 Warp 一样，新一代的革命随着 AI 的发展逐步升级。

有意思的是，在我日常唠嗑的过程中，往往一些大厂的员工对于工具升级反而没有创业公司的员工接受度高，这里当然指的不止是互联网头部的几家大厂以及一些对于热点敏感的同学（没有开地图炮的意思保命警告）。

这主要是因为对于大厂来说，合规永远是一个顾虑，用别人的模型，别人的 API，如果数据泄露了怎么办，要自研，又只有头部那几家能有这个财力和人力去做，而且投入时间长，效果也没有那么好，也因此对于普通大厂开发的开发体验升级其实反而是滞后的（因为我已经问了不止一家创业公司直接报销 Cursor 了（抹泪）

还是流水账比较好写，先把流水账写了吧。

今年过年期间也没有什么年度规划，不过自 1 月开始进行了博客整体重写的计划，起因是因为之前从腾讯云迁移到阿里云时可能是因为 PHP 版本控制的不对或者是别的问题，导致博客没办法正常的上传文件到又拍云。

现在都是靠着脚本上传文件然后 copy 发布的，Obsidian + Typecho 的脚本也不是很好用，也遇到了 5xx 的问题，但是我已经不会写 PHP 了，更不要说 debug 了。

每当公有云类服务出现问题的时候，我都会庆幸还好我一个 NAS 走天下：

• 百度网盘和阿里云盘出了问题：没事，我有 NAS
• 视频被和谐：没事，我有 NAS
• Gitlab 恐吓免费用户：没事，我有 NAS
• 服务器快照收费：没事，我有 NAS(群晖通过 Active Backup for Business 实现服务器快照)

说（传销）了这么多，让我们回到本文的主题，关于怎么部署 Gitea 以及 Gitea Action，CI CD 到自己的服务器。

读前指南：请不要问「为什么不用 GitHub 这种问题，前面的 Case 已经说明。

积压稿件 +1

生存提示：不鼓励使用盗版资源，因此也不提供盗版资源，仅供学习交流。

之前下了一些音频课，但是存在一些音频中间插入广告，更万恶的是，它根本不分是不是整句，只要时间差不多了就插入。

要去掉广告我们分为以下步骤依次执行：

1. 分析规律（就是前面找规律）
2. 广告提取
3. 识别广告
4. 重新拼接

对于字幕提取，之前其实我们在 AI 相关的文章中也介绍过对应模型，直接转换并处理就可以了，后面再介绍。

拖欠稿子 +1……为了重新写这篇文章我还重新踩了一遍坑，我真的哭死。

虽然现在阿里云和腾讯云的服务器都有学生套餐、开发者套餐，包括我目前部署的服务器就是 2C2G 99 一年。（这个在大型迁移现场：腾讯云 to 阿里云大冒险已有描述）。

但是问题是我们这种纯玩派，一方面在上面部署了稳定的服务，另一方面靠着辣鸡的运维水平，每次部署和迭代都有可能原地 GG，而平均每年折腾一次，每次运维水平一键归零让折腾成本雪上加霜。

因此快照服务作为一个无论是服务还是数据的兜底手段都有一定必要性，但是阿里云和腾讯云的快照服务又都是另外的价钱。

作为尊贵的白群晖玩家，我成功的找到了平替！

使用前保证：群晖服务可以在外网访问（否则可以不用看了，或者用内网穿透绕一圈或许也可以）

拖稿时间太长，只能努力还原……QvQ，因为如你所见的近期主要功夫都在重写博客系统和简历页面上了，当然也包括在 NAS 上部署的 gitea + action 的配置之类的，因此后面可以更新的文章还是挺多的

之前我也写过两篇 AI 相关的文章，不过因为不涉及到开发，只涉及到使用，所以我还是用 Windows 宿主机开发的，这次由于涉及到了开发，所以就得折腾一下 WSL GPU 加速的方案。

安装

在 Web 开发中，身份认证是一个很常见的诉求，而平时设计中并没有好好研究整体的 Auth 体系，今天就从头开始研究一下 Auth 这个东西。

MDN 对 HTTP Auth 有所总结：

RFC 7235 定义了一个 HTTP 身份验证框架，服务器可以用来质询（challenge）客户端的请求，客户端则可以提供身份验证凭据。

质询与响应的工作流程如下：

1. 服务器端向客户端返回 401（Unauthorized，未被授权的）响应状态码，并在 WWW-Authenticate 响应标头提供如何进行验证的信息，其中至少包含有一种质询方式。
2. 之后，想要使用服务器对自己身份进行验证的客户端，可以通过包含凭据的 Authorization 请求标头进行验证。
3. 通常，客户端会向用户显示密码提示，然后发送包含正确的 Authorization 标头的请求。

而大部分 HTTP 验证都遵循这一流程，只是加密算法、验证实现可能有所区别。

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

加锁

对于加锁操作，理论上应该是：

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

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

多少流量该限流

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