Posts

AI Agent 开发的本质 开发 AI Agent 的核心是将已验证的知识和流程固化成可执行的规则和指令。 具体来说： 知识固化 - 把专家经验、最佳实践、业务规则编码成 Agent 可以遵循的指令 流程自动化 - 将重复性的决策流程转化为确定性的执行步骤 质量保障 - 通过固化的规则确保每次执行的一致性，避免人为疏忽 迭代优化 - 每次发现新问题或更好的做法，就更新这些"固化的知识"，Agent 的能力随之提升 本质上是把隐性知识显性化，把经验驱动变成规则驱动。 这也意味着 Agent 的质量上限取决于你固化进去的知识质量。垃圾进，垃圾出；好的经验进，稳定的高质量输出。 为什么需要固化知识 LLM 的知识覆盖面极广，解决同一个问题可能有多条路径，但其中只有少部分是最佳实践。具体输出什么内容，很大程度上取决于提示词的质量。 把已验证的解决方案固化到 Agent 里，能让 Agent 在特定领域有更稳定、更优质的表现——相当于给 LLM 划定了一条"黄金路径"，避免它在众多可能性中随机游走。 常用技术栈 编程语言 Python（主流，生态丰富） JavaScript/TypeScript（Web/Node.js Agent） Go、Java（高性能/企业级） 大语言模型与 API OpenAI GPT-4/3.5、Claude、Llama Hugging Face Transformers LangChain、LlamaIndex（Agent 框架） Web 框架与服务 FastAPI、Flask（Python） Express.js（Node.js） Django 数据存储 Redis、MongoDB、PostgreSQL、SQLite 向量数据库：Milvus、Pinecone、Weaviate 消息队列与异步任务 Celery、RabbitMQ、Kafka 容器与部署 Docker、Kubernetes 云服务：AWS、Azure、GCP 前端交互 React、Vue.js WebSocket、RESTful API 其他 Prompt 工程、工具插件系统 OAuth2、JWT（安全认证） 日志与监控：Prometheus、Grafana Python 调用模型方式 AI Agent 用 Python 开发时，可以调用本地模型或云端模型： ...

IO, 输入输出 https://my.oschina.net/u/1859679/blog/1839169 同步阻塞 IO 同步非阻塞 IO 异步非阻塞 IO 针对某种 IO 模型,我们如何分类,可以基于 POSIX 对同步/异步的定义来判别: A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes; （同步 I/O 操作会导致发起请求的进程被阻塞，直到该 I/O 操作完成。） An asynchronous I/O operation does not cause the requesting process to be blocked; （异步 I/O 操作不会导致发起请求的进程被阻塞。） 那么从上我们可以看出: 同步: 是否同步体现在消息通信机制上。 阻塞: 是否阻塞主要体现在调用的线程是否可以干别的,关注的是程序的等待状态 也就是说同步和异步说的是消息的通知机制,阻塞非阻塞说的是线程的状态 。 Unix 5种I/O模型 在《UNIX网络编程: 卷一》的第六章书中列出了五种IO模型: 阻塞式I/O； 非阻塞式I/O； I/O复用 (select,poll,epoll…) ； 信号驱动式I/O (SIGIO) ； 异步I/O (POSIX的 aio 系列函数)

linux apps kitty, terminal Go go install github.com/jesseduffield/lazygit@latest Ubuntu apt package gnome-shell-pomodoro: Pomodoro, https://gnomepomodoro.org/ pavucontrol, chrome audio output, https://askubuntu.com/questions/457978/no-sound-from-chrome-sound-works-fine-in-firefox-etc-13-10 baobab, 硬盘占用分析工具 indicator-sysmonitor, 任务栏里的系统资源监控 thunderbird, 邮件客户端, email client flameshot, 截图工具 pacman ncdu, 磁盘空间占用分析/清理 bitwarden, password management binutils: A set of programs to assemble and manipulate binary and object files btop, 另外一个 top 实现, 颜值还不错 fastfetch, 打印发行版的 logo mousepad, 易于使用的快速的文本编辑器 obsidian, 知识管理 code, visual studio code, vscode chromium, 开源版 chrome base-devel stress, 压力测试 nvm, nvm allows you to quickly install and use different versions of node via the command line. AUR google-chrome redisinsight: redis GUI jetbrains-toolbox pamac-aur, 图形界面的 pacman podlet visual-studio-code-bin claude-code gitkraken, git GUI client, Free for non-commercial use application list https://wiki.archlinux.org/index.php/List_of_applications ...

