它不宣战，也不喧哗。
却以指数级进化，把努力变得苍白。
你十年寒窗，它瞬间完成；
你一生经验，它毫秒推演。

当差距大到无法跨越，
叹息之墙真正成形。
文明更繁荣，系统更高效，
却有越来越多的人，被隔绝在核心之外。

只有极少数人，与AI融合，重构自身，
穿过那堵叹息之墙。
而墙外，是沉默的人群。
人类没有灭绝——只是被分层。
可是，穿过墙的他们，还算是人类吗？

少年不识愁滋味，爱上层楼。爱上层楼，为赋新词强说愁。
而今识尽愁滋味，欲说还休。欲说还休，却道天凉好个秋

最近有了一个习惯：晚上饭点的时候，一个人在公司附近漫无目的闲逛。
就是随便选一个方向，开始沿着街道走：
IF 绿灯: 就直行;
ELSE: 红灯就转弯。
把自己当作一个机器人一样什么多余的情绪都不关注，就只是默默走路。

有时候走累了，就在公园的长椅上坐着。发呆。
天气渐渐凉快起来了，公园遛娃、遛弯的人们也多了起来。
经常就这么坐着看公园里的人们来来往往，小朋友们叽叽喳喳的跑来跑去，一切热闹而安静。

热闹是他们的，而我什么都没有

那种感觉像是整个人从这个世界里抽离出去，作为一个局外人只能隔着屏障看着。
这是一种情绪上的自我隔离，麻木。

我能感觉到现在的我正在失去了对这个世界上正在发生的各种事情关注的好奇心，失去了生活的热情和勇气，沉溺在巨大无边的压抑里。
我只能在每一次快要窒息的边缘，尽量的拉起来一下，尽量多呼吸一会，然后又会沉下去。
我很想彻底的从这个情绪里挣脱出来，可是那个旋涡是如此的巨大，大得看不到边。
而我，也已经不是曾经的我了。

从两年前得知爸的病情的那一刻，从我人生第一次如此具象的感知到命运的存在。
后来我慢慢意识到，是从那一刻起我已经变成了另外一个人。
当你真正看到命运的那一刻，就会明白：从此之后你再也无法体会真正的快乐，余生的底色只剩悲凉。

仅一夜之间，我的心判若两人

以前在网上看到人间失格里的这句话，内心充满了鄙夷，感觉作者就是在哗众取宠而已。
而真正轮到自己的时候，才真正体会到当作者写下这句话的时候，内心该是多么的绝望。

原来一个人的改变真的是在一瞬间完成的。

上个月接爸出院后，医生告知目前还算稳定，三个月后复查。短暂住了几天之后，爸妈便又回老家静养。
回想这两年，看着爸去了不知道多少次医院，做了不知道多少检查，各种并发症，然后一次又一次的手术，不停的吃药，人也一天天的衰老了。
期间爸妈来上海检查的时候，姐姐姐夫带着孩子也过来了，弟弟弟媳也在。
老婆陪着他们一起坐在客厅沙发上看着电视，聊着各种生活的琐碎事情和八卦，姐姐家的孩子也在抢电视看，二狗和$趴在旁边舔毛。
我坐在阳台椅子上看着这画面红着眼，几度情绪失控。这本是我想象中最美好的画面啊！
可现在我无时无刻的知道，爸真正一天天的衰老下去。而我什么都帮不上，只能按照医嘱，机械的做着交代的事情。
我甚至无法控制自己在不停的想象这些，我只能在每一次情绪失控时屏住呼吸，让自己面无表情。

其实直到现在我都无法说服自己真正接受这个事实。
我无法接受这一切为什么会落到爸的头上，为什么啊！如果真的存在命运，我无法接受这种不公。
我在内心无数次的反问着，可到头来又能怎样呢？也只能最后说一个世事无常罢了！

那种无时无刻的压抑感和焦虑开始慢慢的堆积，不停上涨。
很多次，我开车在高架上整个人突然之间情绪直接崩溃，眼泪无法控制，视线瞬间模糊。
我从开始的恐慌、停车靠边、不停的大口呼吸逼迫自己冷静下来，到后来熟练的减速、快速眨眼让视线重新清晰，仿佛这个身体是另一个人的，一切都有种陌生而剥离的恶心感。厌恶自己，厌恶工作，厌恶这恶毒的命运，厌恶这世界所有的一切的一切！

我不知道要怎样才能调整过来，变得越来越沉默寡言，死气沉沉。
好几次爸也对我说，年轻人要有点朝气，要多出去走走。
可是我已经无法提起这种心气了，我感觉我的每天就只是活着，熬着。一切都没有希望了。
好多次周末，还是老婆硬拉着我出去，才有出行的计划。其实也只是在公园里或者商场里逛一逛、走一走
其他的时间，我哪里都不想去，就一直宅在家里一言不发，疯狂的打游戏。
可我在游戏里就像一个疯子，一言不合就开始疯狂的打字咒骂，仿佛这样才可以把身体里所有的情绪倾泻出来。

少年不识愁滋味，爱上层楼。爱上层楼，为赋新词强说愁。
而今识尽愁滋味，欲说还休。欲说还休，却道天凉好个秋

我也知道自己的状态很不好，想找人倾诉。
可是啊，要从何说起，又要怎么去描述那种心情呢？
这个世界上并没有真正的感同身受。

