我常用来查看历史行程的第三方 Tesla App 在去年改为订阅制。为了继续掌握自己的行车数据，也趁机补上 Owner API 的细节，我动手写了一套自用的小工具，把一路摸索的经验整理成这篇笔记。内容主要参考 Tim Dorr 的非官方文档和个人实验数据，希望未来的自己能快速回忆关键步骤。

二十世纪末，浏览器与证书颁发机构（CA）之间的信任几乎完全依赖“名单制”：名单里列出哪些 CA 可信，浏览器就默认接受他们签发的一切证书。DigiNotar 事件等案例¹提醒我们，这套模式太容易被误用或滥用，一张假证书可能在无人知晓的情况下就进入用户的 TLS 连接。Certificate Transparency（简称 CT）因此被提出，希望把签发过程晒在阳光下，让任何人都能验证“谁在什么时候为谁签了证”。

我最近在业余时间重写一个之前为工作开发的 Redis RDB 解析工具¹，旧版工具在处理大 Key 时内存占用过高，有时会触发容器的内存限制，导致解析失败。因此，新版本的核心目标是实现增量解析。

Redis 中对字符串对象，允许使用 LZF 压缩来节省空间，但常见 LZF 实现都只支持一次性解压，仍无法彻底规避内存问题。简单了解 LZF 算法后，发现其实现极为简单，且有流式解压的潜力，因此决定自己实现一个流式解压器。

本文是对 Go 官方博客文章 的中文翻译，原文作者为 Michael Stapelberg，发表于 2024 年 12 月 16 日。

Protocol Buffers (Protobuf) 是 Google 的语言无关数据交换格式。

2020 年 3 月，我们发布了 google.golang.org/protobuf 模块，这是对 Go Protobuf API 的重大重构。该包引入了一流的反射支持、动态 protobuf 实现以及 protocmp 包，简化了测试。

引言

在微服务架构中，接口参数验证是一个常见且重要的需求。B 站开源的 Kratos 框架围绕 ProtoBuf 和 DDD 设计，侵入性低，方便根据业务需求进行裁剪。

在 Kratos 官方模板中，开发者可以通过 ProtoBuf 定义服务接口，进而生成 OpenAPI 文档、客户端代码、服务端代码等。此外，官方文档还介绍了使用 protoc-gen-validate 插件生成数据验证代码，简化数据验证逻辑。

闲着无聊打开很久没用的 QQ，看到了自己中二时期的签名，很多内容的都是辛辛苦苦从网上摘抄的，但谷歌搜索一下，却有部分已找不到出处。 刚接触互联网时，互联网是开放、共享的，我曾幻想互联网上有用的信息会永远保存且公开可查。

我想当初看到这些句子时，一定伴随着某种正面的情感，才会按耐不住兴奋，把它们换成自己的 QQ 签名； 但当我无法搜索到这些句子出处时，我感到了一种失落，仿佛失去了一部分的记忆。 担心明天 QQ 突然不再保存历史签名，我决定把这些签名记录下来，也便于让它们重新回到互联网。

但不得不说，重新看这些签名真的太尴尬了。

背景

目前（2023年2月）维护着公司的对象存储系统，需要一套用于多机房流量调度与缓存的系统。目前由若干套自运维的 NGINX+ATS 集群实现，由于年久失修，存在一些问题，比如：日志信息不足、监控缺失、配置管理困难等，因此需要重构。

理论上可以研究研究 OpenResty 等基于 NGINX 的扩展方案，但由于我们不想为这个项目投入长期人力，能够较为简单的对接公司监控、日志等基础设施，并承载部分 dirty 的业务逻辑，因此决定使用 Go 语言开发。

TLDR

Linux 内核版本号曾被认为可以用三个 8bit 无符号整数表示，但后来这个约定被打破。TiKV 间接使用的库在解析内核版本号时，没有考虑到这一点，导致 panic。

目前（2022年5月）工作是维护某公司的对象存储和整套资源分发体系，经常跟 CDN 与客户端打交道，最近和网友闲聊过程中，发现有些知识虽然没有太大适用空间也说不上难点，但还算有趣，简单记录一下。