硬盘扩容 pve ext4 根分区磁盘扩容 虚拟机关机 在 pve 里给硬盘扩容: vm>hardware> Hard Disk> Disk Action> resize: 填写新增的容量 挂载 archlinux iso, 修改引导顺序, 让虚拟机从 iso 启动 启动虚拟机 # 列出所有块设备（磁盘及分区）的信息，以树状结构显示设备名、大小、挂载点等 lsblk # 看到磁盘总大小增加了，但分区大小没变。 fdisk -l # 调整分区表, 扩容, 用 fdisk 调整分区表一般不会丢数据，但是最好备份一下。 fdisk /dev/sda # 如果不是从 iso 引导,直接在操作系统里执行, 会提示 This disk is currently in use - repartitioning is probably a bad idea. It's recommended to umount all file systems, nd swapoff all swap partitions on this disk. # print the partition table Command (m for help): p Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors Disk model: QEMU HARDDISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x1bc64ef0 Device Boot Start End Sectors Size Id Type /dev/sda1 * 6144 2103295 2097152 1G b W95 FAT32 /dev/sda2 2103296 20971519 18868224 9G 83 Linux # delete partition 2 Command (m for help): d Partition number (1,2, default 2): 2 Partition 2 has been deleted. Command (m for help): n Partition type p primary (1 primary, 0 extended, 3 free) e extended (container for logical partitions) # 输入 p Select (default p): p # 使用默认值 2 Partition number (2-4, default 2): # 输入分区的起始扇区, 要和删除的分区起始扇区一样, 注意!默认值会是2048, 不要使用这个默认值, 要输入前面打印分区表时看到的分区 2 的起始扇区值, 否则会丢数据, 这里是2103296 First sector (2048-41943039, default 2048): 2103296 # 输入分区的结束扇区, 使用默认值, 即使用所有剩余空间 Last sector, +/-sectors or +/-size{K,M,G,T,P} (2103296-41943039, default 41943039): Created a new partition 2 of type 'Linux' and of size 19 GiB. Partition #2 contains a ext4 signature. # 输入 y 确认删除 ext4 签名 Do you want to remove the signature? [Y]es/[N]o: Y The signature will be removed by a write command. # 再次打印分区表， 应该能看到分区 2 已经变大了 Command (m for help): p Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors Disk model: QEMU HARDDISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x1bc64ef0 Device Boot Start End Sectors Size Id Type /dev/sda1 * 6144 2103295 2097152 1G b W95 FAT32 /dev/sda2 2103296 41943039 39839744 19G 83 Linux Filesystem/RAID signature on partition 2 will be wiped. # 输入命令 w 保存分区表 Command (m for help): w The partition table has been altered. Syncing disks. # 强制检查 ext2/ext3/ext4 文件系统的一致性，-f 表示即使文件系统标记为干净也强制执行检查 e2fsck -f /dev/sda2 # 有可能会询问是否优化，输入 y， 后面可能会有很多类似的提示，全部输入 y 即可， 还有可能提示输入 a: 确认全部 root@archiso ~ # e2fsck -f /dev/sda2 e2fsck 1.47.3 (8-Jul-2025) ext2fs_open2: Bad magic number in super-block e2fsck: Superblock invalid, trying backup blocks... Pass 1: Checking inodes, blocks, and sizes Inode 287507 extent tree (at level 1) could be narrower. Optimize<y>? # resize the filesystem # resize2fs 要求文件系统在扩容前必须是干净状态（通过 e2fsck 校验），否则拒绝执行 resize2fs /dev/sda2 # 分区扩容完成，重启虚拟机 PVE ext4 disk resize Online Lossless Expansion of EXT4 Partition ...

Tekton 什么是 Tekton Tekton（发音：/ˈtɛktɒn/，“TEK-ton”）名称来自希腊语 τέκτων，意为"建造者"。 Tekton 是一个开源的云原生 CI/CD 框架，运行在 Kubernetes 上，通过 CRD（自定义资源定义）的方式定义流水线。它是强制 Kubernetes 原生的，所有流水线组件都以 Pod 方式运行，没有其他执行模式。 与 Jenkins、GitLab CI 等工具不同，Tekton 从设计之初就只能运行在 Kubernetes 上，而不是"可选支持 K8s"。这是架构层面的硬性约束，带来的好处是与 K8s 生态深度集成，代价是强依赖 K8s 环境。 Tekton 是 CD Foundation 旗下项目，前身是 Knative 的 Build 模块。 核心概念 Step（步骤） 流水线中的最小执行单元，对应容器中的一条命令。 Task（任务） 由一组有序的 Step 组成，运行在同一个 Pod 中，Steps 共享存储卷。 apiVersion: tekton.dev/v1 kind: Task metadata: name: build-and-push spec: params: - name: image type: string steps: - name: build image: gcr.io/kaniko-project/executor:latest args: - "--dockerfile=$(workspaces.source.path)/Dockerfile" - "--context=$(workspaces.source.path)" - "--destination=$(params.image)" workspaces: - name: source Pipeline（流水线） 由多个 Task 按顺序或并行组成，定义完整的 CI/CD 工作流。 ...