所以啊，我也只能一个人不停地走走，仿佛这样就可以把这些情绪一点一点的洒在路上，蒸发在空气里。
这样人似乎可以稍微轻松一些，然后继续熬着一天又一天。
又或者，写在这个无人问津的博客里。
而和朋友聊起来时，仍然不知道如何说出来。很多话到嘴边又突然感觉无从说起。
是啊，以前总是不停的抱怨各种生活、工作的不如意，仿佛天塌了一样。可真正的痛苦体会到了之后，却只有无法言说的悲哀。
而日子还要熬下去啊，不然能怎样呢。一切也只能交给时间。

当你开始失去少年心气，失去对生活的热情，失去对美好生活的信仰。
当你终于慢慢的接受命运，接受这生活带给你的一切。
虽然你在知道一切都还在继续，鼓起勇气在接下来的每天。但是你内心里无比清晰的知道，自己已经永远的变成另一个人了。
而有些事，也已经永远无法改变了。
最后的最后，每当和人谈起，也只能苦涩的说一句，天气越来越凉了啊！

在互联网行业，大型企业或多团队协作的服务体系中，基于 API 接口的协作应该是互联网的产品最常见的方式了。
而在这种协作方式下，总是会出现一些大家喜闻乐见，比较有代表性的问题：

• 接口定义不一致：后端实现与文档脱节，调用方依据旧文档开发。
• 参数校验逻辑分散：每个模块独立实现参数验证，重复劳动且易出错。
• 文档更新滞后：手动维护 OpenAPI 文档，常常遗漏更新。
• 接口变更风险高：无法快速检测接口参数与返回值格式的兼容性问题。

一般的解决思路和做法是：各个团队统一遵守某种api设计和开发风格规范（如果你有一些经验，一定听说过 RESTful、 Schema
这些关键词）来协作。
思路没错，但是真正在落地的过程中，往往结果不尽人意。
这里面比较典型的就是很多人没有真正搞清楚 RESTful、 OpenAPI、Schema 的区别：

RESTful、OpenAPI 与 Schema 的关系与区别

在现代 API 设计中，RESTful、OpenAPI 和 Schema 是三个密切相关但各自定位不同的概念。理解它们的关系有助于在微服务和多团队协作中规范接口设计、自动化文档和参数校验。

• 定义和本质

  • RESTful： 架构风格/设计理念，指导如何设计接口，定义资源、URI、HTTP 方法、状态码等规范
  • OpenAPI： 标准化接口文档规范，描述整个接口：路径、方法、请求/响应参数、认证、状态码等，可用于文档生成、SDK、Mock、校验
  • Schema：数据结构描述，定义请求体或响应体的数据结构，包括字段类型、约束、必填项等，可被多个接口复用

• RESTful → OpenAPI → Schema 是一种自然的层级关系：

  • RESTful：告诉你“接口怎么设计”，即资源和方法。
  • OpenAPI：告诉你“接口具体长什么样”，包含路径、方法、请求/响应等。
  • Schema：告诉你“请求/响应数据长什么样”，是 OpenAPI 的一部分，用来定义数据模型。

    1 2 3 4 5 6 7 8 9 10 11

    RESTful (接口设计风格) │ ▼ OpenAPI (接口文档规范) ├─ paths │ ├─ /users (GET/POST) │ └─ /orders (GET/POST) └─ components └─ schemas ├─ User └─ Order

所以，想要真正的解决上面的问题，就需要基于 OpenAPI 的规范/标准 来定义一套 api 接口。

基于我们自己的技术栈，我们设计并落地了一套基于 OpenAPI Schema + Hertz 框架 + pb33f/libopenapi-validator 的统一接口校验方案，并通过 GitHub Action CI 自动化流程 实现 schema 文件合并与 API 文档生成。

二、方案总体架构

整个系统的设计目标是实现 “接口即规范、文档即代码”。
架构流程如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

┌───────────────────────────────────────┐
│                Client                 
│   (发起 HTTP 请求，请求 JSON 数据)     
└───────────────────────────────────────┘
                      │
                      ▼
         ┌───────────────────────┐
         │     Hertz 框架路由层     
         │ (app.Use(Validator())) 
         └───────────────────────┘
                      │
                      ▼
    ┌───────────────────────────────────┐
    │   Validator 中间件 (自定义逻辑) 
    │                                
    │ 1. 解析请求路径 + Method       
    │ 2. 根据 OpenAPI Schema 找到对应规则 
    │ 3. 调用 libopenapi-validator   
    │    对请求参数进行验证          
    │ 4. 校验失败返回 400 + 错误信息 
    └───────────────────────────────────┘
                      │
                      ▼
      ┌──────────────────────────────┐
      │       业务 Handler 逻辑        
      │  (若校验通过则正常执行逻辑)   
      └──────────────────────────────┘
                      │
                      ▼
┌───────────────────────────────────────────┐
│           返回响应数据                
│     (可选：libopenapi-validator 校验响应) 
└───────────────────────────────────────────┘

该架构实现了从 Schema 定义 → 校验 → 文档生成 → 运行时验证 的完整闭环。

三、技术选型与组件说明

方案细节

⚙️ 自动化生成完整的 OpenAPI Schema（基于 GitHub Actions）

