Blume's Skylog

Grafana 可视化与监控

Wed, 06 May 2026 00:00:00 GMT

Grafana 是一个开源的数据可视化和监控平台，主要用于把各种数据源中的指标（Metrics）、日志（Logs）和追踪（Traces）展示成直观的仪表盘（Dashboard），方便运维、开发和业务人员监控系统状态。

Grafana 能做什么？#

1. 数据可视化#

将数据绘制成：

折线图
柱状图
饼图
仪表盘
热力图
表格

例如：

1
CPU使用率
2
│
3
│      ╱╲
4
│    ╱╱  ╲
5
│  ╱╱     ╲
6
└───────────── 时间

2. 系统监控#

常用于监控：

服务器 CPU、内存、磁盘
Kubernetes 集群
数据库性能
应用程序运行状态
网络流量

3. 告警通知#

当指标异常时自动发送：

邮件
钉钉
企业微信
Slack
Webhook

例如：

CPU 使用率连续 5 分钟超过 90%，自动报警。

Grafana 的数据来源#

Grafana 本身不存储监控数据，它负责展示数据。

常见搭配：

数据源	用途
Prometheus	监控指标（最常见）
InfluxDB	时序数据库
Elasticsearch	日志分析
MySQL	业务数据
PostgreSQL	业务数据
Loki	日志监控
Tempo	链路追踪

Grafana + Prometheus 是最经典组合#

架构通常如下：

1
服务器
2
   │
3
Node Exporter
4
   │
5
Prometheus
6
   │
7
Grafana
8
   │
9
Dashboard

工作流程：

Node Exporter 收集服务器指标
Prometheus 定时拉取指标
Grafana 从 Prometheus 查询数据
Grafana 展示监控图表

一个典型场景#

比如你有一个 Java 网站：

1
用户访问网站
2
       │
3
Spring Boot
4
       │
5
Prometheus
6
       │
7
Grafana

Grafana 可以实时展示：

QPS（每秒请求数）
接口响应时间
错误率
JVM 内存
GC 次数
数据库连接数

为什么 Grafana 这么流行？#

优点：

免费开源
界面美观
支持大量数据源
Dashboard 丰富
Kubernetes/云原生生态事实标准
插件生态完善

很多公司会使用：

Grafana + Prometheus（监控）
Grafana + Loki（日志）
Grafana + Tempo（链路追踪）

形成完整的可观测性（Observability）平台。

一句话理解#

Prometheus 负责“采集和存储监控数据”，Grafana 负责“把数据画成好看的图表并进行告警”。

如果你是在学习 DevOps、运维、云原生或 Kubernetes，那么 Grafana 几乎是必学工具。

微服务之间如何传递 trace

Wed, 22 Apr 2026 00:00:00 GMT

跨微服务时，靠的是“上下文传播”，不是接口 body 显式保留 trace id。

先区分 3 个东西：

tracer：代码里 otel.Tracer(...) 的对象，表示哪段代码在打点
trace id：一整条链路的 ID
span id：链路里某个节点的 ID

微服务之间传递的是 trace id/span 上下文，不是 tracer。

HTTP 场景#

标准做法是放在请求头里，通常是 W3C Trace Context：

traceparent
tracestate
可选 baggage

流程是：

服务 A 收到请求，创建或继续一个 trace
服务 A 调服务 B 前，把当前 trace context 注入到 HTTP header
服务 B 收到请求后，从 header 提取 trace context
服务 B 基于这个 context 创建自己的 span

这样 A 和 B 的 span 就会落到同一个 trace 里。

所以一般不需要你在接口 JSON 里专门加：

1
{
2
  "traceId": "..."
3
}

除非你有业务上的特殊需求。对 tracing 本身来说，不该这么做，原因是：

污染业务接口契约
容易和真实 OTel 上下文不一致
标准库/中间件已经能自动处理 header

HTTP 里通常像这样：

服务端：Extract（从入站 header 恢复上下文）
客户端：Inject（把上下文写入出站 header）

Go + OpenTelemetry 的服务端提取示例：

1
// 服务端：从入站请求 header 中提取上下文，再基于它创建 span
2
ctx := otel.GetTextMapPropagator().Extract(
3
  r.Context(),
4
  propagation.HeaderCarrier(r.Header),
5
)
6
ctx, span := tracer.Start(ctx, "handle-request")
7
defer span.End()

客户端注入示例：

1
// 客户端：把当前上下文注入到出站请求 header
2
req := httptest.NewRequest("GET", "http://service-b/api", nil)
3
otel.GetTextMapPropagator().Inject(
4
  ctx,
5
  propagation.HeaderCarrier(req.Header),
6
)

gRPC 与消息队列#

gRPC 也是一样，只是不是 HTTP header，而是 gRPC metadata。原理完全相同：

client interceptor 注入
server interceptor 提取

消息队列也类似，通常放在消息 header / metadata 里，不放消息 body。

实务建议#

HTTP：用 traceparent 这些标准 header
gRPC：用 metadata
MQ/Kafka：用 message headers
不要把 trace id 做成业务接口字段，除非只是为了调试展示
可以额外返回一个 X-Trace-ID 给前端或调用方排查问题，但这只是便于观察，不是主链路传播的标准方式

相关概念见 OpenTelemetry 与链路追踪笔记。

kubectl port-forward 端口转发

Wed, 08 Apr 2026 00:00:00 GMT

k8s 端口转发#

最常用的是 kubectl port-forward。

转发 Pod#

把某个 Pod 的 8080 转到本机 18080：

Terminal window

1
kubectl port-forward pod/<pod-name> 18080:8080

如果 Pod 在指定 namespace：

Terminal window

1
kubectl -n <namespace> port-forward pod/<pod-name> 18080:8080

访问方式：

Terminal window

1
http://127.0.0.1:18080

转发 Service#

通常转发 Service 更稳：

Terminal window

1
kubectl -n <namespace> port-forward svc/<service-name> 18080:8080

注意这里后面的 8080 是 Service 的端口，不一定是容器端口。

让局域网其他机器也能访问#

默认只监听本机 127.0.0.1。如果要让其他机器访问你这台主机上的转发端口：

Terminal window

1
kubectl -n <namespace> port-forward --address 0.0.0.0 pod/<pod-name> 18080:8080

然后其他机器访问：

Terminal window

1
http://你的主机IP:18080

常用排查命令#

Terminal window

1
kubectl get pods -n <namespace>
2
kubectl get svc -n <namespace>
3
kubectl describe pod <pod-name> -n <namespace>

注意事项#

kubectl port-forward 是前台命令，终端关闭后转发会断开。
目标端口必须是 Pod 或 Service 实际监听的端口。
如果是长期暴露服务，不建议靠 port-forward，应该考虑 NodePort、LoadBalancer、Ingress 或反向代理。

Kubernetes

kubectl 常用命令速查

Fri, 20 Mar 2026 00:00:00 GMT

kubectl 常用命令#

查看当前集群#

Terminal window

1
kubectl config current-context
2
kubectl get nodes
3
kubectl get ns

查看资源#

Terminal window

1
kubectl get all -n demo
2
kubectl get pods -n demo
3
kubectl get deploy -n demo
4
kubectl get svc -n demo
5
kubectl get configmap -n demo
6
kubectl get secret -n demo
7
kubectl get job -n demo

查看详情#

Terminal window

1
kubectl describe pod -n demo <pod-name>
2
kubectl describe deploy -n demo user-api-deployment
3
kubectl describe svc -n demo user-api

看日志#

Terminal window

1
kubectl logs -n demo <pod-name>
2
kubectl logs -f -n demo deploy/user-api-deployment
3
kubectl logs -n demo job/ai-migrate-job

进入容器#

Terminal window

1
kubectl exec -it -n demo <pod-name> -- sh

本地访问服务#

Terminal window

1
kubectl port-forward -n demo svc/user-api 18000:80
2
curl http://localhost:18000/readyz

部署和删除#

Terminal window

1
kubectl kustomize deploy/overlay/dev
2
kubectl apply -k deploy/overlay/dev
3
kubectl delete -k deploy/overlay/dev

重启和发布状态#

Terminal window

1
kubectl rollout restart deployment/user-api-deployment -n demo
2
kubectl rollout status deployment/user-api-deployment -n demo
3
kubectl rollout history deployment/user-api-deployment -n demo

看事件#

Terminal window

1
kubectl get events -n demo --sort-by=.lastTimestamp

相关笔记：Kubernetes 排障手册、K8s 本地实战

k8s Service：给一组 Pod 稳定入口

Tue, 03 Mar 2026 00:00:00 GMT

k8s Service#

Service 给一组 Pod 提供稳定访问入口。Pod 会销毁、重建、换 IP，但 Service 的名字和虚拟 IP 相对稳定。

Pasted image 20260616204746.png

它解决什么问题#

Deployment 后面可能有多个 Pod：

1
user-api Pod A: 10.1.0.11
2
user-api Pod B: 10.1.0.12
3
user-api Pod C: 10.1.0.13

客户端不应该记住这些 Pod IP，因为 Pod 随时会变化。Service 通过 label selector 找到这些 Pod，对外提供一个稳定入口。

1
client -> Service -> matching Pods

最小示例#

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: user-service
5
spec:
6
  type: ClusterIP
7
  selector:
8
    app: user-service
9
  ports:
10
    - name: http
11
      port: 80
12
      targetPort: 8000

关键字段：

字段	作用
`selector`	找到带有对应 label 的 Pod
`port`	Service 暴露的端口
`targetPort`	Pod 容器里的端口
`type`	Service 暴露方式

Service 类型#

类型	用途
`ClusterIP`	只在集群内部访问，默认类型
`NodePort`	通过每台 Node 的端口访问
`LoadBalancer`	云厂商创建负载均衡器
`ExternalName`	映射到外部 DNS 名称

实际项目例子#

项目里有：

user-api：把流量转发到 app: user-api 的 Pod。
admin-api：把流量转发到 app: admin-api 的 Pod。

本地调试时常用 port-forward：

Terminal window

1
kubectl port-forward -n demo svc/user-api 18000:80
2
curl http://localhost:18000/readyz

常用命令#

Terminal window

1
kubectl get svc -n demo
2
kubectl describe svc user-api -n demo
3
kubectl get endpoints -n demo

如果 Service 没有转发到 Pod，优先检查：

Service 的 selector 是否匹配 Pod 的 labels。
Pod 是否处于 Ready 状态。
targetPort 是否等于容器实际监听端口。

相关笔记：pod、k8s deployment、Kubernetes 排障手册

Kubernetes 集群架构总览

Thu, 12 Feb 2026 00:00:00 GMT

Kubernetes 背后的架构概念。

Kubernetes 集群由一个控制平面和一组用于运行容器化应用的工作机器组成，这些工作机器称作节点（Node）。每个集群至少需要一个工作节点来运行 Pod。

工作节点托管着组成应用负载的 Pod。控制平面管理集群中的工作节点和 Pod。在生产环境中，控制平面通常跨多台计算机运行，而一个集群通常运行多个节点，以提供容错和高可用。

本文概述了构建一个完整且可运行的 Kubernetes 集群所需的各种组件。

控制平面（kube-apiserver、etcd、kube-controller-manager、kube-scheduler）和多个节点。每个节点运行 kubelet 和 kube-proxy。

图 1. Kubernetes 集群组件。

关于此架构

控制平面组件 #