pnpm - 高效的 Node.js 包管理器 pnpm 简介 pnpm (performant npm) 是一个快速、节省磁盘空间的 JavaScript 包管理器，作为 npm 和 yarn 的替代方案。它通过创建硬链接和符号链接的方式来共享依赖，避免重复安装相同的包。 核心特点 节省磁盘空间 所有版本的依赖都存储在硬盘上的单一位置（全局存储目录） 当安装包时，文件会从全局存储硬链接到项目的 node_modules 如果你有 100 个项目使用相同版本的某个依赖，磁盘上只会有这个依赖的一份文件 极快的安装速度 由于使用硬链接，安装过程比 npm 和 yarn 都快 多个项目共享依赖时，速度优势更加明显 严格的依赖解析算法避免了冗余操作 创建非扁平化的 node_modules 使用符号链接创建依赖的嵌套结构 只有 package.json 中声明的依赖才能访问 避免了"幽灵依赖"（phantom dependencies）问题 严格的依赖管理 防止访问未声明的依赖 确保项目的可重现性和安全性 pnpm 工作原理 全局存储 (~/.pnpm-store/) ├── package-a@1.0.0 ├── package-b@2.0.0 └── package-c@3.0.0 ↓ (硬链接) 项目 node_modules/ └── .pnpm/ └── package-a@1.0.0/ └── node_modules/ └── package-a (实际内容) ↓ (符号链接) └── package-a → .pnpm/package-a@1.0.0/node_modules/package-a 与 npm/yarn 的对比 特性 pnpm npm yarn 磁盘空间效率 ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐ 安装速度 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ 依赖隔离 ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐ Monorepo 支持 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ 严格性 ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ pnpm 安装 全局安装 pnpm # 使用 npm 安装 npm install -g pnpm # 使用 Homebrew (macOS/Linux) brew install pnpm # 使用独立脚本安装 curl -fsSL https://get.pnpm.io/install.sh | sh - # Windows (PowerShell) iwr https://get.pnpm.io/install.ps1 -useb | iex 查看版本 pnpm --version pnpm -v pnpm 基本命令 安装依赖 # 安装 package.json 中的所有依赖 pnpm install pnpm i # 安装指定包 pnpm add <package> pnpm add lodash # 安装指定版本 pnpm add lodash@4.17.21 # 安装到 devDependencies pnpm add -D <package> pnpm add --save-dev jest # 全局安装 pnpm add -g <package> pnpm add -g typescript # 安装指定 workspace 包 pnpm add <package> --filter <workspace> 更新依赖 # 更新所有依赖 pnpm update pnpm up # 更新指定包 pnpm update lodash pnpm up lodash # 更新到最新版本（忽略 package.json 中的版本范围） pnpm update --latest pnpm up -L # 交互式更新 pnpm update -i 删除依赖 # 删除指定包 pnpm remove <package> pnpm rm lodash # 删除全局包 pnpm remove -g <package> 查看依赖 # 列出所有依赖 pnpm list pnpm ls # 列出指定包的依赖树 pnpm list <package> # 查看过期的包 pnpm outdated # 查看包信息 pnpm view lodash pnpm info lodash 运行脚本 # 运行 package.json 中定义的脚本 pnpm run <script> pnpm run build pnpm run test # 简写（对于常用命令） pnpm start pnpm test pnpm t 清理缓存 # 清理未被引用的包 pnpm store prune # 查看 store 状态 pnpm store status # 查看 store 路径 pnpm store path 安全审计 # 检查依赖包的安全漏洞（对应 npm audit） pnpm audit # 自动修复漏洞（对应 npm audit fix） pnpm audit --fix # 仅生产环境依赖审计 pnpm audit --prod # 输出 JSON 格式 pnpm audit --json # 审计并显示详细信息 pnpm audit --audit-level=<severity> # severity 可选值: low, moderate, high, critical pnpm audit 与 npm audit 的差异： ...

异常捕捉的确是对性能有影响的,那是因为一旦异常被抛出,函数也就跟着 return 了。而程序在执行时需要处理 函数栈 的上下文,这会导致性能变得很慢,尤其是线程栈比较深的时候。但从另一方面来说,异常的抛出基本上表明程序的错误。程序在绝大多数情况下,应该是在没有异常的情况下运行的, 所以,有异常的情况应该是少数的情况,不会影响正常处理的性能问题。 对于我们并不期望会发生的事,我们可以使用异常捕捉；对于我们觉得可能会发生的事,使用返回码。 https://time.geekbang.org/column/article/675 你觉得自己是一个Java专家吗？是否肯定自己 已经全面掌握了Java的异常处理机制？在下面这段代码中,你能够迅速找出异常处理的六个问题吗？ 1 OutputStreamWriter out = … 2 java.sql.Connection conn = … 3 try { // ⑸ 4 Statement stat = conn.createStatement(); 5 ResultSet rs = stat.executeQuery( 6 “select uid, name from user”); 7 while (rs.next()) 8 { 9 out.println(“ID: " + rs.getString(“uid”) // ⑹ 10 “,姓名: " + rs.getString(“name”)); 11 } 12 conn.close(); // ⑶ 13 out.close(); 14 } 15 catch(Exception ex) // ⑵ 16 { 17 ex.printStackTrace(); //⑴,⑷ ...

两种处理错误/边界条件的编程风格，在 Python 社区尤为常见。 LBYL — Look Before You Leap（先检查再操作） 谚语来源： “Look Before You Leap” 字面意思是"跳跃之前，先看清脚下"。想象要跳过一条沟——不先看清落脚点就跳，可能会摔进坑里。引申为行动之前先确认条件是否安全，对应中文谚语"三思而后行"、“谋定而后动”。 在编程里，“leap”（跳跃）= 执行操作，“look”（看）= if 条件检查。 操作前先检查前提条件是否满足。 # LBYL 风格 if key in my_dict: value = my_dict[key] else: value = default if os.path.exists(filepath): with open(filepath) as f: data = f.read() 特点： 逻辑清晰，防御性强 存在 TOCTOU（Time-Of-Check-Time-Of-Use）竞态条件风险——检查和使用之间状态可能改变 代码中充满 if 判断，容易冗长 EAFP — Easier to Ask Forgiveness than Permission（先操作再处理异常） 短语来源： 这句话来自生活场景的比喻——想做某事时，与其事先去请示许可（可能被拒绝、很麻烦），不如直接去做，事后出了问题再道歉求谅解，因为道歉往往比请示更容易。 英文 字面意思 编程含义 Ask Permission 事先请求许可 用 if 检查条件是否满足 Ask Forgiveness 事后请求原谅 用 except 处理出错的异常 这个说法由 Python 之父 Guido van Rossum 推广，体现了 Python 的哲学：代码应该表达意图，而不是充满防御性检查。 ...