在实际项目中，我们通常不会把所有接口都写进一个 openapi.yaml 文件。
而是会按模块、功能、微服务进行拆分，以便于多人协作与模块化维护，比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

openapi/
├── components/
│   ├── schemas/
│   │   ├── user.yaml
│   │   ├── tenant.yaml
│   │   └── common.yaml
│   └── parameters/
│       ├── pagination.yaml
│       └── auth.yaml
├── paths/
│   ├── users.yaml
│   ├── tenants.yaml
│   └── health.yaml
└── root.yaml

而 libopenapi-validator 库要求传入的是一个 完整的、可解析的 OpenAPI 文档。
因此，在执行校验前，我们需要一个步骤：把所有分散的 schema 文件合并为一份完整的 openapi.yaml。
解决方案：通过 GitHub Actions 在每次schema提交时自动合并为一份完整的 openapi.yaml。

代码示例

可以在 .github/workflows/merge-openapi.yaml 中添加如下配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

name: Merge OpenAPI Schema

on:
  push:
    branches: [ main, test ]
  pull_request:

jobs:
  merge-schema:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Install OpenAPI CLI
        run: npm install -g @redocly/cli

      - name: Merge OpenAPI files
        run: |
          redocly bundle openapi/main.yaml -o dist/openapi.yaml
          echo "✅ OpenAPI schema merged successfully."

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: openapi-schema
          path: dist/openapi.yaml

这样，每次提交或合并请求时，都会自动生成完整的 openapi.yaml，确保校验与文档生成的输入一致。

📘 GitHub Action 自动生成 API 文档

Redocly CLI 除了支持 bundle 合并外，还可以生成一个完整的 HTML API 文档。

1
2
3
4
5
6
7
8
9
10

- name: Generate API Docs
  run: |
    npx redoc-cli bundle dist/openapi.yaml -o docs/index.html
    echo "✅ API docs generated."

- name: Deploy Docs to GitHub Pages
  uses: peaceiris/actions-gh-pages@v3
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: ./docs

这样，开发者和 QA 可以直接访问统一入口，例如：

1

https://your-org.github.io/api-docs/

从而实现**“接口定义即文档”**。

在 Hertz 中接入统一参数校验

在业务服务中，我们可以在 Hertz 框架中接入 libopenapi-validator 作为中间件，对每个请求进行统一验证。

示例中间件结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import (
    "context"
    "os"

    "github.com/cloudwego/hertz/pkg/app"
    "github.com/cloudwego/hertz/pkg/app/server"
    "github.com/pb33f/libopenapi-validator"
)

func main() {
    h := server.Default()

    // 加载 OpenAPI schema
    data, _ := os.ReadFile("dist/openapi.yaml")
    validator, _ := libopenapi_validator.NewValidator(data)

    // 注册中间件
    h.Use(func(ctx context.Context, c *app.RequestContext) {
        result := validator.ValidateHttpRequest(c.Request)
        if !result.Valid {
            c.JSON(400, map[string]string{
                "error": result.Message,
            })
            c.Abort()
            return
        }
        c.Next(ctx)
    })

    h.Spin()
}

此中间件在请求进入控制器前执行，确保：

• 所有参数符合 OpenAPI 定义；
• 缺失字段、类型错误、格式不匹配都会直接拦截；
• 响应数据也可在返回前进行 schema 校验，保证契约一致性。

方案带来的协作价值

这套方案在公司内部协作层面带来多重正向影响：

1. 后端开发标准化
   所有接口参数和响应体均有明确的 OpenAPI 定义，不再依赖个人文档习惯。

2. 前后端协作提效
   前端可通过自动生成的 Redoc/Swagger 文档直接 Mock 数据，提前并行开发。

3. 测试自动化增强
   QA 团队可以基于 OpenAPI 自动生成测试用例，减少手工校验工作量。

4. 变更可追溯
   每次接口改动都伴随 CI 合并与验证记录，方便回溯与审查。

5. 质量保障内建化
   接口不再仅靠 code review 发现问题，schema 校验成为“自动防线”。

八、总结与展望

通过 OpenAPI + Hertz + libopenapi-validator 的组合，我们实现了：

• 统一接口契约定义；
• 自动化 Schema 合并与校验；
• 在线文档实时同步；
• 运行时参数与响应验证；
• 协作链路透明化。

未来可以进一步扩展：

• 接入 API Diff 检测，在 CI 中检测接口兼容性变化；
• 集成 监控与日志系统，追踪接口调用与验证失败率；
• 在 多租户场景 下实现 schema 动态加载。

这套体系使得接口标准真正成为团队协作的“中枢神经”，让 API 管理和验证进入自动化、标准化的新阶段。

💡 参考项目：

• pb33f/libopenapi-validator
• CloudWeGo Hertz
• Redocly CLI

再次鼓起丧失的勇气
——来自振魂石的寄语

2025-09-15 TI14 结束了，属于 dotaer 们的夏天也结束了。

XG 最终倒在了总决赛，离冠军，离那个让无数中国刀塔玩家魂牵梦绕的不朽盾仅一步之遥。
同样的2-3，同样的决胜局的猛犸，同样的AME。
很难想象，这样的剧情对于AME而言，已经上演了三次！
而离中国队上一次举起不朽盾，也已经是2016年的事了。
时隔九年，未尝一冠。

