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

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

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

背景

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

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

TLDR

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

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

Rust 的官方包管理系统依赖一个 GitHub 上的 Git 仓库¹管理索引信息，其相关格式也有较为详细的定义²。

随着 crates.io-index 体积的不断膨胀，现有的分发方案逐渐表现出了一些弊端，Rust 社区开发者也提出了名为稀疏索引（Spare Index）的 RFC³，用于优化相关场景。春节放假无聊，简单介绍一下前因后果，也希望有兴趣有能力的人可以推动其落地与发展。

目前（2021年）的主要工作是参与公司自研对象存储的开发和维护，记录一些常见的成本优化思路。因为投入产出比的原因，不一定所有企业都能够落地。

挑选的都是可以从公开渠道找到相关信息的方案，不涉及企业内部技术机密。

内容很少，想到啥更新啥。