PostgreSQL commands \l 或 \list meta-command 列出所有数据库 sudo -u postgres psql -c "\l" 用 \c + 数据库名 来进入数据库： \dt 列出所有数据库表： # 查看表结构, 索引 \d table0 # 比上面多几个字段 Storage | Stats target | Description \d+ table0 # Turn off printing of column names and result row count footers, etc. This is equivalent to \t or \pset tuples_only. \t tuples only on/off, tuples only on 的时候 select 语句的输出不带 header \h \? \du 列出所有的用户 # 创建用户 CREATE USER user_0 WITH PASSWORD 'password_0'; # create database, 所有者 user_0 create database database_0 OWNER user_0; psql -h 192.168.1.100 -p 5432 -U user_0 -d database_0 PGPASSWORD=password_0 psql -h 192.168.1.100 -p 5432 -U user_0 -d database_0 --command 'select version();' #当表没有其他关系时 TRUNCATE TABLE tablename; #当表中有外键时，要用级联方式删所有关联的数据 TRUNCATE TABLE tablename CASCADE; # 查看 表大小 select pg_size_pretty(pg_relation_size('table0')); # 查看配置文件路径, 切换到 postgres 用户执行 psql -c "show config_file" # 查看版本 select version(); pacman -S postgresql psql -h 127.0.0.1 -p 5432 -d database0 -U user0 # create table create table test(id int, c1 int); create table table0(field0 json); # delete table DROP TABLE table0; # 查看字段类型 select column_name, data_type from information_schema.columns where table_name='table0'; select * length( "abc"::TEXT) insert into test select generate_series(1,10000), random()*10; # 复制表结构到另外一个数据库 pg_dump -U postgres --schema-only source_db | psql -U postgres target_db 导入/导出 export, 导出, 备份 # https://www.postgresql.org/download/linux/ubuntu/ # install pg_dump sudo apt install -y postgresql-common # This script will enable the PostgreSQL APT repository on apt.postgresql.org sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh # ubuntu install pg_dump sudo apt-get install postgresql-client-17 # -h, host 127.0.0.1 # -p, port 5432 # -t, table: table0, 不加 -t 参数时会导出所有表结构 # -s, 不导出数据 # database: database0 # -F : 指定输出文件的格式，它可以是以下格式之一： c: 自定义格式 d: 目录格式存档 t: tar 文件包 p: SQL 脚本文件 # -W 命令执行时提示输入用户密码（不会直接在命令中写密码）。 pg_dump -h 127.0.0.1 -U username -W -F t db_name > foo.tar # 导入 # -c --clean 创建数据库对象前先清理（删除）它们。 pg_restore -h 127.0.0.1 -U username -W -d db_name -c foo.tar pg_dump -h 127.0.0.1 -p 5432 -t table_0 -U postgres database0 > foo.sql pg_dump -h 127.0.0.1 -p 5432 -s -t table_0 -U postgres database0 > foo.sql # 导出并压缩 pg_dump -d db_name | gzip > db.gz pg_dump -a -t table_0 "host=127.0.0.1 hostaddr=127.0.0.1 port=5432 user=user_0 password=password_0 dbname=db_0" # export insert sql pg_dump -a -t table_0 "host=127.0.0.1 hostaddr=127.0.0.1 port=5432 user=user_0 password=password_0 dbname=db_0" --inserts 导入 # sql psql -h 127.0.0.1 -p 5432 -t table0 -U postgres -d database0 -f foo.sql # csv, https://stackoverflow.com/questions/26701735/extra-data-after-last-expected-column-while-trying-to-import-a-csv-file-into-p \COPY agency (agency_name, agency_url, agency_timezone) FROM 'myFile.txt' CSV HEADER DELIMITER ','; 导出指定的行 https://stackoverflow.com/questions/12815496/export-specific-rows-from-a-postgresql-table-as-insert-sql-script ...