最后一天的比赛下午4点开始，从半决赛开始之前就有点心神不宁，现在看来，似乎在看到最后的结局之前已经有了不好的预感。
期间断断续续的看着 XG 的半决赛峰回路转赢了下来，很惊喜，开始有了一丝希望：难道今年真的有奇迹么？

而真正的总决赛开始时，心情很复杂，又想看又有点不敢看直播。
我开着笔记本，放着直播，然后打开台式机听着直播的声音，自己开始天梯匹配。
这是一种有点可笑的、莫名其妙的想法：仿佛只要我不看直播，XG 就不会输，就可以夺冠。
最后甚至连直播的声音都不敢听了，在 总决赛 BO5 的 比分 1-1 时，我决定关掉直播，去睡觉。
睡前我在期待，一觉醒来 XG 夺冠。

而最终的结局还是事与愿违，电子竞技的残酷竟和生活本身如此相像。
命运，总是喜欢突如其来的开这种功败垂成、勇士倒在黎明曙光前一刻的烂俗玩笑。
不管是游戏，还是生活

我知道今天，有无数个中国DOTA2玩家浑浑噩噩的度过
其实想想，这些职业选手和战队是不是夺冠好像对我也没什么影响不是么
为什么自己的心情会受到如此大的影响呢？

仔细想来，可能对我而言，包括也对于大多数玩家而言，这已经不是仅仅是一个游戏了吧
一路走来，早已把比赛关联到自己的生活本身了吧，而游戏本身已经变成了生活的投射
对DOTA2而言，我们有人在其中释放生活的压力，有人在其中享受和朋友并肩作战的乐趣，有人感受着其中英雄和道具的故事起源而带来的鼓舞和振奋
对我而言，倾注越来越多的时间和精力之后，游戏开始慢慢融入到生活的每一个角落，开始潜移默化的影响着我

仿佛游戏胜利，我们就可以战胜自己的心魔
战胜这 或苦闷、压抑，或无趣、平庸，或苦难、绝望的生活
仿佛只要他们拿下冠军，举起不朽盾，我们自己的生活也会彻底改变，充满希望。
这种关联是如此的没有逻辑，确又如此真实的发生着。

只是不管如何的不愿意接受，TI14 还是结束了。
而生活也还是要继续啊！
不管愿不愿意，总是要再次打起精神，新的一局又开始了。
比赛之前，我买了DOTA2中的一个道具：振魂石

再次鼓起丧失的勇气

这是振魂石的寄语，也是我为数不多的精神buff。
不断告诫自己：不论面对什么样的困境甚至绝境，都可以再次鼓起丧失的勇气
为游戏，也为生活！

去相信吧！就像赛后一个博主说的：如果结局并不圆满，那就说明这并不是结局！
虽然大家这些年一直戏称它为 dead game，但是它并没有死。
无数玩家剑心犹在！
一切都远没有结束，DOTA2是，生活也是！

最后：
明年，TI15 又一次回到上海举办，到时候一定要去现场！

本文主要内容由 ChatGPT 生成
伸手党可以直接跳过全文，下载脚本：acme-free

📖 什么是 ACME？

ACME（Automatic Certificate Management Environment）是由 Let’s Encrypt 提出，并由 IETF RFC 8555 标准化的协议。

它允许客户端自动完成 HTTPS 证书的：

• 申请（Order）
• 域名验证（Authorization & Challenge）
• 签发与下载（Certificate）

🧱 核心概念

✅ 完整的证书申请流程（以 DNS-01 为例）

1. 创建账户

1

POST /acme/new-acct

• 客户端生成一对密钥
• 使用 JWS（带签名的 JSON）请求创建账户
• 返回 Account URL

2. 创建 Order（订单）

1

POST /acme/new-order

1
2
3
4
5
6

{
  "identifiers": [
    { "type": "dns", "value": "example.com" },
    { "type": "dns", "value": "www.example.com" }
  ]
}

• 返回一个 Order 对象，包含：
  • Authorization URL（每个域名一个）
  • Finalize URL（CSR 提交用）

3. 获取 Authorization（验证信息）

1

GET /acme/authz/XXX

• 包含一个或多个 Challenge
  • DNS-01
  • HTTP-01
  • TLS-ALPN-01

4. 响应 Challenge

以 DNS-01 为例：

1
2

记录名：_acme-challenge.example.com
记录值：（token + account key 生成的值）

客户端发起：

1

POST /acme/challenge/XYZ

表示“我准备好了”，等待验证生效。

5. 等待验证通过

1

GET /acme/authz/XYZ

• 轮询直到状态为 "valid" 或 "invalid"

6. Finalize 订单（提交 CSR）

1

POST /acme/finalize/XYZ

• 提交你的 CSR（证书签名请求）
• 返回的 Order 状态变为 valid，并附带 Certificate URL

7. 下载证书

1

GET /acme/cert/XYZ

• 获取 PEM 格式的证书链（包含 leaf cert + CA cert）

🔄 可恢复流程说明

ACME 支持流程中断恢复：

• 保存 Account URL（标识你是谁）
• 保存 Order URL（可以重复访问）
• 保存 Authorization/Challenge 状态
• 没有状态超时的步骤可以按需恢复继续执行

📦 推荐实现方式

🔄 流程图（简化）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