控制平面组件会为集群做出全局决策，比如资源的调度。以及检测和响应集群事件，例如当不满足 Deployment 的 [replicas](https://kubernetes.io/zh-cn/docs/reference/glossary/?all=true#term-replica) 字段时，要启动新的 Pod）。

控制平面组件可以在集群中的任何节点上运行。然而，为了简单起见，安装脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。请参阅使用 kubeadm 构建高可用性集群中关于跨多机器安装控制平面的示例。

kube-apiserver #

API 服务器是 Kubernetes 控制平面的组件，该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

etcd #

一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。

如果你的 Kubernetes 集群使用 etcd 作为其后台数据库，请确保你针对这些数据有一份备份计划。

你可以在官方文档中找到有关 etcd 的深入知识。

kube-scheduler #

kube-scheduler 是控制平面的组件，负责监视新创建的、未指定运行节点的 Pod，并选择节点来让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 及多个 Pod 集合的资源需求、软硬件及策略约束、亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

kube-controller-manager #

kube-controller-manager 是运行控制器进程的控制平面组件。

从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

控制器有许多不同类型。以下是一些例子：

Node 控制器：负责在节点出现故障时进行通知和响应
Job 控制器：监测代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直至完成
EndpointSlice 控制器：填充 EndpointSlice 对象（以提供 Service 和 Pod 之间的链接）。
ServiceAccount 控制器：为新的命名空间创建默认的 ServiceAccount。

以上并不是一个详尽的列表。

cloud-controller-manager #

一个 Kubernetes 控制平面组件，嵌入了特定于云平台的控制逻辑。云控制器管理器（Cloud Controller Manager）允许将你的集群连接到云提供商的 API 之上，并将与该云平台交互的组件同与你的集群交互的组件分离开来。

cloud-controller-manager 仅运行特定于云平台的控制器。因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境，所部署的集群不包含云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中，以同一进程的方式供你运行。你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

下面的控制器都包含对云平台驱动的依赖：

Node 控制器：用于在节点终止响应后检查云平台以确定节点是否已被删除
Route 控制器：用于在底层云基础架构中设置路由
Service 控制器：用于创建、更新和删除云平台上的负载均衡器

节点组件 #

节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行时环境。

kubelet #

kubelet 会在集群中每个节点（node）上运行。它保证容器（containers）都运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpec，确保这些 PodSpec 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

kube-proxy（可选） #

根据 Service 和它对应的后端 Pod 列表，在每个节点上配置转发规则，让发往 Service 的流量能被送到某个后端 Pod。

kube-proxy 是集群中每个节点（node）上所运行的网络代理，实现 Kubernetes 服务（Service）概念的一部分。

kube-proxy 维护节点上的一些网络规则，这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。否则，kube-proxy 仅做流量转发。

如果你使用网络插件为 Service 实现本身的数据包转发，并提供与 kube-proxy 等效的行为，那么你不需要在集群中的节点上运行 kube-proxy。

容器运行时 #

这个基础组件使 Kubernetes 能够有效运行容器。它负责管理 Kubernetes 环境中容器的执行和生命周期。

Kubernetes 支持许多容器运行环境，例如 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

插件（Addons） #

插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

下面描述众多插件中的几种。有关可用插件的完整列表，请参见插件（Addons）。

DNS #

尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该有集群 DNS，因为很多示例都需要 DNS 服务。

集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。

Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。

Web 界面（仪表盘） #

Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。它使用户可以管理集群中运行的应用程序以及集群本身，并进行故障排除。

容器资源监控 #

容器资源监控将关于容器的一些常见的时序度量值保存到一个集中的数据库中，并提供浏览这些数据的界面。

集群层面日志 #

集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中，这种集中日志存储提供搜索和浏览接口。

网络插件 #

网络插件是实现容器网络接口（CNI）规范的软件组件。它们负责为 Pod 分配 IP 地址，并使这些 Pod 能在集群内部相互通信

一致性哈希：consistent 与 rendezvous 的对比

Fri, 06 Feb 2026 00:00:00 GMT

一致性哈希要解决的问题：在节点集合会变化的分布式系统里，把 key 稳定地映射到节点上，使得增删节点时只影响尽量少的 key。常见实现有两类：

Consistent Hashing（环 + 虚拟节点）：把节点和 key 都哈希到一个环上，key 沿环顺时针找到第一个节点；用虚拟节点改善均匀度。
Rendezvous Hashing（HRW，Highest Random Weight）：对每个 key，计算它与所有节点的哈希分数，取分数最高的节点。没有环、没有虚拟节点，纯计算。

对比结论#

参考资料：

实测的两条核心结论：

rendezvous 的均匀度更好，所有场景的均值偏差都在 10% 以内。但当集群节点数较多时，rendezvous 更耗时：100 个节点时，rendezvous 的耗时是 consistent 的一倍（因为每个 key 都要和全部节点算一遍分数，O(n)）。
consistent 随虚拟节点数量增加，均匀性越来越好，且虚拟节点数量基本不影响调度用时（哈希环 + 二分查找，O(log n)）。但均匀度和 rendezvous 比始终有差距。

怎么选#

节点数较少：直接选 rendezvous hash，简单且均匀。
节点数较多且时间敏感：选 consistent hash。
节点数较多但对均匀性要求更高、能接受耗时：依然选 rendezvous hash 来确保均匀性。

一句话：rendezvous 用计算时间换均匀度；consistent 用虚拟节点改善均匀度，查询则是哈希环上 O(log n) 的二分。

微服务鉴权与网关职责

Tue, 27 Jan 2026 00:00:00 GMT

微服务鉴权与网关职责#

核心结论#

Gateway 负责 Authentication（你是谁）
Microservice 负责 Authorization（你能干什么）

Gateway 应该做什么#

验证登录态：JWT / OAuth2 / Session / API Key
提取并传递身份上下文：x-user-id、x-user-role、x-tenant-id
公共安全能力：限流、黑名单、IP 风控、CORS、TLS、WAF、审计日志、Tracing

Service 必须做什么#

校验资源归属（是否本人数据）
校验角色权限（RBAC）
校验属性条件（ABAC，可选）
校验租户边界（tenant）

反例#

只在 Gateway 校验 JWT，service 完全信任 header。

风险：

内网横向攻击
内部请求伪造
SSRF 间接越权
资源 ID 枚举导致越权操作

gRPC 透传身份（Go）#

1
md := metadata.Pairs(
2
    "x-user-id", "123",
3
    "x-user-role", "user",
4
)
5
ctx := metadata.NewOutgoingContext(ctx, md)
6

7
// server side
8
md, _ = metadata.FromIncomingContext(ctx)
9
uid := md.Get("x-user-id")
10
role := md.Get("x-user-role")

说明：

metadata 适合内部身份上下文透传
不能只“读到 uid 就执行业务”，必须继续做业务授权校验

更成熟的内部安全#

内部签名头（例如：x-auth-signature + x-request-ts）防伪造
Service Mesh（Istio/Linkerd）做服务间 mTLS 身份认证

文件服务场景落地#

外部：HTTP/JSON -> Gateway
内部：Gateway -> gRPC filesystem-service

filesystem-service 关注：

元数据、分片、hash、配额、权限
对象存储交互
presigned URL 签发

大文件推荐：

Gateway 只签发 URL
客户端直传对象存储（S3/OSS/MinIO）

快速检查清单#

是否明确区分认证与授权
service 是否做了资源归属校验
是否有 role/tenant 维度校验
是否限制了内部伪造请求风险
上传链路是否避免 Gateway 传大文件

Minikube 本地集群

Thu, 22 Jan 2026 00:00:00 GMT

Minikube#

Minikube 是本地单节点 Kubernetes 集群，适合学习和本地验证部署 YAML。

启动和停止#

Terminal window

1
minikube start
2
minikube status
3
minikube stop
4
minikube delete

确认 kubectl 连到 minikube#

Terminal window

1
kubectl config current-context
2
kubectl get nodes

正常情况下会看到：

1
minikube

使用 minikube 内部 Docker#

本地构建镜像后，如果希望 Kubernetes 直接使用这个镜像，需要让当前 shell 的 Docker 命令指向 minikube 内部 Docker：

Terminal window

1
eval $(minikube docker-env)

之后构建的镜像会进入 minikube，可以配合：

1
imagePullPolicy: IfNotPresent

避免 Kubernetes 去远程镜像仓库拉取。

退出 minikube Docker 环境#

Terminal window

1
eval $(minikube docker-env -u)

常用调试命令#

Terminal window

1
minikube dashboard
2
minikube ssh
3
minikube image ls

本地练习#

推荐流程：

Terminal window

1
minikube start
2
eval $(minikube docker-env)
3
make build-base-image
4
APP_VERSION=dev docker compose -f docker-compose.yaml build user-api admin-api worker image-worker
5
docker tag user-api:dev localhost/user-api:dev
6
kubectl apply -k deploy/overlay/dev

Docker 镜像构建上下文

Thu, 15 Jan 2026 00:00:00 GMT

如果注意,会看到 docker build命令最后有一个 .

docker build 命令构建镜像,其实并非在本地构建,而是在服务端,也就是 Docker 引擎中构建的。那么在这种客户端/服务端的架构中,如何才能让服务端获得本地文件呢?

这就引入了上下文的概念

提供构建时所需文件
- COPY、ADD 指令引用的文件路径都必须在上下文内。
传输给 Docker daemon
- 在 docker build 时，CLI 会把上下文打包成一个 tar 包，发送给后端守护进程。
控制构建范围
- 若不小心把整个大目录（如 / 或 ~）作为上下文，会严重拖慢构建。

一个具体例子#

Terminal window

1
# 上下文 = 当前目录（末尾的 .），Dockerfile 默认为 ./Dockerfile
2
docker build -t my-app .
3

4
# 上下文 = 当前目录，但指定别的 Dockerfile
5
docker build -f microservice.Dockerfile -t my-app .
6

7
# 上下文 = 指定目录（构建时路径都相对它解析）
8
docker build -t my-app ./backend

执行 docker build . 时终端里那一行 Sending build context to Docker daemon xx MB，就是把整个上下文目录打包成 tar 传给 daemon 的过程——这也解释了为什么 COPY 不能引用上下文之外的路径（如 COPY ../foo 是非法的）。

用 .dockerignore 收窄上下文#

上下文太大不仅拖慢构建，还会把不该进镜像的文件传进 daemon。在上下文根目录放 .dockerignore：

1
.git
2
node_modules
3
dist
4
*.log
5
.env

语法类似 .gitignore。被排除的文件不会进入 tar 包，COPY . 也就拿不到它们，同时避免密钥、构建产物意外进镜像。

Kafka 的分区与副本机制

Fri, 09 Jan 2026 00:00:00 GMT

在 Kafka 中，每个 Kafka 实例称为 Broker，每个 Broker 中可以保存多个 Topic。每个 Topic 可以划分为多个分区，**每个分区保存的数据是不一样的，**这些分区可以在同一个 Broker 中，也可以在散布在不同的 Broker 中。

一个 Broker 可以存储不同 Topic 的不同分区，也可以存储同一个 Topic 的不同分区。

Pasted image 20260701172445.png

分区与复制#

主题的每个分区都有至少一个副本，也就是 --replication-factor 参数必须大于 1。副本分为 leader 和 follower 两种，每个副本都需要消耗一个存储空间，leader 对外提供读写消息，而 follower 提供冗余备份，leader 会及时将消息增量同步到所有 follower 中。

在 hello-topic 主题中，当分区只有一个副本时，或只关注 leader 副本时，leader 副本对应的 Broker 节点位置如下：

Pasted image 20260701173450.png

如果设置了多个副本( --replication-factor=3 ) 时，leader 副本和 follower 副本的位置如下所示：

Pasted image 20260701173500.png

在不同的副本中，只有 leader 副本能够进行读写，follower 接收从 leader 推送过来的数据，做好冗余备份。

Pasted image 20260701173509.png

Pasted image 20260701173520.png

Docker 镜像的分层与构建

Mon, 05 Jan 2026 00:00:00 GMT

🧱 镜像（Image）#

是一个 只读模板，包含了运行应用所需的一切：操作系统、程序代码、依赖、配置等。
它就像一份快照，可以重复使用。
构建一次，可以启动很多个容器。

Docker 镜像是由多层构成的，每一层通常是只读的。这些层通过 UnionFS (联合文件系统) 组合在一起形成一个完整的文件系统，最终在容器运行时添加一个最上面的 可写层（writeable layer）。

如果你改变了 Dockerfile 中的一层指令（如 RUN、COPY、ADD），那么它之后的所有层都会重新构建。这是 Docker 的构建缓存（build cache）机制所决定的。

如果多个命令都指向同一个目的，那么应该用一个run来进行，而不是叠加多层

用一个RUN：

1
FROM debian:jessie
2
RUN buildDeps='gcc libc6-dev make' \
3
&& apt-get update \
4
&& apt-get install -y $buildDeps \
5
&& wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz" \
6
&& mkdir -p /usr/src/redis \
7
&& tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 \
8
&& make -C /usr/src/redis \
9
&& make -C /usr/src/redis install \
10
&& rm -rf /var/lib/apt/lists/* \
11
&& rm redis.tar.gz \
12
&& rm -r /usr/src/redis \
13
&& apt-get purge -y --auto-remove $buildDeps

docker build 各种用法#

从dockerfile#

Terminal window

1
sudo docker build -f microservice.Dockerfile -t docker-jar .

Terminal window

1
sudo docker build -t minecraft-modpack-server .

从标准输入#

Terminal window

1
cat Dockerfile | docker build -

从Git repo#

Terminal window

1
docker build https://github.com/twang2218/gitlab-ce-zh.git#:8.14

Docker 指令

删除镜像#

Terminal window

1
# 删除单个镜像（可以用镜像名:tag 或镜像 ID）
2
docker rmi nginx:latest
3

4
# 强制删除（即使有基于它的容器存在）
5
docker rmi -f <image-id>
6

7
# 清理所有悬空镜像（dangling，即没有 tag 引用的中间层）
8
docker image prune
9

10
# 清理所有未被任何容器使用的镜像
11
docker image prune -a

本地负缓存

Wed, 03 Dec 2025 00:00:00 GMT

把不存在/失败结果缓存在本地内存里，短时间内直接返回，避免重复访问下游系统。

1
id=999999 不存在 → 缓存 60 秒

后面 60 秒：

1
直接返回不存在，不用查 DB

为什么需要#

典型的缓存只缓存「查到了」的结果，但线上更耗资源的往往是查不到的请求：

缓存穿透：不存在的 key 每次都要打到数据库，负面结果不缓存，等于每次都白查一遍。
下游故障放大：某个依赖超时/报错后，上层不断重试同样的失败请求，把故障放大。
恶意或爬虫流量：大量轮询不存在的资源 ID。

负缓存（negative caching）就是把「不存在 / 失败」也当成一种结果缓存起来，短时间内对同一 key 直接复用这个结论。

实现要点#

1
// 极简示意：本地 map + 过期时间
2
var negativeCache sync.Map // key -> expireAt
3

4
func GetProfile(ctx context.Context, id string) (*Profile, error) {
5
  if exp, ok := negativeCache.Load(id); ok && time.Now().Before(exp.(time.Time)) {
6
    return nil, ErrNotFound // 命中负缓存，直接返回
7
  }
8
  p, err := repo.Find(ctx, id)
9
  if errors.Is(err, ErrNotFound) {
10
    negativeCache.Store(id, time.Now().Add(60*time.Second))
11
    return nil, err
12
  }
13
  return p, err
14
}

TTL 要短：负缓存是「暂时的结论」，实体可能随后就被创建。一般秒级到一分钟，宁短勿长。
只缓存确定性失败：不存在 可以缓存；超时/网络错误 不应该固化为负缓存，否则下游恢复后仍被挡住。
要有容量上限与淘汰：本地内存是无底洞风险，配合 LRU 或分片 + 定期清理，防止被不存在的 key 撑爆。
命中打点：监控负缓存命中率，异常升高往往意味着上游调用方在犯错或有攻击流量。

与「缓存空对象」是同一个思路，只是把空值判断从 Redis 前移到进程内，省一次网络往返。

MySQL 索引与慢查询优化

Fri, 14 Nov 2025 00:00:00 GMT

每条查询的时间应该控制在200ms内否则认为是慢查询

慢查询带来的后果是：IO开销过大，锁持有时间增加，导致数据库吞吐量降低

排查与定位#

开启慢查询日志：slow_query_log=ON，long_query_time=0.2，配合 pt-query-digest 或云监控聚合分析。
用 EXPLAIN 看执行计划，重点看 type（至少到 range，避免 ALL 全表扫描）、key（实际用到的索引）、rows（预估扫描行数）、Extra（Using filesort / Using temporary 都是危险信号）。

JOIN 与数据量#

内联JOIN是求交集，数据变小

外JOIN，会导致数据量过大

JOIN 的驱动表尽量选过滤后结果集小的那张，被驱动表的关联列必须有索引。
避免在 JOIN 条件列上做函数运算或类型转换（如字符串列和数字比较），否则索引失效。

索引失效的常见场景#

对索引列使用函数或运算：WHERE DATE(created_at) = ...、WHERE id + 1 = ...。
隐式类型转换：varchar 列用数字比较。
前导模糊匹配：LIKE '%keyword'。
联合索引不满足最左前缀。
IN 列表过大：如果 IN 关键字包含的id过多，数据库有可能抛弃索引直接进行全表扫描（优化器认为回表成本高于全表扫描）。

分批查询#

如果单次查询的数据量大于1000，则最好需要分批次进行查询每批次500条

分批不只为了保护索引，还能控制单次网络包大小、减少锁持有时间与内存占用。配合覆盖索引（只 SELECT 需要的列）效果更好。

Redis 数据持久化（RDB）

Tue, 28 Oct 2025 00:00:00 GMT

Redis 提供 2 种持久化方案：

RDB 将在内存中的数据库记录定期生成快照存入磁盘中
AOF 将 Redis 的操作日志以追加的方式写入文件，

RDB#

RedisDatabase

将Redis某一时刻的内存数据写入到RDB文件中，并保存到磁盘上。该文件是一个压缩过的二进制文件，默认文件名为dump.rdb，通过该文件可以还原redis数据库的数据。在Redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中，达到恢复数据目的。

可根据 redis.conf 配置文件中设置rdb文件名和保存目录：

1
# 指定本地数据库文件名（rdb文件的名称），默认值为dump.rdb
2
dbfilename dump.rdb
3

4
# 指定本地数据库存放目录（dump.rdb文件存放目录），rdb、aof文件也会写在这个目录dir /usr/local/var/db/redis/

save#

当某个客户端发送 save 命令后，此时会阻塞当前Redis服务器，在RDB文件创建完成之前是不能处理其他客户端发送的任何命令请求，如果数据量太大会造成长时间阻塞，期间redis无法处理其他请求，线上环境不建议使用。

bgsave#

当某个客户端发送 bgsave 命令后，Redis服务器会执行fork() 函数创建一个子进程，由子进程负责rdb文件创建和写入，期间服务器不会阻塞，可以接受其他客户端的命令请求，**但在fork执行阶段，服务器还会阻塞，无法接受其他客户端命令（一般时间很短）

自动触发#

在以下几种情况时会自动触发生成 RDB 文件：

redis.conf 配置文件中达到 save 参数条件
主从复制时，从节点要从主节点进行全量复制，此时会触发 bgsave，生成快照发送到从节点
执行 shutdown，如果没有开启 AOF 持久化，会触发 bgsave
执行 flushall（生成空的 dump.rdb！）

flushall#

flushall 生成的是空dump.rdb文件，目的是覆盖并删除上次备份的快照，防止redis重启时，自动载入并恢复到上一份备份数据！

DDD 领域驱动设计入门

Sat, 11 Oct 2025 00:00:00 GMT

DDD（Domain-Driven Design，领域驱动设计） 不是一种框架，而是一种面向复杂业务系统的软件设计方法论。

它的核心思想是：

软件结构应该围绕业务领域（Domain）组织，而不是围绕数据库、接口、框架组织。

为什么会有 DDD#

很多项目一开始都是这样：

1
controller
2
service
3
repository
4
model

例如：

1
user_controller.go
2
user_service.go
3
user_repo.go

当业务简单时没问题。

但随着需求增加：

1
用户
2
订单
3
支付
4
优惠券
5
库存
6
物流
7
积分

Service 会越来越大：

1
func CreateOrder() {
2
    检查库存
3
    检查优惠券
4
    扣减库存
5
    创建订单
6
    创建支付单
7
    发MQ
8
}

最后：

1
OrderService
2
3000行

业务规则散落在：

Controller
Service
SQL
MQ Consumer

维护起来很痛苦。

DDD 就是为了解决：

复杂业务逻辑如何长期演进。

DDD 的核心概念#

1. Domain（领域）#

领域就是业务范围。

例如电商：

1
电商系统
2
├── 用户领域
3
├── 订单领域
4
├── 支付领域
5
├── 库存领域
6
└── 物流领域

每个领域独立思考。

“这个东西如果脱离 HTTP、数据库、缓存、消息队列，仍然有业务意义吗？”

如果有，可能属于 domain
如果没有，多半不属于 domain

2. Entity（实体）#

有唯一身份的对象。

例如：

1
type User struct {
2
    ID int64
3
    Name string
4
}

即使名字变了：

1
张三 → 李四

还是同一个用户。

因为：

1
ID没变

3. Value Object（值对象）#

没有身份。

只关心值。

例如：

1
type Money struct {
2
    Amount int64
3
    Currency string
4
}

两个：

1
100 CNY
2
100 CNY

就是相等的。

4. Aggregate（聚合）#

DDD最重要概念之一。

例如订单：

1
Order
2
├── OrderItem
3
├── Address
4
└── PaymentInfo

这些对象一起维护一致性。

形成：

1
Order Aggregate

聚合根（Aggregate Root）#

外部只能访问：

1
Order

不能直接改：

1
OrderItem

例如：

1
order.AddItem(...)

而不是：

1
order.Items[0].Count++

这样业务规则集中。

Repository#

Repository 不是 DAO。

DAO：

1
db.Create(...)

Repository：

1
type OrderRepository interface {
2
    Save(order *Order)
3
    FindByID(id string)
4
}

领域层不知道：

1
MySQL
2
PostgreSQL
3
Redis

Domain Service#

有些业务不属于某个实体。

例如：

1
订单创建
2
需要：
3

4
库存
5
优惠券
6
支付

放进 Order 也不合适。

这时：

1
type OrderDomainService struct {}

负责跨聚合逻辑。

Application Service#

很多人容易混淆。

DDD里通常：

1
Controller
2
 ↓
3
Application Service
4
 ↓
5
Domain
6
 ↓
7
Repository

Application Service：

负责：

编排流程
事务
调用领域对象

例如：

1
func CreateOrder(cmd CreateOrderCommand) {
2
    order := domain.NewOrder()
3

4
    order.AddItem(...)
5

6
    repo.Save(order)
7

8
    mq.Publish(...)
9
}

分层架构#

经典 DDD：

1
┌──────────────────┐
2
│ Presentation     │
3
│ Controller/API   │
4
└────────┬─────────┘
5
         ▼
6
┌──────────────────┐
7
│ Application      │
8
│ Use Case         │
9
└────────┬─────────┘
10
         ▼
11
┌──────────────────┐
12
│ Domain           │
13
│ Entity           │
14
│ Aggregate        │
15
│ Domain Service   │
16
└────────┬─────────┘
17
         ▼
18
┌──────────────────┐
19
│ Infrastructure   │
20
│ DB MQ Redis      │
21
└──────────────────┘

展开收起

Go 项目常见目录#

1
internal/
2

3
├── application
4
│   └── order
5
│       └── service.go
6

7
├── domain
8
│   └── order
9
│       ├── entity.go
10
│       ├── repository.go
11
│       └── service.go
12

13
├── infrastructure
14
│   └── repository
15
│       └── order_repo.go
16

17
└── interfaces
18
    └── http
19
        └── order_handler.go

展开收起

在微服务里怎么用#

假设你之前说的在线判题系统：

1
gateway
2
user
3
problem
4
judge
5
sandbox

每个微服务都可以有自己的领域。

例如：

problem-service#

1
Problem
2
Tag
3
SubmissionRule

judge-service#

1
Submission
2
JudgeTask
3
JudgeResult

user-service#

1
User
2
Role
3
Permission

DDD 和 MVC 的区别#

MVC：

1
Controller
2
 ↓
3
Service
4
 ↓
5
DAO

关注：

1
代码分层

DDD：

1
Domain
2
 ↓
3
Aggregate
4
 ↓
5
Business Rules

关注：

1
业务建模

所以：

MVC 是技术视角，DDD 是业务视角。

两者并不冲突。

什么时候值得引入 DDD#

如果是学习性质的：

1
Gateway
2
User
3
Problem
4
Judge
5
Sandbox

我的建议是：

第一阶段#

普通三层：

1
handler
2
service
3
repo

先把功能跑通。

第二阶段#

当出现：

1
提交代码
2
↓
3
创建Submission
4
↓
5
发MQ
6
↓
7
Judge消费
8
↓
9
更新结果
10
↓
11
更新排行榜

这种复杂业务流时，

再引入：

1
Aggregate
2
Domain Service
3
Repository

会更容易体会 DDD 的价值。

否则很容易变成：

1
为了DDD而DDD

写了很多目录和接口，但业务复杂度还没到那个程度。对于一个在线判题系统这类项目，比较合适的路线通常是：

1
三层架构
2
    ↓
3
理解微服务
4
    ↓
5
事件驱动(MQ)
6
    ↓
7
DDD Lite
8
    ↓
9
完整DDD

这样学习曲线会平滑很多，也更符合实际项目的演进过程。

Python StrEnum 与 Literal 的区别

Wed, 10 Sep 2025 00:00:00 GMT

StrEnum 和 Literal 虽然都能限制字符串取值，但用途完全不同。

1. StrEnum：运行时的枚举类型#

Python 3.11+

1
from enum import StrEnum
2

3
class Status(StrEnum):
4
    PENDING = "pending"
5
    SUCCESS = "success"
6
    FAILED = "failed"

使用：

1
status = Status.PENDING
2

3
print(status)          # pending
4
print(status.value)    # pending

特点：

运行时真实存在的对象
可以遍历
可以比较
可以作为配置、数据库字段、API参数等统一定义

1
for s in Status:
2
    print(s)

1
if status == Status.PENDING:
2
    ...

2. Literal：类型提示#

来自 typing

1
from typing import Literal
2

3
Status = Literal[
4
    "pending",
5
    "success",
6
    "failed"
7
]

使用：

1
def update_status(
2
    status: Status
3
):
4
    ...

IDE 会提示：

1
update_status("pending")  # ✅
2

3
update_status("abc")      # ❌ 类型检查报错

特点：

只存在于类型系统
运行时没有枚举对象
不能遍历
不能写 Status.PENDING

1
print(Status)

输出：

1
typing.Literal['pending', 'success', 'failed']

对比#

特性	StrEnum	Literal
运行时存在	✅	❌
类型检查	✅	✅
可遍历	✅	❌
可作为常量	✅	❌
IDE 自动补全	✅	一般
JSON/API 参数约束	✅	✅
数据库存储映射	✅	❌

FastAPI/Pydantic 场景#

通常推荐：

1
from enum import StrEnum
2

3
class ModelProvider(StrEnum):
4
    OPENAI = "openai"
5
    ANTHROPIC = "anthropic"
6
    GEMINI = "gemini"

1
from pydantic import BaseModel
2

3
class Request(BaseModel):
4
    provider: ModelProvider

自动生成 OpenAPI：

1
{
2
  "enum": [
3
    "openai",
4
    "anthropic",
5
    "gemini"
6
  ]
7
}

同时还能：

1
if req.provider == ModelProvider.OPENAI:
2
    ...

什么时候用 Literal？#

当你只是想约束几个字符串参数，而且不会在别处复用：

1
def create_message(
2
    role: Literal[
3
        "user",
4
        "assistant",
5
        "system"
6
    ]
7
):
8
    ...

这种场景用 Literal 很轻量。

实际项目建议#

业务领域概念（状态、模型提供商、订单类型等） → StrEnum
函数参数的简单约束 → Literal
FastAPI/Pydantic Schema → 优先 StrEnum

很多大型 Python 项目（如 Pydantic、FastAPI、LangGraph 等）最终都会把重要的字符串常量抽成 StrEnum，因为它既有类型安全，又有运行时能力。

Gin 模型绑定与验证

Tue, 02 Sep 2025 00:00:00 GMT

使用时，需要在要绑定的所有字段上，设置相应的tag。例如，使用 JSON 绑定时，设置字段标签为 json:"fieldname"。

Gin提供了两类绑定方法：

Type - Must bind
- Methods - Bind, BindJSON, BindXML, BindQuery, BindYAML
- Behavior - 这些方法属于 MustBindWith 的具体调用。如果发生绑定错误，则请求终止，并触发 c.AbortWithError(400, err).SetType(ErrorTypeBind)。响应状态码被设置为 400 并且 Content-Type 被设置为 text/plain; charset=utf-8。如果您在此之后尝试设置响应状态码，Gin会输出日志 [GIN-debug] [WARNING] Headers were already written. Wanted to override status code 400 with 422。如果您希望更好地控制绑定，考虑使用 ShouldBind 等效方法。
Type - Should bind
- Methods - ShouldBind, ShouldBindJSON, ShouldBindXML, ShouldBindQuery, ShouldBindYAML
- Behavior - 这些方法属于 ShouldBindWith 的具体调用。如果发生绑定错误，Gin 会返回错误并由开发者处理错误和请求。

使用 Bind 方法时，Gin 会尝试根据 Content-Type 推断如何绑定。如果你明确知道要绑定什么，可以使用 MustBindWith 或 ShouldBindWith。

你也可以指定必须绑定的字段。如果一个字段的 tag 加上了 binding:"required"，但绑定时是空值, Gin 会报错。

如果结构体的某个字段本身也是一个结构体（嵌套结构体），为了正确验证，该结构体的字段也需要添加 binding:"required" 标签。

1
// 绑定 JSON
2
type Login struct {
3
  User     string `form:"user" json:"user" xml:"user"  binding:"required"`
4
  Password string `form:"password" json:"password" xml:"password" binding:"required"`
5
}
6

7
func main() {
8
  router := gin.Default()
9

10
  // 绑定 JSON ({"user": "manu", "password": "123"})
11
  router.POST("/loginJSON", func(c *gin.Context) {
12
    var json Login
13
    if err := c.ShouldBindJSON(&json); err != nil {
14
      c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
15
      return
16
    }
17

18
    if json.User != "manu" || json.Password != "123" {
19
      c.JSON(http.StatusUnauthorized, gin.H{"status": "unauthorized"})
20
      return
21
    }
22

23
    c.JSON(http.StatusOK, gin.H{"status": "you are logged in"})
24
  })
25

26
  // 绑定 XML (
27
  //  <?xml version="1.0" encoding="UTF-8"?>
28
  //  <root>
29
  //    <user>manu</user>
30
  //    <password>123</password>
31
  //  </root>)
32
  router.POST("/loginXML", func(c *gin.Context) {
33
    var xml Login
34
    if err := c.ShouldBindXML(&xml); err != nil {
35
      c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
36
      return
37
    }
38

39
    if xml.User != "manu" || xml.Password != "123" {
40
      c.JSON(http.StatusUnauthorized, gin.H{"status": "unauthorized"})
41
      return
42
    }
43

44
    c.JSON(http.StatusOK, gin.H{"status": "you are logged in"})
45
  })
46

47
  // 绑定 HTML 表单 (user=manu&password=123)
48
  router.POST("/loginForm", func(c *gin.Context) {
49
    var form Login
50
    // 根据 Content-Type Header 推断使用哪个绑定器。
51
    if err := c.ShouldBind(&form); err != nil {
52
      c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
53
      return
54
    }
55

56
    if form.User != "manu" || form.Password != "123" {
57
      c.JSON(http.StatusUnauthorized, gin.H{"status": "unauthorized"})
58
      return
59
    }
60

61
    c.JSON(http.StatusOK, gin.H{"status": "you are logged in"})
62
  })
63

64
  // 监听并在 0.0.0.0:8080 上启动服务
65
  router.Run(":8080")
66
}

展开收起

Go 的 Small Interface 设计理念

Tue, 05 Aug 2025 00:00:00 GMT

C++ 使用时必须依赖头文件声明接口，而 Go 却可以在消费端就地定义 interface，由类型隐式满足契约。这个差异的核心在于语言的设计哲学、实现机制和编译模型的不同。 Go 和 C++ 在“契约”（contract）定义方式上的对比，体现了两种完全不同的编程范式。

1. C++ 的方式：生产者提供全局 Header 作为契约（显式、中心化）#

历史和编译模型驱动：C++ 继承自 C 的分离编译（separate compilation）模型。源文件（.cpp）分开编译成对象文件，再链接。编译器在编译一个 .cpp 时，需要知道其他模块的声明（类型、函数签名、类布局等），否则无法生成正确的代码（尤其是虚函数表、内存布局等）。
- Header 文件（.h/.hpp）就是这个“声明”的载体。它定义了类、函数、虚方法等，作为全局可见的契约。
- 生产者（库作者）必须在 header 中把接口写好，消费者（用户代码）通过 #include 来使用。
显式实现：类需要显式继承抽象基类（带纯虚函数），或使用模板。改变 header 往往影响 ABI（二进制兼容性），容易导致“header hell”、编译时间爆炸和耦合。
优势：适合大型系统，需要精确控制内存布局、性能和二进制接口（比如游戏引擎、系统库）。header 像一份“公开规格书”。

这是生产者驱动（producer-driven）的契约：生产者决定“我的东西长什么样，你们都得按这个来”。

2. Go 的方式：消费者在消费端定义 interface（隐式、分散化）#

编译模型不同：Go 没有 header，整个 package 一起编译（快速构建是 Go 的核心目标之一）。编译器能直接看到所有源码，不需要单独的声明文件。
隐式满足（Implicit Implementation）：这是 Go 接口最关键的特性。
- 一个类型只要实现了 interface 声明的所有方法，就自动满足该 interface，不需要 implements 关键字。
- 接口本身只是一组方法签名的集合（往往很小，比如 io.Reader 只一个 Read 方法）。
消费者定义：推荐在使用接口的地方（消费者包）定义 interface，而不是在提供具体实现的包里。

为什么 Go 这样设计？

解耦和灵活性：生产者只需提供具体类型（struct + 方法），不需要预知所有可能的用法。消费者根据自己当前需求定义最小化的 interface（“我只需要这些行为”）。这符合 Go “小接口、大组合”的哲学（Small Interfaces）。
- 例子：标准库的 io.Reader、io.Writer、fmt.Stringer 等，都是极小的接口，定义在需要它们的地方。
减少依赖：消费者定义 interface 时，不需要导入生产者包里的接口定义（避免循环依赖或不必要的包依赖）。测试时特别方便——你可以轻松 mock 一个只满足你自定义 interface 的假对象。
Duck Typing 的静态检查版：像动态语言的鸭子类型，但编译期就检查。生产者代码不需要“知道”任何 interface 的存在。
设计哲学：Go 强调简单、可维护、少预判。生产者不用在设计时“预见所有用例”（这往往会导致胖接口、违背接口隔离原则）。消费者只依赖自己真正需要的行为，代码更松耦合、更易演化。

总结对比#

方面	C++ (Header)	Go (Interface)
谁定义契约	生产者（全局 header）	消费者（使用处定义）
实现方式	显式（继承、声明）	隐式（只要有方法就行）
接口大小	倾向较大、完整类接口	极小、单一职责（one-method 常见）
耦合度	较高（header 变更影响大）	极低
适用场景	性能敏感、大型系统、ABI 稳定	微服务、快速迭代、测试友好
根本原因	分离编译 + 历史传统	统一编译 + 现代简约哲学

Go 的这种设计不是“随意”，而是深思熟虑的结果：它让接口真正成为“行为契约”而非“类型层次结构”。很多从 Java/C++ 转 Go 的人初期会不适应（总想在生产者端定义大接口），但用熟后会发现测试、扩展和维护都轻松很多。

CMake：add_subdirectory 与 add_library 的区别

Tue, 15 Jul 2025 00:00:00 GMT

If you want to compile the code into your project directly, that’s not a library, that’s just code.

A library is a distinct compiled and linked object. A static library is a .a/.lib file, a shared library is a .so/.dll file.

If you just want to add source code files to your current target, you do so with target_sources() and that’s it. No need to create a library at all.

So with that in mind, we can now talk about the commands:

add_subdirectory(): This has nothing to do with libraries, this just runs the CML of a subdirectory. The code in that CML can do anything, maybe it creates a library, maybe it adds source code files to your current project, maybe it plays a little song and prints messages to your build log

add_library(): This creates a new library target, a new .lib or .dll file to be compiled and linked. It is the sister command to add_executable(), which creates a new binary executable target (.exe on Windows)

target_link_libraries(): This links a library, maybe created in your current project or maybe an imported library from find_package()/find_library(), into a target

CMake target_include_directories 的三种作用域

Tue, 08 Jul 2025 00:00:00 GMT

`target_include_directories()`#

命令可以为目标指定包含目录，并且可以使用 PRIVATE、INTERFACE 或 PUBLIC 来控制这些包含目录的作用范围以及它们是否会传播给其他依赖该目标的目标。

1. `PRIVATE`#

PRIVATE 意味着包含目录仅对该目标自身可见，它不会传播给链接该目标的其他目标。

1
target_include_directories(MyTarget PRIVATE include/)

使用场景：目标在自身编译时需要该包含目录，但不希望其他链接到这个目标的目标使用该目录。

2. `INTERFACE`#

INTERFACE 表示该目标本身不需要这个包含目录，但是链接到这个目标的其他目标会需要它。

1
target_include_directories(MyTarget INTERFACE include/)

使用场景：该目标是一个头文件库（例如header-only library），它自身不需要包含目录，但任何链接到它的目标都需要这个包含目录来编译。

3. `PUBLIC`#

PUBLIC 意味着包含目录对该目标自身和链接到该目标的其他目标都可见。它既会用于编译这个目标，也会传播给任何依赖它的其他目标。

1
target_include_directories(MyTarget PUBLIC include/)

使用场景：该目标在编译时需要包含目录，同时任何依赖这个目标的其他目标也需要该包含目录。

总结：#

可见性	目标本身使用	链接到该目标的其他目标使用
`PRIVATE`	是	否
`INTERFACE`	否	是
`PUBLIC`	是	是

Go 的 map

Fri, 20 Jun 2025 00:00:00 GMT

map 是引用类型，可以使用如下声明：

map 不是”简单结构”，是复杂的引用类型，必须 make 分配底层哈希表内存。

1
var map1 map[keytype]valuetype
2
var map1 map[string]int

在声明的时候不需要知道 map 的长度，map 是可以动态增长的。

未初始化的 map 的值是 nil。

key 可以是任意可以用 == 或者 != 操作符比较的类型，比如 string、int、float32(64)。所以数组、切片和结构体不能作为 key (译者注：含有数组切片的结构体不能作为 key，只包含内建类型的 struct 是可以作为 key 的），但是指针和接口类型可以。如果要用结构体作为 key 可以提供 Key() 和 Hash() 方法，这样可以通过结构体的域计算出唯一的数字或者字符串的 key。

value 可以是任意类型的；通过使用空接口类型（详见第 11.9 节），我们可以存储任意值，但是使用这种类型作为值时需要先做一次类型断言（详见第 11.3 节）。

1
package main
2
import "fmt"
3

4
func main() {
5
  var mapLit map[string]int
6
  //var mapCreated map[string]float32
7
  var mapAssigned map[string]int
8

9
  mapLit = map[string]int{"one": 1, "two": 2}
10
  mapCreated := make(map[string]float32)
11
  mapAssigned = mapLit
12

13
  mapCreated["key1"] = 4.5
14
  mapCreated["key2"] = 3.14159
15
  mapAssigned["two"] = 3
16

17
  fmt.Printf("Map literal at \"one\" is: %d\n", mapLit["one"])
18
  fmt.Printf("Map created at \"key2\" is: %f\n", mapCreated["key2"])
19
  fmt.Printf("Map assigned at \"two\" is: %d\n", mapLit["two"])
20
  fmt.Printf("Map literal at \"ten\" is: %d\n", mapLit["ten"])
21
}

展开收起

Wooden Toy Festival 题解：二分答案与贪心验证

Sun, 25 May 2025 00:00:00 GMT

题意：#

有三个雕刻师，他们需要制作n个玩具，对于n个玩具，每个玩具都有一个图案值a[i]，

如果雕刻师选择的图案是 x ，那么为他制作一个图案为 y 的玩具需要 |x−y| 的时间，因为玩具越像他能立即制作的玩具，雕刻师的工作速度就越快。

雕刻师们都是非常熟练的人，可以同时处理不同玩具雕刻师们希望在选择准备工作的样式时，尽可能减少完成制作所有玩具所需要的等待时间

要求你求出制作出所有玩家所需要的最短等待时间

分析#

当需要求某个数是最大值/最小值的时候，会考虑到问题是否可以通过二分搜索来解决。

能用二分搜索解决的问题通常具有单调性，而对于本题，很明显的一个事实是如果等待时间越短，那么三个雕刻师一开始所选择的图案就与越多的玩具的a[i]相似.。

而且，还注意到，如果3个雕刻师能够在 t 的时间内制作所有的玩具，那么3个雕刻师必定也能在 d (d > t) 的时间内也制作所有的玩具

因此我们可以尝试二分搜索可行的时间（即三个雕刻师是否可以在这个时间内把所有的玩具制作完），一旦查到可行的时间，我们便试着不断缩小搜索的区间去把mid值逼近最优解。

条件判断#

那么现在的问题是该如何判断三者可以在时间 t 内制作所有玩具？

想象一下，如果我们给三个雕刻师分别分配任务，时间 t 实际上取决于三者之间最晚完成任务的人。考虑到任务分配的顺序是没有影响的，那么我们最好对图案数组先排序一次，因为排序后的数组中对于任意的 (i, j)，他们的 |a[i] - a[j]| 的值总要比未排序的要小。

也就是因为这个排序后的性质，如果我们在排序后的数组里面按顺序分配任务，选定 i，某个雕刻师在 t 时间内能制作完成的玩具数量即为在 [a[i], a[i] + 2*x] 值区间内的 a[i] 的数量

所以剩下来的部分就只有模拟了，我们模拟分配工作给雕刻师，记录当前已完成制作的玩具的数量 cur，每名雕刻师的工作完成后cur都会增加，而这个cur后面的玩具又会交给下一个雕刻师，最后检查cur是否到达n个数量即可

详细代码#

1
#include <bits/stdc++.h>
2
using namespace std;
3

4
const int mod = 1e6+10;
5
typedef long long ll;
6
#define x first
7
#define y second
8
typedef pair<int, int> P;
9

10
ll v[mod];
11
ll n;
12

13
bool check(ll x) {
14
  int cur = 0;
15
    for (int i = 0; i < 3; ++i) {
16
        int start = v[cur];
17
        int end = start + 2 * x;
18
        while (cur < n && v[cur] <= end) {
19
            ++cur;
20
        }
21
        if (cur >= n) {
22
            return true;
23
        }
24
    }
25

26
    return cur >= n;
27
}
28

29
void solve() {
30
  cin >> n;
31

32
  for (int i = 0; i < n; i++) {
33
    cin >> v[i];
34
  }
35

36
  sort(v, v+n);
37

38
  ll l = 0, r = 1e9;
39
  ll mid,ans=1e9;
40
  //mid为三者雕刻所需要的最大时间
41
  //check的时候，尽可能多的在mid时间内为雕刻师安排多的v
42
  //显然这个问题具有单调性，如果用时越久，模具的制作偏差就越大
43
  while (l <= r) {
44
    mid=(l+r)>>1;
45
    if (check(mid)) {
46
      r = mid-1;
47
      ans = mid;
48
    } else {
49
      l = mid+1;
50
    }
51
  }
52
  cout << ans << endl;
53
}
54

55
int main() {
56
    ios_base::sync_with_stdio(false);
57
    cin.tie(NULL);
58
    cout.tie(NULL);
59

60
  int t;
61
  cin >> t;
62
  while(t--) solve();
63

64
  return 0;
65
}

展开收起

CF 957E Novice's Mistake 题解

Sun, 09 Mar 2025 00:00:00 GMT

原题#

K1o0n 的第一个编程问题是这样的”Noobish_Monk有 n 个朋友。 (1≤n≤100) 个朋友。每个朋友都给了他 a (1≤a≤10000) 个苹果。 (1≤a≤10000) 个苹果作为生日礼物。收到这样的礼物后，诺比什/蒙克很高兴，他回赠了 b (1≤b≤min(10000,a⋅n)) 个苹果。 (1≤b≤min(10000,a⋅n)) 个苹果给他的朋友们。诺比西和尚还剩下多少个苹果？”

K1o0n 写了一个解决方案，但不小心把 n 的值看成了字符串，所以 n⋅a−b 的值的计算方法不同。具体来说

当用字符串 n 乘以整数 a 时，他将得到字符串 s=n+n+⋯+n+n (a times) 从字符串 s 中减去整数 b 时，将删除最后的 b 个字符。如果 b 大于或等于字符串 s 的长度，则字符串 s将变为空。了解到这一点后，ErnKor 开始关注在给定的 n 中，有多少对 (a,b) 满足问题的约束条件，而 K1o0n 的解给出了正确答案。

“解法给出了正确答案 “意味着它输出了一个非空字符串，这个字符串转换成整数后等于正确答案，即 n⋅a−b 的值。

输入#

第一行包含一个整数 t ( 1≤t≤100) - 测试用例数。对于每个测试用例，单行输入包含一个整数 n ( 1≤n≤100)。保证在所有测试用例中， n 都是不同的。

输出#

对于每个测试用例，按以下格式输出答案：在第一行，输出整数 x - 给定 n 的坏测试次数。在接下来的 x 行中，输出两个整数 ai 和 bi - K1o0n 在测试” n “中的解决方案的整数。 ai bi” 得到正确答案。

Input

Output

题目大意：#

给你一个整数n，现在对于n*a - b有两种运算：

n作为一个字符往后延伸至a个，然后从最后减去b个字符
n作为一个数字，进行运算n*a - b

需要你求出 (a, b) 不同的组合数，使得两种运算后的结果相同。

思考#

此题的数据范围不大，使用暴力枚举再调整合适的枚举范围是可以通过的。

对于此题，我们容易想到O(n^2)的暴力解法，即从010000枚举a再从 0a*n 去枚举b 但是这样子做必定会超时，我们不可能直接按题目给的范围去直接枚举b

调整上界#

由于在第一种操作中，减去b会使得na减去b个字符，结果的字符串字符数不可能为负数因此b的上界即是na的字符串的最长长度，即 |n|*a，即数字n变成字符串后的长度再乘每次枚举的a

所以我们确定b的上界为 |n|*a

1
int len = 0;
2
while (tmp[len]) {
3
  arr[len] = tmp[len]-'0';
4
  len++;
5
}
6
for (int a = 1; a <= 10000; a++)
7
  for (int b = 0; b <= a*len; b++)

调整下界#

回到题目观察数据范围，我们发现n*a - b的范围是严格小于 10^6的，也就是说，按照第一种操作，字符串的长度最多不会超过6个字符，于是下界minB的计算：|n|∗a−minB≤6 minB=|n|∗a−6

比较两种计算的值#

十进制逐位加，注意一个小技巧：这里对arr下标取余运算，我们设arr是一个大小为3的数组，下标存的是 n 的每一位数字

1
val = (n*a) - b; //具体值
2
rep = (a*len - b); //目标的字符串有多长
3

4
if (!val || !rep) {
5
  break;
6
}
7

8
int r = 0;
9
for (int i = 0; i < rep; i++) {
10
  r = r * 10 + arr[i%len];
11
}
12
if (r == val) {
13
  ans.push_back({a, b});
14
}

题解代码#

1
#include <bits/stdc++.h>
2
using namespace std;
3

4
const int mod = 1e6+10;
5
typedef long long ll;
6
#define x first
7
#define y second
8
typedef pair<int, int> P;
9

10
void solve() {
11
    int n;
12
    cin >> n;
13

14
    vector<P> ans;
15
    int val;
16
    int rep;
17
    int d;
18

19
    int arr[3];
20
    char tmp[256] {};
21
    itoa(n, tmp, 10);
22
    int len = 0;
23

24
    while (tmp[len]) {
25
        arr[len] = tmp[len]-'0';
26
        len++;
27
    }
28

29
    for (int a = 1; a <= 10000; a++) {
30
        //对于B:  上界: a*len-1，下界: a*len-6 (在区间内最多不会超过6个字符)
31
        for (int b = max(1, len*a -5); b <= a*len; b++) {
32
            val = (n*a) - b; //具体值
33
            rep = (a*len - b); //目标的字符串有多长
34

35
            if (!val || !rep) {
36
                break;
37
            }
38

39
            int r = 0;
40
            for (int i = 0; i < rep; i++) {
41
                r = r * 10 + arr[i%len];
42
            }
43
            if (r == val) {
44
                ans.push_back({a, b});
45
            }
46
        }
47
    }
48

49
    cout << ans.size() << endl;
50
    for (int i = 0; i < ans.size(); i++) {
51
        cout << ans[i].x << ' ' << ans[i].y << endl;
52
    }
53
}
54

55
int main() {
56
    ios_base::sync_with_stdio(false);
57
    cin.tie(NULL);
58
    cout.tie(NULL);
59

60
    int t;
61
    cin >> t;
62
    while (t--)
63
        solve();
64

65
    return 0;
66
}

展开收起

Tarjan 算法求强连通分量

Sun, 12 Jan 2025 00:00:00 GMT

Tarjan 算法是一种用于 求强连通分量（SCC, Strongly Connected Components） 的高效算法，时间复杂度 O(n + m)，其中 nnn 是顶点数，mmm 是边数。它基于 深度优先搜索（DFS），使用回溯的思想来判断一个点是否属于同一个 SCC。

1. Tarjan 算法核心思路#

时间戳（dfn）：记录每个节点的 DFS 访问次序，每个点的 dfn[u] 值是其访问顺序（从 1 开始递增）。
最小可达值（low）：记录 当前节点能通过 DFS 访问到的最早的节点。

如果 low[u] == dfn[u]，说明 u 是一个 SCC 的根，栈中 u 及其上方的所有点属于同一 SCC。

栈（stack）：维护 SCC，确保 SCC 内的点按拓扑顺序排列。
入栈标记（in_stack）：用于判断当前节点是否在栈中，避免重复计算。

2. Tarjan 代码框架#

1
#include <bits/stdc++.h>
2
using namespace std;
3

4
const int N = 1e5 + 5;  // 最大节点数
5
vector<int> graph[N];   // 邻接表存储图
6
int dfn[N], low[N], scc_id[N], ts = 0, scc_cnt = 0;
7
bool in_stack[N];
8
stack<int> stk;
9

10
void tarjan(int u) {
11
    dfn[u] = low[u] = ++ts;  // 设置访问次序
12
    stk.push(u);
13
    in_stack[u] = true;
14

15
    for (int v : graph[u]) {
16
        if (!dfn[v]) {  // 递归访问
17
            tarjan(v);
18
            low[u] = min(low[u], low[v]);  // 回溯更新 low 值
19
        } else if (in_stack[v]) {  // 发现回边
20
            low[u] = min(low[u], dfn[v]);
21
        }
22
    }
23

24
    if (dfn[u] == low[u]) {  // 发现 SCC 根
25
        ++scc_cnt;
26
        while (true) {
27
            int v = stk.top();
28
            stk.pop();
29
            in_stack[v] = false;
30
            scc_id[v] = scc_cnt;  // 给 SCC 赋编号
31
            if (v == u) break;
32
        }
33
    }
34
}
35

36
void find_scc(int n) {
37
    for (int i = 1; i <= n; i++) {
38
        if (!dfn[i]) tarjan(i);
39
    }
40
}

展开收起

3. Tarjan SCC 代码详解#

(1) dfn[u] 和 low[u]#

dfn[u]：表示 访问次序，用递增的时间戳标记。
low[u]：表示 回溯能到的最早访问点。
更新规则：

low[u] = min(low[u], low[v])（如果 v 是 u 的子节点）。 low[u] = min(low[u], dfn[v])（如果 v 已访问，且 v 在栈中）。

(2) SCC 识别#

如果 dfn[u] == low[u]，说明 u 是 SCC 根，栈中 u 及其上方的所有点属于同一 SCC。
SCC 出栈的顺序即拓扑序，可以用于 缩点（Condensation Graph）。

4. SCC 相关应用#

(1) 求缩点 DAG#

SCC 形成后，我们可以 建立一个新的 DAG（有向无环图），以 SCC 为点，SCC 之间有向边：

1
vector<int> scc_graph[N];  // SCC 缩点后的图
2
vector<int> scc_in_degree(N, 0);  // SCC 入度
3

4
void build_scc_graph(int n) {
5
    for (int u = 1; u <= n; u++) {
6
        for (int v : graph[u]) {
7
            if (scc_id[u] != scc_id[v]) {  // 仅当 u, v 属于不同 SCC 时建边
8
                scc_graph[scc_id[u]].push_back(scc_id[v]);
9
                scc_in_degree[scc_id[v]]++;
10
            }
11
        }
12
    }
13
}

(2) 统计有向图中的「强连通块」#

Tarjan 算法可以用于求解 一个图最多能划分成多少个强连通块：

1
cout << "图的强连通分量个数: " << scc_cnt << endl;

(3) 计算入度为 0 的 SCC 数量#

入度为 0 的 SCC 在缩点 DAG 中没有前驱，可用于拓扑排序：

1
int zero_in_degree_scc = 0;
2
for (int i = 1; i <= scc_cnt; i++) {
3
    if (scc_in_degree[i] == 0) {
4
        zero_in_degree_scc++;
5
    }
6
}

(4) 计算强连通分量中的最小代价#

有时 SCC 内有一些数值（如贿赂代价、最小值等），可以用 SCC 合并后取最小值：

1
vector<int> scc_min_cost(scc_cnt + 1, INF);
2
for (int i = 1; i <= n; i++) {
3
    scc_min_cost[scc_id[i]] = min(scc_min_cost[scc_id[i]], cost[i]);
4
}

5. 复杂度分析#

Tarjan 的时间复杂度：

每个点 被访问 1 次（O(n)）。每条边 被遍历 1 次（O(m)）。 总时间复杂度 O(n + m)，适用于 大规模数据（如 n,m≤105n, m \leq 10^5n,m≤105）。

0-1 背包问题

Sun, 15 Dec 2024 00:00:00 GMT

1
题意概要：有 n 个物品和一个容量为 W 的背包，每个物品有重量 w_{i} 和价值 v_{i} 两种属性，要求选若干物品放入背包使背包中物品的总价值最大且背包中物品的总重量不超过背包的容量。

在上述例题中，由于每个物体只有两种可能的状态（取与不取），对应二进制中的 000 和 111，这类问题便被称为「0-1 背包问题」。

例题中已知条件有第 i 个物品的重量 w_{i}，价值 v_{i}，以及背包的总容量 W。设 DP 状态 f_{i,j} 为在只能放前 i 个物品的情况下，容量为 j 的背包所能达到的最大总价值。

考虑转移。假设当前已经处理好了前 i-1 个物品的所有状态，那么对于第 i 个物品，当其不放入背包时，背包的剩余容量不变，背包中物品的总价值也不变，故这种情况的最大价值为 f_{i-1,j}；当其放入背包时，背包的剩余容量会减小 w_{i}，背包中物品的总价值会增大 v_{i}，故这种情况的最大价值为 f_{i-1,j-w_{i}}+v_{i}。由此可以得出状态转移方程：

物品放入背包后，总重量增加 wiw_iwi，背包剩余容量减少，所以容量是 j−wij-w_ij−wi

Pasted image 20240314225745.png

1. 二维动态规划解法#

最直接的思路是使用二维数组来记录状态。定义dp[i][j]表示前i个物品在背包容量为j时所能达到的最大价值。

状态转移方程：

如果不选第i个物品，dp[i][j] = dp[i-1][j]。
如果选第i个物品，dp[i][j] = dp[i-1][j-wi] + vi，其中wi是第i个物品的重量，vi是其价值。

综合以上两种情况：

1
dp[i][j]=max(dp[i−1][j],dp[i−1][j−wi]+vi)

时间复杂度：O(n * W)，空间复杂度也是O(n * W)。

2. 一维动态规划优化#

通过观察上述二维动态规划方程，可以发现dp[i][j]只依赖于dp[i-1][j]和dp[i-1][j-wi]。因此，dp数组当前行的值只与前一行有关，所以我们可以通过一维数组来保存这些状态，从而降低空间复杂度。

优化思路：

使用一维数组dp[j]，表示在背包容量为j时，能得到的最大价值。
按照从大到小的顺序更新dp[j]，这样可以确保在计算dp[j]时，dp[j-wi]使用的是上一轮的值，即“前一行”的状态。

状态转移方程（与二维数组时类似）

1
dp[j]=max(dp[j],dp[j−wi]+vi)

最大上升三元组数量

Sun, 01 Dec 2024 00:00:00 GMT

数组离散化树状数组前缀和

思路#

要求统计满足 i<j<ki < j < ki<j<k 且 ai<aj<aka_i < a_j < a_kai<aj<ak 的上升三元组数量。把每个位置 jjj 当作三元组的中间元素，问题拆成两步：

第一层（树状数组 f1）：从左往右扫描，f1.add(idx, 1) 记录值 idx 出现次数。对当前值 idx，f1.query(idx - 1) 就是它左边比它小的数的个数，记作 smalljsmall_jsmallj。
第二层（树状数组 f2）：f2.add(idx, small_j)，即在位置 idx 上累加「以某个值结尾、且比它小的左边元素数」。这样 f2.query(idx - 1) 累计的就是所有「两两上升对」中，右端值比 idx 小的对数。

扫到 i 时执行 ans += f2.query(idx - 1)，即以 aia_iai 作为第三个元素，能接上的上升对数量。三层递推：单个数 → 上升对 → 上升三元组。

值域可能很大（long long），所以先对数组离散化（排序副本 + lower_bound 映射），再把离散化后的排名当作树状数组下标。

复杂度 O(nlog⁡n)O(n \log n)O(nlogn)，空间 O(n)O(n)O(n)。

1
#include <bits/stdc++.h>
2
using namespace std;
3

4
const int MAXN = 3e4+10;
5
typedef long long ll;
6

7
class MyTree {
8
public:
9
    vector<int> v;
10
    int sz;
11
    MyTree(int sz) {
12
        this->sz = sz;
13
        v.resize(sz + 1);
14
    }
15

16
    int lowbit(int x) {
17
        return x & (-x);
18
    }
19

20
    void add(int x, int value) {
21
        while (x <= sz) {
22
            v[x] += value;
23
            x += lowbit(x);
24
        }
25
    }
26

27
    int query(int x) {
28
        int sum = 0;
29
        while (x > 0) {
30
            sum += v[x];
31
            x -= lowbit(x);
32
        }
33
        return sum;
34
    }
35
};
36

37
MyTree f1(MAXN), f2(MAXN);
38

39
void solve() {
40
    int n;
41
    cin >> n;
42

43
    vector<ll> arr(n + 1);
44
    vector<ll> sorted_arr(n + 1);
45

46
    for (int i = 1; i <= n; i++) {
47
        cin >> arr[i];
48
        sorted_arr[i] = arr[i];  // 复制数组用于排序
49
    }
50

51
    sort(next(begin(sorted_arr)), end(sorted_arr)); // 仅排序副本
52
    auto f = [&](ll x) {
53
        return lower_bound(next(begin(sorted_arr)), end(sorted_arr), x) - sorted_arr.begin();
54
    };
55

56
    ll ans = 0;
57
    for (int i = 1; i <= n; i++) {
58
        int idx = f(arr[i]);
59
        f1.add(idx, 1);
60
        f2.add(idx, f1.query(idx - 1));  // 确保索引合法
61
        ans += f2.query(idx - 1);
62
    }
63
    cout << ans << endl;
64
}
65

66
int main() {
67
    ios_base::sync_with_stdio(false);
68
    cin.tie(NULL);
69
    cout.tie(NULL);
70

71
    solve();
72
    return 0;
73
}

展开收起

带权路径长度（WPL）

Sun, 10 Nov 2024 00:00:00 GMT

在讨论树结构，特别是在哈夫曼树等数据压缩和编码算法中，一个关键的概念是“带权路径长度”（Weighted Path Length，WPL）。这个概念对于理解树的效率和优化有重要作用。

带权路径长度（WPL）#

带权路径长度是树中 所有叶节点 的路径长度与其权值的乘积之和。具体来说：

路径长度：从树的根节点到任一节点的边的数量（或者说从该节点到根节点的边的数量）。
权值：分配给树中每个节点的数值，通常反映了某种度量（如在哈夫曼树中，一个字符的频率）。

对于哈夫曼树，WPL 最小化是其设计的关键目的，意味着常见的数据（高权值）具有较短的路径长度，从而实现整体存储和传输的效率。

WPL 的计算#

假设一个树结构中，每个叶节点 nin_ini 有一个权值 wiw_iwi 和一个从根到该节点的路径长度 lil_ili，WPL 计算公式为：

WPL=∑i=1kwi×li\text{WPL} = \sum_{i=1}^{k} w_i \times l_iWPL=∑i=1kwi×li

其中 kkk 是叶节点的数量。

示例#

考虑一个简单的哈夫曼树：

在这个例子中，数字代表权值，星号 (*) 表示内部节点（其权值是子节点权值的和）：

权值为 5 的节点路径长度为 1。
权值为 2 的节点路径长度为 2。
权值为 3 的节点路径长度为 2。

计算 WPL:

WPL=(5×1)+(2×2)+(3×2)=5+4+6=15WPL = (5 \times 1) + (2 \times 2) + (3 \times 2) = 5 + 4 + 6 = 15WPL=(5×1)+(2×2)+(3×2)=5+4+6=15

MEX：最小非负整数

Sun, 20 Oct 2024 00:00:00 GMT

MEX 即一个数组中的最小非负整数，它满足下面三个性质：

只有在添加的数等于当前序列的mex时，mex的值才会变化。添加操作只会使得mex变大删除操作会使得mex的值变小。

Problem - C - Codeforces

对于一个随时插入，删除元素的数组，想高效的查询mex可使用 set 和一个计数数组

用一个set<int> st 来记录没有出现过的数，然后直接取最小值就可以了，当然需要一个cnt来计数。

最小值用begin取得

1
struct Mex {
2
    static const int N = 1e5 + 5;
3
    int cnt[N] = {};
4
    set<int> s;
5
    Mex() { for (int i = 0; i < N; ++i) s.insert(i); }
6

7
    void add(int x) {
8
        if (!cnt[x]) s.erase(x);
9
        ++cnt[x];
10
    }
11

12
    void del(int x) {
13
        if (cnt[x] == 1) s.insert(x);
14
        if (cnt[x]) --cnt[x];
15
    }
16

17
    int get() { return *s.begin(); }
18
};

展开收起

C++ priority_queue 优先队列

Sun, 06 Oct 2024 00:00:00 GMT

C++中的优先队列（priority queue）是一种用于维护一组元素构成的集合的容器适配器，其中每个元素都有一个优先级。添加到优先队列中的元素将按照其优先级排序，优先级最高的元素将首先被移除。优先队列通常使用堆（heap）数据结构来实现，以支持高效的元素插入和移除操作。

在C++标准库中，优先队列通过priority_queue模板类提供，该模板类定义在头文件<queue>中。

基本用法#

以下是priority_queue的基本用法示例：

1
#include <iostream>
2
#include <queue>
3

4
int main() {
5
    // 创建一个int类型的优先队列，默认使用std::less<int>，
6
    // 即最大值优先
7
    std::priority_queue<int> pq;
8

9
    // 向优先队列中插入元素
10
    pq.push(30);
11
    pq.push(10);
12
    pq.push(20);
13
    pq.push(5);
14

15
    // 遍历优先队列（这不是最好的方法，因为会改变队列内容）
16
    while (!pq.empty()) {
17
        // 访问队头元素
18
        std::cout << pq.top() << " ";
19
        // 移除队头元素
20
        pq.pop();
21
    }
22
    std::cout << std::endl;
23

24
    return 0;
25
}

展开收起

输出结果将是：

1
30 20 10 5

自定义优先级#

你可以通过定义自己的比较函数或者重载operator<来实现自定义类型的优先级排序。比如，使用结构体并自定义优先级规则：

1
#include <iostream>
2
#include <queue>
3
#include <vector>
4

5
struct MyStruct {
6
    int value;
7
    // 自定义比较函数
8
    bool operator<(const MyStruct& other) const {
9
        // 这里定义的是最小值优先
10
        return value > other.value;
11
    }
12
};
13

14
int main() {
15
    std::priority_queue<MyStruct> pq;
16

17
    // 向优先队列中插入元素
18
    pq.push({10});
19
    pq.push({30});
20
    pq.push({20});
21
    pq.push({5});
22

23
    // 遍历优先队列
24
    while (!pq.empty()) {
25
        std::cout << pq.top().value << " ";
26
        pq.pop();
27
    }
28
    std::cout << std::endl;
29

30
    return 0;
31
}

展开收起

输出结果将是：

1
5 10 20 30

在这个例子中，自定义的比较运算符让我们能够实现最小值优先的排序逻辑。注意，当使用自定义类型时，必须确保提供用于比较元素的机制，要么通过重载operator<，要么通过提供自定义的比较函数对象。

字典树

Sun, 22 Sep 2024 00:00:00 GMT

数据结构

特点：字典树支持高效的前缀查找。其次，通过共享前缀来节省空间，多个以相同前缀开头的字符串只需存储一份前缀。再次，字典树的节点不直接存储完整的字符串，而是通过从根节点到该节点的路径构成字符串最后，字典树支持插入、查找、删除和前缀匹配等多种操作 插入和查找操作的时间复杂度均为 O(m)，其中 m 是字符串的长度

结构定义：字典树通常由两个主要结构组成。首先是TrieNode（节点），每个节点包含一个子节点的映射（通常使用哈希表或数组）和一个布尔值 end，指示该节点是否为某个字符串的结尾。其次是Trie（字典树），它包含一个指向根节点的指针，所有字符串的插入和查找操作都从根节点开始

1
struct trie {
2
  int nex[100000][26], cnt;
3
  bool exist[100000];  // 该结点结尾的字符串是否存在
4

5
  void insert(char *s, int l) {  // 插入字符串
6
    int p = 0;
7
    for (int i = 0; i < l; i++) {
8
      int c = s[i] - 'a';
9
      if (!nex[p][c]) nex[p][c] = ++cnt;  // 如果没有，就添加结点
10
      p = nex[p][c];
11
    }
12
    exist[p] = true;
13
  }
14

15
  bool find(char *s, int l) {  // 查找字符串
16
    int p = 0;
17
    for (int i = 0; i < l; i++) {
18
      int c = s[i] - 'a';
19
      if (!nex[p][c]) return 0;
20
      p = nex[p][c];
21
    }
22
    return exist[p];
23
  }
24
};

展开收起

维护异或极值#

XOR 异或将数的二进制表示看做一个字符串，就可以建出字符集为 {0,1}\{0,1\}{0,1} 的 trie 树。

Problem - 706D - Codeforces

我们考虑在一个01字典树（每个节点是0或1）里插入所有数的二进制表示。比如要插入一个32位整数，就从高位到低位一位一位插。

插入过程：

从最高位（比如31位）往最低位0位走。
每一位如果是0，就走/建0儿子，否则走/建1儿子。

查询最大异或值的过程： 假设现在要查一个数x，想找集合中一个数，使得异或值最大。异或要大，意味着尽量在每一位上异或出1。怎么做？

从高位到低位一位一位走。
每一位，优先找跟x当前位不同的方向（因为1异或0 = 1，能让结果高位出现1）。
如果能走，就走异位；不能走，就只能走同位。
边走边计算异或值。

查询最小异或值的过程（比如如果需要）：

每一位，优先走跟x当前位相同的方向（因为0异或0=0，1异或1=0，结果小）。
走不了再走异位。

XOR 异或的性质与可差分性

Sun, 08 Sep 2024 00:00:00 GMT

位运算

XOR 满足交换律和结合律

结论1: 如果奇数位和偶数位的 XOR 结果相等，则整个数组的 XOR 结果为 0
结论2: a xor b = 0 当且仅当 a == b
结论3: a xor 0 = 0

Problem - 1872E - Codeforces 巧妙异或前缀和

Problem - 1516B - Codeforces 此题中由于异或运算满足交换律，所以相邻谁先异或谁是没有关系的，然后就可以把问题转化成求分界点，两边的异或和相等 (或者三块相等)。然后就暴力枚举两个分界点L，R

枚举 “隔板点”

一个数组中的异或和是可差分的信息

1
void solve() {
2
    int n;
3
    cin >> n;
4
    vector<ll> v(n), pa(n);
5
    for (int i = 0; i < n; i++) {
6
        cin >> v[i];
7
    }
8

9
    pa[0] = v[0];
10
    for (int i = 1; i < n; i++) {
11
        pa[i] = pa[i - 1] ^ v[i];
12
    }
13

14
    if (pa[n - 1] == 0) {
15
        YES;
16
        return;
17
    }
18

19
    for (int i = 0; i < n - 1; i++) {
20
        for (int j = i + 1; j < n - 1; j++) {
21
            ll a = pa[i];
22
            ll b = pa[j] ^ pa[i];
23
            ll c = pa[n - 1] ^ pa[j];
24
            if (a == b && b == c) {
25
                YES;
26
                return;
27
            }
28
        }
29
    }
30

31
    NO;
32
}

展开收起

并查集

Sun, 25 Aug 2024 00:00:00 GMT

并查集是一种用于管理元素所属集合的数据结构，实现为一个森林，其中每棵树表示一个集合，树中的节点表示对应集合中的元素。

顾名思义，并查集支持两种操作：

合并（Union）：合并两个元素所属集合（合并对应的树）
查询（Find）：查询某个元素所属集合（查询对应的树的根节点），这可以用于判断两个元素是否属于同一集合

并查集在经过修改后可以支持单个元素的删除、移动；使用动态开点线段树还可以实现可持久化并查集。

Pasted image 20240310165444.png

1
struct dsu {
2
    std::vector<int> pa;
3

4
    explicit dsu(int size) : pa(size) {
5
        std::iota(pa.begin(), pa.end(), 0);
6
    }
7

8
    int find(int x) {
9
        return pa[x] == x ? x : (pa[x] = find(pa[x]));
10
    }
11

12
    void unite(int x, int y) {
13
        pa[find(x)] = find(y);
14
    }
15
};

展开收起

数组离散化

Mon, 12 Aug 2024 00:00:00 GMT

当你需要比较元素的大小，或者节省空间的情况:

1
// 离散化
2
sort(begin(v_sorted), end(v_sorted));
3
v_sorted.erase(unique(begin(v_sorted), end(v_sorted)), end(v_sorted));
4

5
// 映射离散化索引（1-based index）
6
for (int i = 0; i < (int)v_sorted.size(); i++) {
7
  index_map[v_sorted[i]] = i + 1;
8
}

1
vector<ll> arr(n + 1);
2
vector<ll> sorted_arr(n + 1);
3

4
for (int i = 1; i <= n; i++) {
5
  cin >> arr[i];
6
  sorted_arr[i] = arr[i];  // 复制数组用于排序
7
}
8

9
sort(next(begin(sorted_arr)), end(sorted_arr)); // 仅排序副本
10
auto f = [&](ll x) {
11
  return lower_bound(next(begin(sorted_arr)), end(sorted_arr), x) - sorted_arr.begin();
12
};

1
#define all(x) x.begin(), x.end()
2
#define unq_all(x) x.erase(unique(all(x)), x.end())
3
#define sort_all(x) sort(all(x))
4

5
vector<ll> g = v;
6
sort_all(v);
7
unq_all(v);
8
auto get_id = [&](ll x) {
9
  return lower_bound(g.begin(), g.end(), x) - g.begin() + 1; // 下标从1开始
10
};

Vue 组件属性 Props

Mon, 15 Apr 2024 00:00:00 GMT

在 Vue 组件中，属性（Props）用于在父组件和子组件之间传递数据。以下是 Vue 组件属性的关键概念：

1. 基础使用#

子组件模板（单文件组件的 <template> 块）：

1
<template>
2
  <div>
3
    <p>Message: {{ message }}</p>
4
  </div>
5
</template>

对应的脚本（Options API）：

1
export default {
2
  props: ["message"], // 简单定义 props
3
};

父组件使用：

1
<ChildComponent message="Hello Vue!"/>

2. 类型验证#

Vue 允许为 props 指定数据类型：

1
props: {
2
  message: String,
3
  count: Number,
4
  isActive: Boolean,
5
  items: Array,
6
  user: Object,
7
  callback: Function
8
}

3. 默认值#

如果父组件未传递 prop，可以提供默认值：

1
props: {
2
  count: {
3
    type: Number,
4
    default: 0
5
  }
6
}

4. 必填#

如果某个 prop 必须提供：

1
props: {
2
  title: {
3
    type: String,
4
    required: true
5
  }
6
}

5. 自定义验证#

1
props: {
2
  rating: {
3
    type: Number,
4
    validator: value => value >= 0 && value <= 5
5
  }
6
}

6. 动态绑定#

1
<ChildComponent :message="parentMessage" :count="42"/>

:message 表示 message 由父组件的数据 parentMessage 绑定，而不是字符串。

7. 非 Prop Attribute#

如果子组件没有声明某个 prop，Vue 会把它当作普通 HTML 特性传递：

1
<ChildComponent class="custom-style"/>

如果 ChildComponent 没有 props: ["class"]，这个 class 会应用到子组件的根元素。

8. 单向数据流#

Prop 只能在子组件内部读取，不能修改。如果要修改，推荐使用：

局部数据拷贝：

1
props: ["count"],
2
data() {
3
  return { localCount: this.count };
4
}

$emit 事件通知父组件：

1
<button @click="$emit('update-count', count + 1)">Increase</button>

9. 使用 `defineProps`（Vue 3 Composition API）#

单文件组件 <script setup> 块中：

1
defineProps({
2
  message: String,
3
  count: Number
4
});

Vue 组件的属性机制可以帮助父子组件高效通信，同时保持组件的封装性和可复用性。

Vue 生命周期钩子

Tue, 02 Apr 2024 00:00:00 GMT

（1）创建阶段#

组件实例被初始化，但 DOM 还未渲染，可以在这阶段进行数据初始化、调用 API 获取数据等操作。

钩子	说明
`beforeCreate()`	数据和事件都未初始化，只能访问 `methods` 但无法访问 `data`、`computed`。
`created()`	实例创建完成，data 已初始化，可以进行异步请求，但 DOM 还未渲染。

（2）挂载阶段#

组件被挂载到 DOM，此时可以进行 DOM 操作 或者 获取 DOM 元素。

钩子	说明
`beforeMount()`	模板已编译，但虚拟 DOM 还未挂载到真实 DOM，可以操作 `data`，但不能操作 `DOM`。
`mounted()`	组件已挂载到真实 DOM，可操作 DOM、进行 AJAX 请求。

（3）更新阶段#

当 data 发生变化时，Vue 组件会重新渲染。

钩子	说明
`beforeUpdate()`	组件更新前触发，数据已经改变但 DOM 还未更新。
`updated()`	组件更新后触发，DOM 已更新，可以执行依赖更新 DOM 的操作。

Vue v-model 双向数据绑定

Mon, 18 Mar 2024 00:00:00 GMT

`v-model` 在 Vue 中的作用#

v-model 是 Vue 提供的双向数据绑定指令，用于在表单控件（如 input、textarea、select）和组件之间同步数据。

特点：

绑定的数据会随着用户输入自动更新。
适用于 input、textarea、select 等表单控件。
Vue 3 中可以自定义 v-model 绑定的属性。

本质是语法糖#

在原生表单元素上，v-model 约等于「value 绑定 + input 事件回写」：

1
<input v-model="text" />
2

3
<!-- 等价于 -->
4
<input :value="text" @input="text = $event.target.value" />

修饰符#

1
<!-- lazy：改为 change 事件触发（失焦才同步） -->
2
<input v-model.lazy="text" />
3

4
<!-- trim：自动去掉首尾空格 -->
5
<input v-model.trim="text" />
6

7
<!-- number：把输入转为数字 -->
8
<input v-model.number="age" type="number" />

在组件上使用（Vue 3）#

组件上的 v-model 默认展开为 modelValue prop 和 update:modelValue 事件：

1
<!-- 父组件 -->
2
<MyInput v-model="keyword" />
3

4
<!-- 等价于 -->
5
<MyInput :model-value="keyword" @update:model-value="keyword = $event" />

1
// 子组件 MyInput
2
const props = defineProps(["modelValue"]);
3
const emit = defineEmits(["update:modelValue"]);

Vue 3 还支持多个双向绑定，通过参数区分：

1
<MyForm v-model:title="bookTitle" v-model:author="bookAuthor" />

自定义组件也可以声明 v-model 的 arg、事件名与修饰符（defineModel() 更简洁）。

Vue v-bind 动态属性绑定

Tue, 05 Mar 2024 00:00:00 GMT

v-bind 是 Vue.js 中用于动态绑定 HTML attribute（属性）的指令。它允许你在模板中将 JavaScript 表达式的值绑定到 HTML 元素的属性上，使页面能够根据数据的变化自动更新。

基本语法#

1
<!-- 完整写法 -->
2
<a v-bind:href="url">链接</a>
3

4
<!-- 缩写：冒号 -->
5
<a :href="url">链接</a>

绑定的值可以是任意 JavaScript 表达式：

1
<img :src="baseUrl + '/logo.png'" :alt="title" :width="size * 2" />

绑定 class 与 style#

这是 v-bind 最常用的场景之一，支持对象语法和数组语法：

1
<!-- 对象语法：条件为真时应用该 class -->
2
<div :class="{ active: isActive, 'text-red': hasError }"></div>
3

4
<!-- 数组语法 -->
5
<div :class="[baseClass, isActive ? 'active' : '']"></div>
6

7
<!-- style 对象语法 -->
8
<div :style="{ color: textColor, fontSize: fontSize + 'px' }"></div>

动态 attribute 名#

Vue 3 支持用方括号把 attribute 名也变成表达式：

1
<a :[attributeName]="url">这里的 attributeName 可以是动态的</a>

与组件 props 的关系#

在组件上使用 :prop-name="value" 时，v-bind 就是把父组件的数据传给子组件的 prop。配合 v-bind="obj" 还可以一次性把整个对象展开为多个 props：

1
<UserCard v-bind="userFields" />

一句话总结：插值表达式负责把值写进文本，v-bind 负责把值写进 attribute。

Blume's Skylog

Grafana 可视化与监控

Grafana 能做什么？#

1. 数据可视化#

2. 系统监控#

3. 告警通知#

Grafana 的数据来源#

Grafana + Prometheus 是最经典组合#

一个典型场景#

为什么 Grafana 这么流行？#

一句话理解#

微服务之间如何传递 trace

HTTP 场景#

gRPC 与消息队列#

实务建议#

kubectl port-forward 端口转发

k8s 端口转发#

转发 Pod#

转发 Service#

让局域网其他机器也能访问#

常用排查命令#

注意事项#

kubectl 常用命令速查

kubectl 常用命令#

查看当前集群#

查看资源#

查看详情#

看日志#

进入容器#

本地访问服务#

部署和删除#

重启和发布状态#

看事件#

k8s Service：给一组 Pod 稳定入口

k8s Service#

它解决什么问题#

最小示例#

Service 类型#

实际项目例子#

常用命令#

Kubernetes 集群架构总览

控制平面组件 #

kube-apiserver#

etcd#

kube-scheduler#

kube-controller-manager#

cloud-controller-manager#

节点组件 #

kubelet#

kube-proxy（可选） #

容器运行时 #

插件（Addons） #

DNS#

Web 界面（仪表盘） #

容器资源监控 #

集群层面日志 #

网络插件 #

一致性哈希：consistent 与 rendezvous 的对比

对比结论#

怎么选#

微服务鉴权与网关职责

微服务鉴权与网关职责#

核心结论#

Gateway 应该做什么#

Service 必须做什么#

反例#

gRPC 透传身份（Go）#

更成熟的内部安全#

文件服务场景落地#

快速检查清单#

Minikube 本地集群

Minikube#

启动和停止#

确认 kubectl 连到 minikube#

使用 minikube 内部 Docker#

退出 minikube Docker 环境#

常用调试命令#

本地练习#

Docker 镜像构建上下文

一个具体例子#

kube-apiserver #

etcd #

kube-scheduler #

kube-controller-manager #

cloud-controller-manager #

kubelet #

DNS #

`target_include_directories()`#

1. `PRIVATE`#

2. `INTERFACE`#

3. `PUBLIC`#