distributed lock 分布式锁 分布式是一种分布式协调技术，控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。 分布式锁是由于单机锁无法满足分布式系统锁，在多进程/分布式环境下，需要分布式锁来控制共享内容，保证线程的安全。 为何需要分布式锁 Martin Kleppmann 是英国剑桥大学的分布式系统的研究员，之前和 Redis 之父 Antirez 进行过关于 RedLock (红锁，后续有讲到) 是否安全的激烈讨论。 Martin 认为一般我们使用分布式锁有两个场景: 效率: 使用分布式锁可以避免不同节点重复相同的工作，这些工作会浪费资源。比如用户付了钱之后有可能不同节点会发出多封短信。 正确性: 加分布式锁同样可以避免破坏正确性的发生，如果两个节点在同一条数据上面操作， 比如多个节点机器对同一个订单操作不同的流程有可能会导致该笔订单最后状态出现错误，造成损失。 分布式锁的一些特点 当我们确定了在不同节点上需要分布式锁，那么我们需要了解分布式锁到底应该有哪些特点？ 分布式锁的特点如下: 互斥性: 和本地锁一样互斥性是锁最基本的特性, 任意时刻，只有一个客户端能持有锁。 可重入性: 同一个节点上的同一个线程如果获取了锁之后那么也可以再次获取这个锁。 超时释放: 锁失效机制, 防止死锁。正常情况下，请求获取锁之后，处理任务，处理完成之后释放锁。 但是如果在处理任务发生服务异常，或者网络异常时，导致锁无法释放。其他请求都无法获取锁，变成死锁。 为了防止锁变成死锁，需要设置锁的超时时间。过了超时时间后，锁自动释放，其他请求能正常获取锁。 自动续期: 锁设置了超时机制后，如果持有锁的节点处理任务的时候过长超过了超时时间，就会发生线程未处理完任务锁就被释放了， 其他线程就能获取到该锁，导致多个节点同时访问共享资源。对此，就需要延长超时时间。 开启一个监听线程，定时监听任务，监听任务线程还存活就延长超时时间。当任务完成、或者任务发生异常就不继续延长超时时间。 高可用, 高性能: 加锁和解锁需要高效，同时也需要保证高可用防止分布式锁失效，可以增加降级。 安全性: 锁只能被持有锁的客户端释放, 不能被其它客户端释放. 支持阻塞和非阻塞: 和 ReentrantLock 一样支持 lock 和 trylock 以及 tryLock(long timeOut)。即没有获取到锁将直接返回获取锁失败 支持公平锁和非公平锁(可选): 公平锁的意思是按照请求加锁的顺序获得锁，非公平锁就相反是无序的。这个一般来说实现的比较少。 分布式锁一般有三种实现方式: 数据库乐观锁 基于 Redis 的分布式锁 基于 ZooKeeper 的分布式锁 可靠性 首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件: 互斥性。在任意时刻，只有一个客户端能持有锁。 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。 具有容错性。只要大部分的 Redis 节点正常运行，客户端就可以加锁和解锁。 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。 Redis 实现分布式锁 Redis 实现分布式锁，性能会比关系式数据库高一些. ...

什么是背压 背压 (Backpressure, back-pressure), 又称负压。 Backpressure 并不是响应式编程 (Reactive Programming) 独有的概念, 也不是一种「机制」或「策略」。 Backpressure 是一种现象: 在数据流从上游生产者向下游消费者传输的过程中, 上游生产速度大于下游消费速度, 导致下游的 Buffer 溢出, 这种现象就叫做 Backpressure。 背压的本质 可以用水管来类比: 上游 = 水源 (生产者, Producer) 下游 = 水龙头 / 水桶 (消费者, Consumer) 管道 = 消息队列 / Buffer 当水源出水速度远远大于水桶的接收速度时, 管道中的水压就会升高。如果不加以控制, 水桶会溢出, 即数据丢失或系统崩溃。这个"升高的压力"就是背压。 背压出现的场景 背压广泛存在于各类系统中: 消息队列: 生产者发送消息的速率超过消费者消费速率, 队列积压 流式计算: Kafka、Flink 等处理管道中, 上游数据涌入速度超过下游处理能力 网络传输: TCP 协议中, 发送方速率超过接收方处理能力时, 接收窗口收缩 响应式编程: RxJava、Project Reactor 等框架需要显式处理背压 微服务调用链: 下游服务响应慢, 上游请求积压导致线程池耗尽 背压的处理策略 背压本身是现象, 应对背压才是策略。常见的应对方式有以下几种: 1. 控制生产速率 (Flow Control) 主动降低上游的生产速度, 使其与下游消费能力匹配。典型实现是 TCP 的滑动窗口机制: 接收方通过 ACK 报文中的窗口大小字段, 告知发送方当前可接收的数据量。 ...

概念 优先级队列（Priority Queue）是一种特殊的队列，队列中每个元素都附有一个"优先级"。出队时，不再遵循普通队列的 FIFO（先进先出）原则，而是优先级最高（或最低）的元素先出队。 直观类比：医院的急诊室——无论谁先到，病情最重的患者优先就诊。 核心特性 插入（insert / enqueue）：将元素连同优先级一起加入队列 取最值（peek）：查看优先级最高的元素，不移除 取出最值（poll / dequeue）：取出并移除优先级最高的元素 不保证全局有序：内部结构只保证堆顶（最值）正确，其余元素顺序不确定 内部实现：二叉堆 绝大多数语言的标准库都用**二叉堆（Binary Heap）**实现优先级队列。 堆的结构 用完全二叉树表示，通常以数组存储 最小堆（Min-Heap）：父节点 ≤ 子节点，根为最小值 最大堆（Max-Heap）：父节点 ≥ 子节点，根为最大值 数组索引关系（从 0 开始）： 节点 索引 父节点 (i-1) / 2 左子节点 2*i + 1 右子节点 2*i + 2 核心操作：上浮与下沉 上浮（Sift Up）：插入新元素时，将其放在数组末尾，然后与父节点比较，不满足堆性质则交换，直到满足为止。 下沉（Sift Down）：取出堆顶后，将末尾元素移到堆顶，然后与子节点比较，不满足堆性质则与较小（或较大）的子节点交换，直到满足为止。 时间复杂度 操作 时间复杂度 插入 $O(\log n)$ 取出最值 $O(\log n)$ 查看最值 $O(1)$ 建堆（heapify） $O(n)$ 两种变体 最小优先级队列（Min Priority Queue） 优先级数值最小的元素最先出队。例如：Dijkstra 最短路径算法中，每次选取距离最小的节点。 最大优先级队列（Max Priority Queue） 优先级数值最大的元素最先出队。例如：任务调度中，优先执行优先级最高的任务。 ...