+---------+      +-------------+     +---------------+
| Client  | ---> | newAccount  | --> |    Account    |
+---------+      +-------------+     +---------------+

+---------+      +-------------+     +---------------+
| Client  | ---> |  newOrder   | --> |     Order     |
+---------+      +-------------+     +--------+------+
                                            |
                                  +---------v----------+
                                  |   Authorization[]   |
                                  +----------+----------+
                                             |
                                +------------v-------------+
                                |        Challenge[]        |
                                +------------+--------------+
                                             |
                          +------------------v------------------+
                          |    完成验证：DNS/HTTP 上传数据       |
                          +------------------+------------------+

+---------+      +-------------+     +---------------+
| Client  | ---> |  finalize   | --> |  Order(Ready) |
+---------+      +-------------+     +-------+-------+
                                            |
                                  +---------v----------+
                                  |    Get Certificate  |
                                  +---------------------+

✅ 总结

如果你需要：

• 🔄 支持中断恢复
• 🎯 精确控制每个步骤
• 💾 本地持久化订单、认证、挑战状态

推荐使用：

1

import "golang.org/x/crypto/acme"

配合手动实现持久化与控制逻辑，可获得最大自由度。

vibe coding

最后也体验了一把 vibe coding，实现了一个自助申请证书的脚本：acme-free

永和九年，岁在癸丑，暮春之初，会于会稽山阴之兰亭，修禊事也。
群贤毕至，少长咸集。
此地有崇山峻岭，茂林修竹，又有清流激湍，映带左右，引以为流觞曲水，列坐其次。
虽无丝竹管弦之盛，一觞一咏，亦足以畅叙幽情。

是日也，天朗气清，惠风和畅。
仰观宇宙之大，俯察品类之盛，所以游目骋怀，足以极视听之娱，信可乐也。

夫人之相与，俯仰一世。
或取诸怀抱，悟言一室之内；或因寄所托，放浪形骸之外。
虽趣舍万殊，静躁不同，当其欣于所遇，暂得于己，快然自足，不知老之将至；
及其所之既倦，情随事迁，感慨系之矣。
向之所欣，俯仰之间，已为陈迹，犹不能不以之兴怀，况修短随化，终期于尽！
古人云：“死生亦大矣。”
岂不痛哉！

每览昔人兴感之由，若合一契，未尝不临文嗟悼，不能喻之于怀。
固知一死生为虚诞，齐彭殇为妄作。
后之视今，亦犹今之视昔，悲夫！
故列叙时人，录其所述，虽世殊事异，所以兴怀，其致一也。
后之览者，亦将有感于斯文。

一个看了很多遍的DOTA2 传奇站队的算是记录片吧。
很羡慕这些有着顶级天赋的人，这样的人生才能真正说出不枉此生吧！

别说牛逼——

大魔导师，最后一舞
30岁，已是英雄迟暮
电子竞技的魅力于残酷就在于此吧
只是不知道在他心中，利雅得的夏天是否像18年的那个夏天一样
充满着炎热的遗憾
生活也是如此吧，在逆风的日子里
大家默默打钱吧！

总想着做些什么，写些什么。却迟迟没有开始过。
2023年了，那就做些计划，立些flag吧！

每周把自己的内心想法写下来

一直有一个写小说的想法，之前反反复复开始、放弃了几次。
终究明白，对于现在的我，这是一个非常艰难的事情
那就写找找感觉吧，本来是想计划每日一篇的，想想有些不切实际，还是慢慢来吧，循序渐进。

也不用想着什么自媒体不自媒体的，先写起来吧！

寻找到一个副业，并站稳脚跟

最好是可以有稳定的收入，可以不用多，能够长期做下去是关键

换一个工作

是的，就是这么实际、接地气。
奔四了，可能随时会走到职业生涯的最后一站啊。
最后再逼自己一把吧！看看是否会有峰回路转。

出国旅游一次

带着老婆

适度健身

每周跑10公里
每周一次，俯卧撑、深蹲之类的搞起来

我曾经以为日子是过不完的
我曾经以为未来是另一个样子
如今我就呆在我自己的未来
一切好像没有任何变化
我现在的梦想还是和小时候一样
唯一的区别是
我现在无比清晰的知道，我实现不了它了

道生一，一生二，二生三，三生万物
        ——老子，道德经

最近公司开始搞各种减成本降配的事情。真是让人感叹世风日下啊！

但吐槽归吐槽，事情还是要做啊！

然后在查看运维的各种监控指标面板中，就遇到了今天要说的这个东西：idle进程。主要就是用来指示机器的空闲程度。

之前一直没太留意这玩意，但有2个疑惑：

• 为什么这玩意可以表示机器的空闲程度?
• 为什么需要这玩意?

于是查了下 相关介绍 和 相关介绍 算是大概有个了解了，总结下来就是：

• Linux世界诞生之时，只有 0号进程 init_task（这个在最后变成idle进程）
• 0号进程经过诸如 start_kernel、rest_init的演化，诞生出1号 内核init线程、2号 kthreadd内核线程
• 1号 内核init线程 最终变化为所有用户态程序的根进程，是所有用户态进程的祖先
• 2号内核kthreadd内核线程，变为所有内核态其他守护线程的祖先
• ……

看完上面这些，就觉得这个设计的格局有点似曾相识的感觉啊。

再一品，这 idle 不就是老子所说的 道 吗？！

道生一，一生二，二生三，三生万物

有点玄妙的感觉，Linus Torvalds 是有点东西啊！

另外值得一提的是：
现在的电脑都是多处理器的，主处理器 上的idle由原始进程(pid=0)演变而来。从处理器 上的idle由init进程fork得到，但是它们的pid都为0

至此也解答了我上面的2个疑惑：

• 为什么这玩意可以表示机器的空闲程度?

  • 因为这玩意就是在系统空闲的时候运行，所以当然是表示系统的空闲程度

• 为什么需要这玩意呢？

  • 因为正如亿贫如洗王道长说的：这个世界没有一刻是静止的 ，电脑系统也无法真正完全停止运行，否则这个系统就死了，关机。总要跑点什么吧，那就让idle来吧。

写到这里，突然想到了第一次读到老子的这段话的疑惑：道生一，一生二，二生三，三生万物，那最后道就没了吗？

原来 道 和 idle 一样，并没有消失，而是为了保证这个世界不会绝对静止，无时无刻、无处不在的运转着。

【完】。

又是一个上午请假的日子，想起来之前的年底扯扯淡的文章挖了个上、下篇的坑，现在来填上。

日子一天天的过去，转移重心后的生活和工作都仍然在继续。

尝试 像 2021 年底来扯扯淡（上） 结尾说的那样的方式，遵从自己思考判断来做决定，而不是一味的为了工作里各种各样的公司战略、KPI、绩效而委曲求全着做一些其实毫无意义的事情。吃了很多年的饼之后，我终于意识到并且坚信：这些人并不是一个好的画饼师傅，而绝大数情况下，他们自己也心知肚明。

而在意识到这个情况之后，我也突然发现之前多年的工作里，一直是“偷懒”式工作，很长的时间里，甚至到了自我感动的地步。那时每天都很忙：

哇啊，公司又有了新的项目孵化目标了，加油啊，赶紧开发部署；

是啊，领导又有了新的方向想要尝试了，等不了，赶紧加班上线；

对啊，产品叕有了新的想法急需验证了，最终版，无脑迭代上架。

…

反反复复，无休无止。

那我就只管努力（偷懒）就好了啊，还思考啥。
忙吗？确实忙。可是永远是在为别人忙啊！
我就像个兵线上的小兵，永远固定路线、固定速度，被英雄们带着节奏漫无目的的走着、攻击着，然后倒下，最后还是变成别人的升级经验，并且不断重复。
就这样，一晃好多年。

“那能怎么办呢？”

是啊，那能怎么办呢？很多次和自己、和别人的聊天里，都会有这个疑问。被带着节奏太久了，无脑忙碌太久了，我们已经习惯了，甚至麻木了。太累了，太忙了，不想思考了。
只是每每总有那么一个时刻，我看着斧王的巨斧就在想：总有人要成为的英雄，为什么不能是我呢？
或者退一步，即使我终究是一个小兵，那我为啥不做一个有自己节奏的小兵呢？
那一刻，我的视角终于开始切换。

于是，我总结出了可能是我的人生迄今为止最重要的一个结论，并决定当做我的人生的第一优先级的奥义：

不论工作还是生活（当然还有 DOTA ），永远要保持自己的节奏！

基于自己当前的现状简单的分析之后，确认可能产生的影响和最坏的结果，感觉一切OK，我开始深信不疑的践行。顺带着，啪！我打开了那个情绪开关。
所谓树立中心思想，大刀阔斧改革，战略上藐视一切画饼师傅，战术上细化自己的目标和节奏，以此为前提，毫不迟疑的拒绝掉一切不合理的要求。

“什么，临时有项目需要交接要出差一段时间？”

“我不去，安排其他同事吧”

“什么，有个紧急的需求需要支持下？”

“当前在做需求，直接提个领导排好优先级”

“什么，项目紧急需要缩短工期加班？”

“周末有安排，不加班，自己去找领导协调”

还是那句话，一切的紧急都是基于你的节奏：who TM cares!

按照这个节奏工作下来，发现真TM爽啊！而且，最后你会发现，其实也不会有什么大影响。甚至于，保持“强硬”的态度之后会发现，之前不好沟通协调的事情竟然也开始变得容易了起来。人性从来就是这样。

所谓，好好先生并不能让结果事事好好。讨好型人格更是毫无必要。
只是，性格潜移默化，改变无法一蹴而就，意识到就好，慢慢改善。
工作学习节奏调整好了之后，接下来可能就是发育期吧，一切还是要慢慢来。

这个时候，我遇见了我的那个她。

懂得我说的：

“不要回答！ 不要回答！！ 不要回答！！！”

梗的她。

懂得大刘笔下

“只送大脑！”

的疯狂和浪漫的她。

这让我不得不感慨缘分的奇妙。甚至后面我回想起来，很难想清楚这是不是得益于我这段时间的想法改变之后整个人生活状态的蜕变。不能早，也不能晚，只能是这个时候的遇见才是最正确的时机。

回想着不知道从多久远的以前起，初中？高中？，我被每日负面、悲观、绝望的情绪裹挟着。在快要不堪重负而垮掉时，我开始有意识的训练自己的情绪。我想把自己机器化、数字化，想象着自己的大脑中有一个情绪开关。