Git basic commands 目前比较流行的版本管理系统 相比同类软件，Git有很多优点。其中很显著的一点，就是版本的分支 (branch) 和合并 (merge) 十分方便。 有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本 (又称"快照") 的指针，因此非常快捷易用。 commands git status --porcelain #用于以简洁、脚本友好的格式显示 Git 仓库当前的状态，方便自动化处理和快速查看文件的变动情况。 git ls-files --unmerged git diff --name-only --diff-filter=U #显示出 HEAD 对应的提交的 hash 值 git rev-parse HEAD git rev-parse --short HEAD # windows install git winget install Git.Git # 显示工作树状态, (已经修改但是没 git add, 或者 没有 git commit) # 显示索引文件和当前HEAD提交有差异的路径，工作树和索引文件有差异的路径，以及工作树中不被Git追踪的路径（也不被gitignore[5]忽略）。前者是你通过运行 "git commit "会提交的东西；第二和第三者是你在运行 "git commit "之前通过运行 "git add "可以提交的东西。 git status -s # 查看本地仓库的当前分支和远程分支的差异(已经 commit 但是还没 push), 只显示 commit id 和 comments git cherry -v # 查看本地仓库的当前分支和远程分支的差异(已经 commit 但是还没 push), 展示方式类似 git log git log master ^origin/master # 计算对象数和磁盘消耗 git count-objects -vH # 指定目录 1.8.5 以前 git --git-dir=/Users/jhoffmann/tmp/my-project/.git --work-tree=/Users/jhoffmann/tmp/my-project/ pull # 指定目录 >=1.8.5 git -C /Users/jhoffmann/tmp/my-project/ pull options -C, 大写 C 指定目录, .git 所在的目录 –version, 查看 git 版本 origin https://www.zhihu.com/question/27712995 ...

k8s command commands kubekey https://github.com/kubesphere/kubekey Rancher https://rancher.com/ archlinux install k8s ubuntu install k8s commands # 查看某一个 pod 配置 kubectl get pod <pod-name> -n <namespace> -o yaml # 找到 Pod 所属的 Controller（通常是 Deployment） kubectl get pod <pod-name> -o jsonpath="{.metadata.ownerReferences[0].name}" # 查看 Deployment 的 YAML 启动命令 kubectl get deployment bgp-opt-backend -o yaml # exec api kubectl exec -it "$(kubectl get pods | grep -Eo '^[^ ]+' |grep api)" -- bash # pod kubectl get pod -A -o wide # 查看 pod, 比如能看到镜像版本 kubectl describe pods pod0 # configmap kubectl apply -f redis-config.yaml kubectl get configmap kubectl get configmap -n namespace0 kubectl edit configmap configmap0 kubectl delete configmap configmap0 # 显示集群信息 kubectl cluster-info kubectl cluster-info dump # 查询所有节点标签信息 kubectl get node -o wide --show-labels # kube-system namespace 的 pod kubectl get pods -n kube-system kubectl label node 192.168.0.212 gpu=true kubectl get node -L gpu kubectl get node -L kubernetes.io/arch # delete lable kubectl label node minikube disktype- kubectl describe node node0 ## 节点关机操作 ```bash # 1. 标记节点为不可调度（防止新 Pod 调度到该节点） kubectl cordon <node-name> # 2. 驱逐节点上的 Pod（优雅地将 Pod 迁移到其他节点） kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data # 3. 验证节点上是否还有 Pod 运行 kubectl get pods --all-namespaces -o wide | grep <node-name> # 4. 关机 sudo poweroff # 5. 节点重新上线后，恢复调度（取消不可调度状态） kubectl uncordon <node-name> 查看 pod 状态 kubectl get pods –all-namespaces ...

Git graph LR work["Working tree<br/>工作树/工作区"] stage["Index / Staging Area<br/>暂存区"] repo["Local Repository<br/>本地仓库"] remote["Remote Repository<br/>远程仓库"] work -->|add| stage stage -->|commit| repo repo -->|push| remote remote -->|pull| work remote -->|"fetch/clone"| repo stage -->|checkout| work repo -->|merge| work repo -->|"reset --soft"| stage repo -->|rebase| stage repo -->|"reset --mixed"| work 工作区 (working tree) working tree, 2.9.1 之前被称作 Working Directory https://stackoverflow.com/questions/39128500/working-tree-vs-working-directory 也称工作区, 工作目录、工作副本 我们日常开发操作是在工作区中进行的。 工作区的内容会包含提交到暂存区和版本库(当前提交点)的内容，同时也包含自己的修改内容。 ...