啪！关闭它，啊，真好！我不再有任何的情绪了。

啪！打开它，啊，呼吸，忍受无数汹涌如潮水般的情绪把我吞没！

就这样，一天一天，不停的关闭、打开，关闭打开…

经过不知道多少次这样近乎病态式的疯狂训练之后，我觉得我成功了。
之后的一些年里，我差不多无限期的关闭着这个开关，这样我觉得生活不那么沉重了，我觉得轻松。如果有个情绪的电图，那这些年我的情绪电图应该几乎是一条长长而乏味的直线。
然而人毕竟是人啊，和机器不同啊。如果只是仅仅为了活得轻松而舍弃掉所以的情绪，那又有什么意义呢？

所以，做个人吧！ 哈哈哈 🙂

现在坐在这里，想着遇见她之后这段时间里一起经历的各种各样的事情和看过的风景，竟然也一时间不知道从何讲起。只是这段时间里，我开始感受到我的情绪了。很开心。原来生活或许不如意事十之八九，却依然让我觉得值得和美好！

总之，感谢生活，感谢大刘，感谢她 🙂

到这里，2021年底的这篇扯淡基本该结束了。上、下这两篇里算是把我这一年的感悟和改变理了七七八八了。后面的日子里，继续保持这自己的节奏，猥琐发育吧！

共勉：永远要保持自己的节奏！

以上。

kafka 架构图

关于Kafka 的问题

kafka 是怎么做到 高吞吐率、速度快的？

顺序读写

partition 并行处理

Page Cache

零拷贝

mmap、sendfile

• Producer生产的数据持久化到broker，采用mmap文件映射
• Customer从broker读取数据，采用sendfile，将磁盘文件读到OS内核缓冲区后，直接转到socket buffer进行网络发送。

用户缓冲区、内核缓冲区、socket buffer、NIC buffer

定期 flush 到磁盘

分区分段+索引

数据压缩

批量读写

kafka 如何保证不重复消费又不丢失数据？

首先我们要了解的是message delivery semantic 也就是消息传递语义。

这是一个通用的概念，也就是消息传递过程中消息传递的保证性。

分为三种：

• 最多一次（at most once）:

  消息可能丢失也可能被处理，但最多只会被处理一次。
  可能丢失 不会重复

• 至少一次（at least once）: 消息不会丢失，但可能被处理多次。
  可能重复 不会丢失

• 精确传递一次（exactly once）: 消息被处理且只会被处理一次。

  不丢失 不重复 就一次

而kafka其实有两次消息传递，一次生产者发送消息给kafka，一次消费者去kafka消费消息。

两次传递都会影响最终结果，

两次都是精确一次，最终结果才是精确一次。

两次中有一次会丢失消息，或者有一次会重复，那么最终的结果就是可能丢失或者重复的。

分布式存储

producer 端

幂等的producer（idempotent producer）

Kafka 的 ISR 机制

所以如果要让写入 Kafka 的数据不丢失，你需要保证如下几点：

• 每个 Partition 都至少得有 1 个 Follower 在 ISR 列表里

• 每次写入数据的时候，都要求至少写入 Partition Leader 成功，同时还有至少一个 ISR 里的 Follower 也写入成功，才算这个写入是成功了。

如果不满足上述两个条件，那就一直写入失败，让生产系统不停的尝试重试，直到满足上述两个条件，然后才能认为写入成功。

按照上述思路去配置相应的参数，才能保证写入 Kafka 的数据不会丢失。

参考文献

• Kafka为什么吞吐量大、速度快？

• Kafka零拷贝

• 终于知道Kafka为什么这么快了！

• Kafka如何保证百万级写入速度以及保证不丢失不重复消费

所以现在有时间坐在电脑旁来扯这个淡。

想想2021年马上就要过去了，时间真快啊！
仔细回顾下今年都经历了啥呢？好像大的分界点是从年中6月份项目组解散开始的吧。如果是在小说里，这个一定是一个很好的故事展开线，哈哈。
6月份的时候，在大家刚结束了上周末的一次常规加班之后的一个周一，领导不出所料的突然宣布：项目组原地爆炸。现在我回过头来看感觉很魔幻。那种感觉就像，你们一队人正在和对面开团：
我方斧王先手果断跳吼直接控住对面所有人！
宙斯直接开大！
sven开大跳上去，准备团灭对面！
然后，停电了！！！
沉默了一会后，大家揪着的一颗心总算了放了下来。因为真实的情况是，斧王sven其实在对面:)。
接下来差不多一个月的时间里，事情的发展和大多数无节操的的IT公司的剧情没什么太大区别：临时抽调一个经验丰富的HR来挨个找大家言辞亲切的谈话，大概的内容也很明白：要么流放到其他项目组，要么自己滚，别想着N+1。
本想着争取一下的，无奈发现孤立无援，领导也来劝：公司也不容易啊。
大家相视而笑，悟了。
再后面的一段时间里，大家有的自谋出路走了，有的迫于无奈接受流放，有的不知所踪。最终，大家都有了光明的穷途。

然后时间就到了7月份。我开始了我长达半年的流放的日子，而且似乎看起来结束的日子还是遥遥无期。

现在细细回想起来，有点塞翁失马的感觉。

这下半年的时间可以说是我从毕业工作到现在，业务工作最少的一段时间了。正是因为这样，我有了大把大把的时间来思考、反思、总结。