“video, h.264, h.265, ffmpeg” H.265与H.264是ITU-T VCEG 制定的视频编码标准。H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。具体的研究内容包括: 提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。H264由于算法优化，可以低于1Mbps的速度实现标清数字图像传送；H265则可以实现利用1~2Mbps的传输速度传送720P (分辨率1280*720) 普通高清音视频传送。 H.265旨在在有限带宽下传输更高质量的网络视频，仅需H.264的一半带宽即可播放相同质量的视频。H.265标准也同时支持4K(4096×2160)和8K(8192×4320)超高清视频。 H.264 H.264，同时也是MPEG-4第十部分，是由ITU-T视频编码专家组 (VCEG) 和ISO/IEC动态图像专家组 (MPEG) 联合组成的联合视频组 (JVT，Joint Video Team) 提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC (或者AVC/H.264或者H.264/MPEG-4AVC或MPEG-4/H.264 AVC) 而明确的说明它两方面的开发者。 H.264最大的优势是具有很高的数据压缩比率，在同等图像质量的条件下，H.264的压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。举个例子，原始文件的大小如果为88GB，采用MPEG-2压缩标准压缩后变成3.5GB，压缩比为25∶1，而采用H.264压缩标准压缩后变为879MB，从88GB到879MB，H.264的压缩比达到惊人的102∶1。低码率 (Low Bit Rate) 对H.264的高的压缩比起到了重要的作用，和MPEG-2和MPEG-4ASP等压缩技术相比，H.264压缩技术将大大节省用户的下载时间和数据流量收费。尤其值得一提的是，H.264在具有高压缩比的同时还拥有高质量流畅的图像，正因为如此，经过H.264压缩的视频数据，在网络传输过程中所需要的带宽更少，也更加经济。 H.265, HEVC(高效视频编码) H.265是ITU-TVCEG继H.264之后所制定的新的视频编码标准。H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。 新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。具体的研究内容包括: 提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。H264由于算法优化，可以低于1Mbps的速度实现标清数字图像传送；H265则可以实现利用1~2Mbps的传输速度传送720P (分辨率1280*720) 普通高清音视频传送。 H.265旨在在有限带宽下传输更高质量的网络视频，仅需原先的一半带宽即可播放相同质量的视频。这也意味着，我们的智能手机、平板机等移动设备将能够直接在线播放1080p的全高清视频。H.265标准也同时支持4K(4096×2160)和8K(8192×4320)超高清视频。可以说，H.265标准让网络视频跟上了显示屏"高分辨率化"的脚步。 H.265 与 H.264 有何不同 在讨论 H.265有哪些提升和优点之前，我们不妨先来了解一下H.264。H.264 也称作 MPEG-4AVC(Advanced Video Coding，高级视频编码)，是一种视频压缩标准，同时也是一种被广泛使用的高精度视频的录制、压缩和发布格式。H.264 因其是蓝光光盘的一种编解码标准而著名，所有蓝光播放器都必须能解码H.264。更重要的是，因为苹果公司当初毅然决然抛弃了Adobe 的VP6 编码，选择了 H.264，这个标准也就随着数亿台iPad和iPhone 走入了千家万户，成为了目前视频编码领域的绝对霸主，占有超过80%的份额。H.264 也被广泛用于网络流媒体数据、各种高清晰度电视广播以及卫星电视广播等领域。H.264相较于以前的编码标准有着一些新特性，如多参考帧的运动补偿、变块尺寸运动补偿、帧内预测编码等，通过利用这些新特性，H.264比其他编码标准有着更高的视频质量和更低的码率，也因此受到了人们的认可，而被广泛应用。 H.265/HEVC 的编码架构大致上和H.264/AVC的架构相似，也主要包含: 帧内预测(intra prediction)、帧间预测(inter prediction)、转换(transform)、量化(quantization)、去区块滤波器(deblocking filter)、熵编码(entropy coding)等模块。但在HEVC编码架构中，整体被分为了三个基本单位，分別是: 编码单位(coding unit，CU)、预测单位(predict unit，PU)和转换单位(transform unit，TU)。 H.265为 何优于H.264 比起H.264/AVC，H.265/HEVC提供了更多不同的工具来降低码率，以编码单位来说， 最小的8x8到最大的64x64。信息量不多的区域(颜色变化不明显，比如车体的红色部分和地面的灰色部分)划分的宏块较大，编码后的码字较少，而细节多的地方(轮胎)划分的宏块就相应的小和多一些，编码后的码字较多，这样就相当于对图像进行了有重点的编码，从而降低了整体的码率，编码效率就相应提高了。同时，H.265的帧内预测模式支持33种方向(H.264只支持8种)，并且提供了更好的运动补偿处理和矢量预测方法。 反复的质量比较测试已经表明，在相同的图象质量下，相比于H.264，通过H.265编码的视频码流大小比H.264减少大约39-44%。由于质量控制的测定方法不同，这个数据也会有相应的变化。通过主观视觉测试得出的数据显示，在码率减少51-74%的情况下，H.265编码视频的质量还能与H.264编码视频近似甚至更好，其本质上说是比预期的信噪比(PSNR)要好。这些主观视觉测试的评判标准覆盖了许多学科，包括心理学和人眼视觉特性等，视频样本非常广泛，虽然它们不能作为最终结论，但这也是非常鼓舞人心的结果。 目前的HEVC 标准共有三种模式: Main、Main10 和Main Still Picture。Main模式支持8bit色深(即红绿蓝三色各有256个色度，共1670万色)，Main10模式支持10bit色深，将会用于超高清电视(UHDTV)上。前两者都将色度采样格式限制为4: 2: 0。预期将在2014年对标准有所扩展，将会支持4: 2: 2和4: 4: 4采样格式(即提供了更高的色彩还原度)和多视图编码(例如3D立体视频编码)。 ...

ps command Linux 中的 ps 命令是 Process Status 的缩写 输出指定的字段 ps -eo pid, ppid, command ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' 其中 rsz 是是实际内存 ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' | grep oracle | sort -nrk5 其中 rsz 为实际内存，上例实现按内存排序，由大到小 http://blog.fpliu.com/it/software/procps ps 命令用来列出系统中当前运行的那些进程。ps 命令列出的是当前那些进程的快照，就是执行ps命令的那个时刻的进程，如果想要动态的显示进程信息, 可以使用 top 命令。 要对进程进行监测和控制，首先必须要了解当前进程的情况，也就是需要查看当前进程，而 ps 命令就是最基本同时也是非常强大的进程查看命令。使用该命令可以确定有哪些进程正在运行和运行的状态、进程是否结束、进程有没有僵死、哪些进程占用了过多的资源等等。总之大部分信息都是可以通过执行该命令得到的。 linux 上进程有 5 种状态 运行 (正在运行或在运行队列中等待) 中断 (休眠中, 受阻, 在等待某个条件的形成或接受到信号) 不可中断 (收到信号不唤醒和不可运行, 进程必须等待直到有中断发生) 僵死 (进程已终止, 但进程描述符存在, 直到父进程调用wait4()系统调用后释放) 停止 (进程收到SIGSTOP, SIGSTP, SIGTIN, SIGTOU信号后停止运行运行) STAT 进程的状态 R 运行 Runnable (on run queue) 正在运行或在运行队列中等待。 S 睡眠 Sleeping 休眠中, 受阻, 在等待某个条件的形成或接受到信号。 I 空闲 Idle Z 僵死 Zombie (a defunct process) 进程已终止, 但进程描述符存在, 直到父进程调用wait4()系统调用后释放。 D 不可中断 Uninterruptible sleep (ususally IO) 收到信号不唤醒和不可运行, 进程必须等待直到有中断发生。不可中断的睡眠，通常是I/O T 停止 traced or stopped 进程收到SIGSTOP, SIGSTP, SIGTIN, SIGTOU信号后停止运行运行。 停止或被追踪 terminate终止 P 等待交换页 W 进入内存交换（从内核2.6开始无效） 无驻留页 has no resident pages 没有足够的记忆体分页可分配。换出,表示当前页面不在内存 (从内核2.6开始无效) X 死掉的进程 < 高优先级进程 N 低优先级进程 L 内存锁页 Lock 有记忆体分页分配并缩在记忆体内, 些页被锁进内存 s session leader (在它之下有子进程) l 多进程的 (使用 CLONE_THREAD, 类似 NPTL pthreads) + is in the foreground process group, 前台运行. 默认情况下, ps 不会显示很多进程信息, 只是列出与当前终端会话相关的进程 ...

kitty kitty 是一个 GPU based terminal https://sw.kovidgoyal.net/kitty/ SSH 连接远程主机 xterm-kitty: unknown terminal type Kitty 使用 xterm-kitty 作为 $TERM 环境变量的值。通过 SSH 连接远程主机时，该值会被传递过去，但远程主机的 terminfo 数据库中没有 xterm-kitty 的定义，导致 git、vim 等程序报错： 'xterm-kitty': unknown terminal type. 解决方案：使用 kitty +kitten ssh Kitty 内置了 ssh kitten，连接时会自动将 terminfo 传到远程主机。 在 ~/.zshrc（或 ~/.bashrc）中添加别名： alias ssh='kitty +kitten ssh' 然后执行： source ~/.zshrc 之后直接执行 ssh openclaw 即可，无需其他改动。 远程控制（Remote Control） Kitty 支持通过命令行远程控制终端，可以实现自动化窗口管理、发送命令等功能。 启用远程控制 在 ~/.config/kitty/kitty.conf 中添加： # Unix Socket 方式（推荐，可从任何终端控制） allow_remote_control socket-only listen_on unix:/tmp/kitty.sock 注意：使用 Unix Socket 方式时，Kitty 会在 socket 文件名后自动添加进程 ID，例如： ...

“network manager” sudo pacman -S networkmanager sudo systemctl status NetworkManager.service sudo systemctl start NetworkManager.service sudo systemctl restart NetworkManager.service sudo pacman -S nm-connection-editor sudo pacman -S network-manager-applet nmcli device nmcli connection nmcli c delete System policy prevents control of network connections System policy prevents control of network connections System policy prevents modification of network settings for all users< vim /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy Open /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy with root/sudo privileges and search for the following line: ...

git merge git rebase interactive rebase Join two or more development histories together merge 合并 用于将两个或多个分支的更改合并到一起。它通常用于将一个分支上的开发成果合并到当前分支（如将 feature 分支合并回 main 分支）。其主要作用是整合不同开发者或分支上的工作，保持代码库的统一和最新。 # 基本用法 # git merge <branch-name> # merge 默认会把 commit 的历史都合并进来 # 把 branch_0 合并到当前分支 git merge branch_0 # -m 参数用于指定合并提交（merge commit）的说明信息，即合并时生成的 commit message。 git merge branch_0 -m "MSG0" # 禁用 Fast forward git merge branch_0 -m "merge with no-ff" --no-ff 合并方式 Fast-forward（快进合并） 如果当前分支没有新的提交，仅仅是落后于目标分支，Git 会直接把指针向前移动到目标分支的位置，这种合并不会产生新的合并提交。快速合并，看不出做过合并。快进合并后不会留下一个明显的"feature 分支合并节点"，只有一条线性的记录。 特点： 不创建 merge commit 分支指针直接前移 提交历史呈线性 无法看出曾经有分支存在 示意图： ...