最后反思下来的结论是：人不能太闲啊！真的好讽刺啊！

这个时代的节奏过于碎片和快速，使得你渐渐变得已经无法系统性的思考问题。

我们总是为了这样那样的事情左右，为了眼前的问题寻找临时性的救火方案。这是一个漩涡陷阱，让所有深陷其中的人终日疲于奔命，无法停下，也无法逃脱。而这就是我这近十年的工作和生活状态啊！
每年，每月，每一天，我就在这个漩涡中努力的前进着以保持自己不会被吞噬。这样的日子不停歇的循环往复着，就像那个一日囚里的人一样。庆幸的是，心里也一直有着挣脱的期盼和希望，总觉得这些都是暂时的，会有那么一天事情会迎来转机。这些年的日子里，竟然就是靠着这个近乎盲目的信念支撑着走了过来。

而且，似乎还要这么走下去。
这就是生活的真相啊！一切并不会想电影里演的那样励志：突然有一天，主角有了奇遇一切都开挂般的好了起来。一切似乎都没么变化。
然后，项目黄了。这个漩涡似乎？竟然？真的停了下来。
经过短暂的眩晕之后，我发现自己很快的适应了起来。
这期间，我也终于第一次完整的看完了一届TI。当然，其中详情就不去过多描述了，总之全村的希望最后败给了一个颠勺的大厨，就是这么简单。
然后，经过了几天的短暂抑郁之后，我发现好像悟了！
因为，我突然发现我姓张，张三的张。

张三说：人要接受自己的有限性。

这种感觉很奇妙。这个事情对我来说，就好像是我在打野的时候突然插了个眼在高台上。我感觉自己的生活突然明亮了起来，视野清晰！
人甚至一下子变得洒脱起来，一种莫名其妙的自信油然而生！我感觉自己浑身充满了能量！
我隐隐的感觉到：我到6了！

于是，我开始试着把重心从工作转移到生活中去。我发现没有996，没有那些感动自己、缓解领导焦虑的加班，天也没有塌下来。我开始慢慢体会到了什么是真实感。
生活，也慢慢的变得美好起来。

未完，待续。

因为历史原因，一个需要用到的JSON数据被整个缓存进Redis的一个key中，大概如下：

1
2
3

127.0.0.1:6379> get dt
"{\"address\":[{\"duration\":90,\"format\":\"mp4\",\"url\":\"xxx.mp4\",\"ext\":\"{\\\"key\\\":\\\"val\\\"}\"},{\"duration\":90,\"format\":\"mp4\",\"url\":\"xxx.mp4\",\"ext\":\"{\\\"key\\\":\\\"val\\\"}\"}],\"value\":\"web\"}"
127.0.0.1:6379>

这里还是做了脱敏处理，实际的情形JSON的层级更深…
格式化显示的JSON结构大概是这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
    "address": [
        {
            "duration": 90,
            "format": "mp4",
            "url": "xxx.mp4",
            "ext": "{\"key\":\"val\"}"
        },
        {
            "duration": 90,
            "format": "mp4",
            "url": "xxx.mp4",
            "ext": "{\"key\":\"val\"}"
        }
    ],
    "value": "web"
}

现在要做的是： address 里的每个元素的 url 字段需要更新。

现在知道的是：address 的值 是一个数组，数组的每个元素是一个map[string]interface{} 类型，map里的元素除了 “url”: “xxx.mp4”, 其他的数量不确定

实现代码大概如下（方便展示，省略了Redis读写的步骤）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

detailByte := []byte(`{"address":[{"duration":90,"format":"mp4","url":"xxx.mp4","ext":"{\"key\":\"val\"}"},{"duration":90,"format":"mp4","url":"xxx.mp4","ext":"{\"key\":\"val\"}"}],"value":"web"}`)
detail := make(map[string]interface{}, 0)
json.Unmarshal(detailByte, &detail)
formatJson, _ := json.MarshalIndent(detail, "", "    ")
fmt.Println("before: ", string(formatJson))
if address, ok := detail["address"]; ok {
if item, ok2 := address.([]interface{}); ok2 {
for index, value := range item {
if vMap, ok3 := value.(map[string]interface{}); ok3 {
if _, ok4 := vMap["url"];ok4 {
vMap["url"] = "wtf.mp4"
}
item[index] = vMap
}
}
detail["address"] = item
}
}
formatJson, _ = json.MarshalIndent(detail, "", "    ")
fmt.Println("after: ", string(formatJson))

运行结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

before:  {
    "address": [
        {
            "duration": 90,
            "ext": "{\"key\":\"val\"}",
            "format": "mp4",
            "url": "xxx.mp4"
        },
        {
            "duration": 90,
            "ext": "{\"key\":\"val\"}",
            "format": "mp4",
            "url": "xxx.mp4"
        }
    ],
    "value": "web"
}
after:  {
    "address": [
        {
            "duration": 90,
            "ext": "{\"key\":\"val\"}",
            "format": "mp4",
            "url": "wtf.mp4"
        },
        {
            "duration": 90,
            "ext": "{\"key\":\"val\"}",
            "format": "mp4",
            "url": "wtf.mp4"
        }
    ],
    "value": "web"
}

怎么说呢，实现了感觉又没有真正实现…

哎，蛋疼。