Posts on

VibeCoding个人配置

Sun, 24 May 2026 00:00:00 +0000

工欲善其事，必先利其器

status line.sh

Superpowers

Notification

cc switch

过目不忘：CLAUDE

Sun, 24 May 2026 00:00:00 +0000

核心概念
#

CLAUDE.md是Claude Code的核心配置文件，它相当于项目的**”说明书”**，告诉Claude如何理解和处理你的代码库。一个好的CLAUDE.md可以显著提升AI的理解准确性和工作效率。我结合自己的项目来说明如何写一个配置。

其作用如下：

上下文设置：为Claude提供项目背景、技术栈、架构信息
约束定义：设定开发规范、代码风格、质量标准
任务指导：提供明确的执行指令和优先级
知识传承：保存项目的重要决策和设计理念

为什么重要？

减少沟通成本：避免重复解释项目背景
提升准确性：使Claude更好地理解你的意图
保持一致性：确保所有修改都符合项目规范，在团队合作中保持代码的一致性
加速开发：减少调试和返工时间

工作原理
#

当你在项目目录启动 Claude Code 时，发生的“记忆系统初始化”过程如下图所示。

CLAUDE.md 的内容会每次对话都加载，所以要精简。把“每次都需要”的内容放这里，把“偶尔需要”的内容放到 Skills 或文档里。

Claude Code 支持五个层级的记忆，就像洋葱一样，从外到内，按层级结构组织——高层级的文件优先加载，为底层文件提供基础：

其中每个层级都有其用途及使用场景，如下所示：

记忆类型	位置	用途	使用场景	共享范围
企业策略	macOS:/Library/ApplicationSupport/ClaudeCode/CLAUDE.md Linux: /etc/claude-code/CLAUDE.md Windows: C:\Program Files\ClaudeCode\CLAUDE.md	组织级指令，由 IT/Devops管理	公司编码标准、安全策略、合规要求	组织内所有用户
项目记忆	./CLAUDE.md或者./claude/CLAUDE.md（必须提交到git）	团队共享的项目指令	项目架构，编码标准，常用工作流	通关版本管理与团队成员共享
模块记忆	./claude/rules/*.md	模块化的、特定主题的项目指令	语言特定指南、测试规范、API标准	通关版本管理与团队成员共享
用户记忆	~/.claude/CLAUDE.md	跨所有项目的个人偏好	代码风格偏好、个人工具快捷方式	仅自己
项目本地	./CLAUDE.local.md（记得把他加到.gitignore）	跨所有项目的个人偏好	你的沙箱URL、偏好的测试数据	仅自己

基础结构
#

项目记忆一般来说是整个开发过程中最常用的“说明书”了，一个完整的项目CLAUDE.md文件包含以下几个部分：

gmview设计

Thu, 21 May 2026 00:00:00 +0000

背景
#

profobuf公共大仓与本地引用的protobuf官方库依赖的底层的grpc库会产生冲突，因为不同版本的grpc库的函数签名不同，新版本的不兼容历史版本（相信不少人都遇过底层依赖etcd函数报错的问题，真是苦天下久诶），所以萌生了一个go mod依赖可视化的想法。其实早在2024年就已经实现了一版，但苦于工作繁忙没有继续完善，现在有时间了利用AI重新完善一版。

设计
#

gmview意为 go mod view，即go引用库的可视化视图，其核心步骤就两个：

获取当前go引用库的依赖关系
在页面中展示这个依赖关系

git删除远程文件

Wed, 20 May 2026 00:00:00 +0000

why
#

需要删除远程仓库的一些文件，例如一些本地文件
不小心把一些ide配置文件发到远程git仓库。例如 .idea .vscode

how
#

针对第一个种情况，需要删除本地文件&远程文件

#删除本地 & 远程
git rm 文件 //本地中该文件会被删除
git rm -r 文件夹 //删除文件夹
git add .
git commit -m '删除某个文件'
git push

如果是像第二种情况，只是不想把ide文件传上去，在本地还是需要保存的，那么只删远程文件即可

#删除远程
git rm --cached 文件 //本地中该文件不会被删除
git rm -r  --cached  文件夹 //删除文件夹
git add .
git commit -m '删除某个文件'
git push

当然，记得新增一个.gitignore，防止再次将.idea上传。

触类旁通：Skill

Tue, 19 May 2026 00:00:00 +0000

Skill的背景
#

每个公司每个团队都与自己的一套规范，例如代码风格规范、API设计规范、安全审查清单规范、部署流程规范，这些规则并不复杂，但是数量很多。开发者通常不可能将他们全部记忆下来，大部分工程师的做法是：需要时再查阅。

如果我们把 Claude 当作真正的工程助手，它也会面临同样的问题。最直接的做法，是把所有团队规范写进 CLAUDE.md，让模型每次对话都读取这些内容。短期看这是可行的。但当知识规模扩大到几十页甚至上百页时，问题就出现了——每一次对话都在为“可能用不到的知识”支付上下文成本。这不仅消耗 token，更重要的是，它会稀释模型的注意力。真正需要用到的规则，反而淹没在冗余信息里。

Skills的出现解决了这一问题。Skills 并不是简单的“能力扩展机制”，它本质上是一种按需加载的认知结构。与其把所有知识常驻在上下文中，不如把它们封装成可独立触发的能力单元。当模型判断当前任务涉及某个特定领域时，再加载对应的知识与操作流程。Skills 解决的核心问题是，在有限的上下文窗口中，让 Agent 在正确的时刻拥有正确的领域知识。

对于企业来说，把专业流程、领域知识和行动判断封装成可复用的能力单元，然后让智能体按需加载和调用，这是一种让通用模型具备专业化、按需调用能力的通用设计模式。类似 Skills 的模块化能力已经被用于数据分析、校验、报告生成等任务，把自然语言指令转化成结构化的专业工作流；也有技术方案将企业组件库、开发规范等封装成“技能包”，让模型自动发现、理解并正确应用这些业务能力。

正因为“模型调度能力”和“可操作知识”的重要性，Skills 已经逐渐脱离了 Claude 的语境，成了 Agent 生态中的通用概念。“技能化”思路正在从 Claude 系统扩展到其他智能体平台，以及 AI 赋能的工程工具中。在 Claude 发布的 Agent Skills 公用仓库中，集成了大量可复用的能力。Coze 也推出了技能商店，为 Coze 智能体生态提供即插即用的能力组件。

Skill的类型
#

从工程角度，Skill 内容分为两类，参考型和任务型。参考型 Skill 影响“怎么做”，任务型 Skill 决定“做什么”。前者是语义环境，后者是具体行动。

参考型
#

参考型 Skill 更像组织的行为规范层。它定义“在这个世界里，什么是正确的做法”——例如 API 设计标准、代码风格、错误处理约定。这类 Skill 通常由模型根据语义自动判断是否加载，它不主导行动，而是塑造行动的方式。它属于“世界规则”。

防微杜渐：Hook

Tue, 19 May 2026 00:00:00 +0000

Hook出现背景
#

如果你有 Web 开发经验，你一定熟悉中间件（Middleware）的概念。

请求 → 中间件1 → 中间件2 → 中间件3 → 处理函数 
                 ↓ 认证、日志、限流

中间件在请求到达最终处理函数之前插入检查和处理，实现横切关注点（Cross-cutting Concerns）。这些逻辑不属于任何一个业务功能，但又必须贯穿所有请求——认证要每个接口都检查，日志要每个操作都记录，限流要每个入口都控制。

Claude Code 的 Hooks 机制与此异曲同工，但它针对的不是 HTTP 请求，而是 AI Agent 的工具调用。

用户请求 → Claude 决策 → [PreToolUse Hook] → 工具执行 → [PostToolUse Hook] → 响应 
                               ↓ 权限检查、拦截                 ↓格式化、验证、日志

Hooks 是 AI 助手的中间件——拦截、监控、增强每一次交互。这个类比不仅是形象上的相似。Web 中间件解决的核心问题是“业务代码不应该操心安全和日志”，Hooks 解决的核心问题也一样——Claude 不应该操心格式化和权限检查，它只管写好代码就行。安全防线、质量守卫、审计日志，全部由 Hooks 在“幕后”自动完成。

Hook事件
#

截至 2026 年 3 月，根据 Anthropic 官方文档，Claude Code 支持 17 种 Hook 事件，覆盖了从会话启动到结束的完整生命周期：

Hello World

Wed, 29 Apr 2026 16:51:06 +0800

你好
#

吃饭
睡觉
无聊

我好
#

对	与	错
	23
	wera	e w er
		Sofa

大家好
#

fmt.Println("hellow world")

各司其职：SubAgent

Wed, 22 Apr 2026 00:00:00 +0000

为什么需要SubAgent
#

我们先从一个常见场景开启今天的内容。

某天，你让 Claude Code 帮你跑一个测试套件，结果输出了 500 行日志；然后你想让它分析一下代码结构，又输出了 200 行；接着你想让它改一个 bug……这时候，你的对话上下文已经被各种“中间过程”塞满了，真正重要的信息被淹没在茫茫的输出海洋里。

其实，究其根本。如果你觉得 Claude Code 越用越“健忘”，并不是模型退化了，而是你的对话上下文，已经被一次次中间过程污染了,这正是子代理要解决的核心问题。因为只有子代理，才在系统层面天然拥有一个独立的上下文窗口。不是因为它“聪明”，不是因为它“更强”，而是因为它是 Claude Code 里唯一一个，结构上允许“执行完即丢弃”的东西。

在前面的现象里，上下文里充斥着这些内容：

跑测试 → 500 行日志。
搜索代码 → 200 行 grep。
分析错误 → 一堆中间推理过程……

这些信息有一个共同特征：它们对“当下执行”是必要的，但对“后续决策”是噪声。而 Claude Code 的主对话上下文是线性追加的，不会自动过期，默认“都当成重要记忆”。所以问题不是 Claude 突然不聪明了，而是它把临时执行数据，当成了长期决策记忆。这在工程上，本来就一定会“炸”。

而子代理，通过上下文隔离，让专业的 Agent 做专业的事儿，不是为了让 Claude 做得更多，而是为了让 Claude 记得更少，但记得对。

什么是SubAgent
#

SubAgent当于一个“专职小助手”，它拥有独立的：

15. 交易树与收据树

Sat, 29 Nov 2025 00:00:00 +0000

交易树与收据树
#

上篇文章中讲了数据结构MPT及状态树，这篇文章再来讲交易树与收据树。交易树与收据树同样基于MPT，分别用于存储区块内的交易信息与交易执行结果，是保证以太坊数据可验证性和透明性的关键组件。二者均与区块一一对应，其根哈希会被记录在区块头中，确保数据不可篡改。

交易树
#

交易树是每个区块内所有交易的结构化存储载体，本质是一棵以交易在区块中的序号为键的 MPT。

其核心作用：

记录区块内所有交易的完整信息，包括发送方、接收方、转账金额、Gas 设置、智能合约调用数据等。
生成交易根哈希并写入区块头，任何人可通过该哈希验证区块内交易是否被篡改，也可通过Merkle Proof快速验证某笔交易是否存在于区块中。

结构特点：

交易的索引（在区块中的序号）会被 RLP 编码后作为 MPT 的键，由于交易序号是连续的数字，其路径前缀共享的概率极低，因此交易树的 MPT 路径压缩特性几乎无法体现，但仍保留 MPT 的密码学验证能力。
与状态树不同，每个区块的交易树仅包含相关的交易，不同区块的交易树不会共享节点。

收据树
#

收据树也叫回执树，存储每笔交易执行后的结果信息，同样是基于 MPT 构建，且与交易树的节点一一对应。

核心作用：

记录交易执行的最终状态，包括交易是否成功、消耗的 Gas 量、智能合约触发的事件日志（Log）、区块哈希与交易哈希关联信息等。
生成收据根哈希写入区块头，为轻节点验证交易执行结果提供依据，比如钱包可通过收据树验证转账是否到账、智能合约事件是否触发。

结构特点：

16. 以太坊的共识协议

Sat, 29 Nov 2025 00:00:00 +0000

前言
#

前面的文章中说过比特币的出块时间在10m左右，且需要经过多个区块确认后才能认为交易已完成（一般是6个区块，主要是为了防止临时性分叉）。这也就意味着在比特币中大概要1h左右才能确保交易已完成。而以太坊的出块时间降到了15s左右，大大提升了以太坊的吞吐与效率，但是出块时间太快又会带来临时性分叉的问题，导致那些符合难度要求但没有成为最长合法链区块被抛弃，严重影响了矿工的积极性。对此以太坊使用了改进版的GHOST协议来解决这一问题。

GHOST协议
#

GHOST（Greedy Heaviest-Observed Sub-Tree，贪婪最重可观测子树）是区块链共识优化机制，核心是在快速出块场景下将孤块 “叔块” 纳入权重与奖励，提升安全性与吞吐量。

14. 以太坊的状态树

Sun, 23 Nov 2025 00:00:00 +0000

以太坊的状态树
#

上一篇文章中我们说了每个以太坊账户中有余额、nonce、code、storage等属性，这篇文章就是讲用什么数据结构，将用户地址与这些属性关联起来。简单来说就是如何存储 address -> state 映射关系。首先要明确这个数据结构需要实现的目的：

给手机钱包等轻节点提供Merkle Proof验证，能够验证任意用户的状态。
保证账户状态的防篡改与可验证性，任意微小的改变都能被感知。
适配以太坊的状态模型与性能需求，以高效快捷的方式在各节点之前同步及验证状态。

方案1: 哈希表
#

既然是映射，一个直观的想法是哈希表，即系统中的全节点维护一个哈希表，查询与操作的时间复杂度都是O(1)，简单又高效。但是缺点也很明显，哈希表没法提供地址状态的Merkle Proof。

方案2: Merkle Tree
#

既然要满足Merkle Proof，那能Merkle Tree就天然地满足了这个需求，能跟比特币一样否直接使用Merkle Tree？答案是NO。

为什么比特币中能使用Merkle Proof，而以太坊不行呢？是因为比特币中用Merkle Tree存储的是一个区块的交易数据，前面我们分析过大概是4000个交易。而以太坊需要存储的是所有用户的状态数据，这里可能是千万量级的，如果每次发布区块都要重新构建这个Merkle Tree，从效率上来说并不可行，实际上每次发布区块只涉及部分地址的状态变更，从这点来看重建Merkle Tree的性价比也太低了。

另外，每个节点打包时虽然状态一样，但是只要叶子节点顺序不一致，那Merkle Tree的根哈希值也不一样，无法做到节点之间同步。

如上图所示，虽然两个节点打包的都是ABCD四个账户的状态数据，但最后他们的根哈希值并不相同。

11.比特币思考

Sat, 22 Nov 2025 00:00:00 +0000

哈希指针
#

比特币系统中很多地方都用到了哈希指针，但是指针是只指向某个内存地址的，这个指针只有在本地计算机才有意义，如果一个新的区块发布，区块里的哈希指针在其他的节点中并不适用，那么比特币是如何设计这个哈希指针的呢？

实际中，比特中的哈希指针只有哈希，没有指针。全节点一般将区块存储于一个kv数据库（如上图所示）中，key为哈希，value为区块内容，一个常用的kv数据库是levelDB。

区块恋
#

有的情侣共用一个账户购买比特币，账户的私钥一人保管一半，如果两人感情一直好，则可以一直维持，但一旦两人感情破裂，那这些比特币将会变成死钱，永远取不出来。同样的，如果一个商铺有四个合伙人，每人保管1/4的私钥，这样也会带来一些列问题：

其中一个人忘记私钥，将永久无法交易，买的币将永久存于UTXO集合，对矿工不友好。
截断私钥长度会降低安全性，128位密钥的破解难度要远小于256位的密钥，假设有三个合伙人串通起来瞒着另一个合伙人将钱取出来，那他们只需要尝试2^64次。

分布式共识
#

从理论上来说，分布式系统中取得共识是不可能的，那比特币为什么能够取得共识呢？严格地说，比特币并没有取得真正意义上的共识，因为取得的共识随时都有可能被推翻。比如分叉攻击，本来以为已经达成了某个共识，分叉攻击后，系统会回滚到前一个状态。

此外，理论与实际之间存在差异，在实际中窒只需要把模型稍微改改，就能够变得适用。

比特币的稀缺性
#

前面我们说过，比特币的总量在2100万个，并且每隔一个周期，出块奖励都会减半，这样会导致越到后面比特币会越稀缺，但是实际上是稀缺的东西是不适合用来做货币的。我们可以参考黄金，黄金在很长一段时间作为货币在使用，但是现代社会基本都抛弃了金本位，因为现实中每年黄金产量要远远小于社会产生的财富，如果继续用黄金作为货币，那么黄金会变得越来越值钱，以致于前期拥有黄金的人会一直在食物链顶端，后面的人怎么怎么赶也赶不上，个人奋斗将变得毫无意义，一个健康向上的社会不应该出现这种情况。

量子计算
#

比特币是建立在密码学的基础上的，量子计算起来之后这些加密货币会不会变得不安全？

12. 以太坊

Sat, 22 Nov 2025 00:00:00 +0000

概述
#

比特币跟以太坊是两种最主要的加密货币，以太坊可以说是比特币的2.0版本，相较于比特币，其做了如下改进。

核心功能
#

比特币的核心仅支持简单的价值转移交易，协议逻辑简洁，只能实现去中心化支付相关功能，无法承载复杂业务逻辑。以太坊引入了智能合约和以太坊虚拟机（EVM），能实现任意复杂的逻辑运算。

共识机制
#

特币采用工作量证明（PoW）机制，节点需通过大量算力运算竞争记账权，而ASIC芯片的出现将挖矿算力集中化，已经偏离了比特币最开始的设计。以太坊使用的是权益证明（PoS）机制，验证者无需靠算力竞争，而是通过质押 ETH 获取记账和验证资格。

经济模型
#

比特币总量固定为 2100 万枚，采用固定的挖矿奖励减半机制，经济模型核心围绕 “稀缺性” 设计，以太坊无固定总量上限，但通过 PoS 机制减少发行量。

性能与扩展
#

比特币区块大小和出块时间固定，导致网络吞吐量极低，仅能满足少量交易需求，一旦交易激增就会出现拥堵，且手续费大幅上涨。以太坊将区块链拆分为多个平行分片，并行处理交易，理论上大幅提升吞吐量。

13. 以太坊的账户

Sat, 22 Nov 2025 00:00:00 +0000

前言
#

在讲以太坊的账户之前，先说下比特币的账户有哪些缺点，再来讲以太坊跟比特币账户模式的不同点。

比特币账户
#

前面我们说过，比特币中账户就是一个私钥地址，且账户并没有显式的余额的概念，余额是通过UTXO集合算出来的。此外，在比特币的一次转账中，必须要一次性的把一个UTXO集合的输出全部花掉。

例如上图所示，如果A的UTXO输出有10个比特币，要转3个比特币转给B，那么A要把剩下的7个毕业币转给自己的另外一个账户A’，否则那7个比特币就变成给矿工的手续费了。

以太坊账户
#

在以太坊中账户与现在的银行账户模式类似，都是显式地记录了账户的余额，转账只需要查询转账者的账户中是否有足够余额的钱。

这种模式的好处是：

转账变得简单清晰，不再需要将余额转给自己的另一个账号。
天然地防范了 Double Spending 攻击，因为花两次，就会扣账户两次的钱。

以太坊的账户模式解决了比特币中的Double Spending 攻击，但又会带来另一种问题，就是Replay 攻击。以上图来举例，假如B是有恶意的，将A->B的这个交易再广播给其他的节点，那么A的钱会被再扣一次，B的钱会再加一次。其实可以看出Replay 攻击跟Double Spending 攻击是对称的，前者是收款人有恶意，后者是付款人有恶意。

如何解决
#

以太坊中是引入nonce值来解决Replay 攻击的。在以太坊的每个交易中不仅有交易相关的信息，而且有一个nonce值，其是一个连续递增的整数，nonce值可以理解为账号的第几次交易。

10. 比特币匿名性

Sat, 15 Nov 2025 00:00:00 +0000

比特币的匿名性
#

比特币的 “匿名性” 是一个被广泛误解的核心特性—— 它并非绝对匿名，而是一种伪匿名，更准确的描述是地址匿名、交易公开可追溯。甚至与纸币相比，纸币的匿名性更好，因为纸币上面没有任何任何个人相关的信息。

下面分别从几个角度分析下比特币匿名的局限性。

账号关联
#

在一次比特币交易中，通常会有多个输入及多个输出。我们前面说过，比特币基于utxo集合，在现实世界中很少某个utxo输出刚好等于你要交易的金额，这就意味着某笔交易可能需要多个utxo输出及"找零"的情况。

在上面的情况中，输入的两个账号很可能都是同一个人的，很可能该人同时用于这两个账号的私钥，从而发起的交易。同样的，account_4也很可能是找零的地址，account_3是实际的交易金额（为什么不是反过来？因为如果实际交易金额是account_3的3个比特币的话，那account_1跟account_2单个账号金额就足够了，也没必要用两个账号了）。

由上，能由交易的账号信息，从而将这些账号进行关联。

身份关联
#

任何使得比特币和实体世界中关联的操作都有可能泄露用户真实身份，其中最典型的就是比特币与法币的交易。例如在钱包软件中使用法币购买比特币，或者将比特币出售以换取法币（但对于大额法币的转入与转出，很难逃避司法机构的监管）。

监管机构通过链上分析工具已破获多起利用比特币洗钱的案件比较著名的有silk road事件

实际上，很难不让比特币与现实世界产生关联，除非，你完全不使用比特币。这样的人也不是没有，比特币的发明人中本聪就是其中一个（传闻他有大量比特币，但从未使用过）。

如何提高匿名性
#

如果要提高比特币的匿名性，可以从两个方向来实现，一个是网络层，一个是应用层。

4. 比特币挖矿

Sat, 15 Nov 2025 00:00:00 +0000

比特币共识
#

在文章开始之前，必须先聊聊共识。共识是在某个群体或系统中，针对特定问题或规则达成的普遍一致意见或共同认识。

为什么需要共识
#

通过前面的知识我们知道，比特币是一个去中心化的账本，在这个世界上的每一个节点都可以打包交易的信息，即获得比特币的记账权。

究竟以哪个节点打包的信息为主？
如何让所有用户都认可某个节点打包的账单信息？
打包交易有什么利可图？

如何达成共识
#

在日常生活中，投票是一个达成共识的好办法。那在比特币中能否使让用户投票，来决定记账权呢？答案自然是否定的，因为在比特币中的账号可以无限产生，只要生成一对公私钥对就相当于生成了一个账户，如果有人恶意生成足够多账户，那他就可以控制投票的结果（女巫攻击）。

在比特币中也是利用投票机制，但不是按照账户投票，而是按照计算力来投票。

挖矿
#

发行货币
#

在讨论挖矿之前，我们先来说说如何发行比特币。前面的文章中我们讨论的交易都是在两个用户之间进行的，例如A转给B，B转给C，但在这些交易自始至终都没有产生新的货币，那这些货币最开始是从哪里产生的呢？答案就是出块奖励。

9. 比特币分叉

Sat, 15 Nov 2025 00:00:00 +0000

什么是分叉
#

比特币分叉的本质是区块链因规则变更或数据一致性冲突，导致原本单一的区块链分裂成为两条甚至多条独立的链。分叉的核心原因是比特币网络中不同节点对 “交易验证规则”“区块结构” 等核心协议产生分歧，且无法达成统一共识，最终各自遵循新规则继续记账，形成并行的区块链。

软分叉与硬分叉
#

根据分叉的性质、触发方式及对网络的影响，主要分为两大类：软分叉和硬分叉

硬分叉
#

hard fork 即硬分叉，是对现有协议的非向后兼容式修改，新规则与旧规则完全冲突，遵循旧规则的节点无法识别新规则的区块，最终网络会永久分裂为两条独立的链，各自拥有独立的代币、交易历史和社区。

例如，当比特币中出现协议更新，但并非所有节点都认同这个协议更新时，就会出现硬分叉。我们前面提过，每个区块的大小的上限是1MB，假设每笔交易大小占250KB，那么一个区块大概能容纳4000个交易。按照每10分钟出一个区块，那么每秒仅能写入7个交易，这跟现有的中心化的金融体系的每秒交易数量差了好几个数量级。

假设有人提议修改比特币协议，将每个区块的容量上限从1MB改成4MB，那么同意新协议的节点跟不同意的节点将会产生硬分叉。

在上图中，上限1MB的节点收到上限4MB的节点不会认同，会认为他是一个非法的区块，下面这条链永远不会认同上限4MB的区块。而上限4MB的节点收到一个上限1MB的区块会认同（因为其上限没有超过4MB），但下面的链永远不会认可上面这条链，因为其始终认为上面的链是非法的。

典型案例

2017 年因 “区块大小扩容” 争议引发的硬分叉。原比特币区块大小上限为 1MB，部分社区认为这一限制导致交易拥堵，主张将区块大小提升至 8MB。由于与另一部分社区无法达成共识，支持扩容的节点和算力分裂出去，基于原比特币区块链在特定高度分叉，形成新的加密货币 BCH，原链则继续作为比特币（BTC）存在。

软分叉
#

软分叉是对现有协议的向后兼容式修改，新规则发布后，遵循旧规则的节点仍能识别和验证遵循新规则的区块，不会导致网络永久分裂。

3. 比特币的交易

Sat, 08 Nov 2025 00:00:00 +0000

UTOX模型
#

在讲比特币交易之前，必须先理解比特币的交易模型。在比特币的交易体系中，并没有“余额”这一概念，它使用的是utxo模型（unspent transaction outputs，未使用过的交易输出）来记录用户的交易信息。我们在交易过程中经常说的钱包余额，实际上是一个钱包地址的utxo集合。所以，在比特币中，余额是实际上是别人转给你的，且未使用的额度。

这样说还是比较抽象，举个日常生活中的例子来说明，假如B、C给A分别转账20元，10元，那么用户A的钱包里有30元，这30元是A钱包里的余额。

我们将这个场景类比到比特币交易中，假如B、C给A分别转账20个比特币，10个比特币，那么用户A的钱包里有30个比特币，但这30个比特币不是直接得出来得，而是通过计算获取出来得。

当A把币花掉后，就会在utxo集合里删除。

简单来说，传统的账户系统中存在这一个余额变量，每当产生交易时都会对这个余额变量进行修改，用户想要获取余额时直接读取整个余额变量即可。但在比特币的系统中并没有这个余额变量，而是每次都通过求和自己收到并且未花的钱来获取余额（当然一些钱包软件可能会对这个余额做一些缓存）。

我们上面所说的utxo集合都是用户自己相关的utxo集合，这种数据一般会单独保存在钱包软件中。其实在全节点中我们还保留一个比特币系统中所有交易的utxo集合，用户之间的交易要通过挖矿机制同步到这个完整的utxo集合中去，这样用户之间的交易才能被同步到其他用户那里去（后续我们会逐步提到这一机制）。

为什么要使用utxo模型，相对于传统的账户模型，有什么好处？

增强隐私性：utxo模型使得交易与账户分离，增加了追踪资金流动的难度，从而保护用户身份。
可拓展性：utxo模型支持并行处理交易，提高了网络的扩展性。每个节点只需要验证自己的收到的uxto，而不需要处理整个账户的余额。
安全性：utxo模型通过验证每笔交易的输入，确保

了解了比特币得交易模型，接下来再思考讨论下比特币交易相关的一些问题。

传统的中心化交易
#

在中心化的交易系统，例如支付宝中，必须有一个中心化的数据库，其记录了用户有多少余额，这样可以确保交易的绝对准确性，不会出现一份钱花两次等问题（依赖于第三方服务，例如支付宝、微信等，保证账户的钱不会多花、漏花）。其次，货币的发行由中心化的机构（例如央行）来决定。

去中心化交易
#

在去中心化的交易系统中，并没有一个中心化的机制来帮我们保证交易的准确性，即比特币系统中任需要解决如下问题：

如何发行货币
如何解决双花攻击
如何避免冒名顶替

双花攻击
#

第一个问题后面会详细讨论，先来看下比特币中是如何解决双花攻击的。首先，每一个比特币交易都包含输入跟输出两个部分：

8. 比特币脚本

Sat, 08 Nov 2025 00:00:00 +0000

5. 比特币挖矿难度

Sat, 18 Oct 2025 00:00:00 +0000

挖矿难度
#

前面提到了挖矿是不断地调整 block header 中的nonce值，使得 hash(block_header) 的值小于等于一个目标值target。可以看出，target越小，挖矿的难度越大，他们之间是反比的关系。 $$ difficulty = \frac{difficulty1(最小挖矿难度)}{target} $$

调整挖矿难度原因
#

在比特币系统中，出块的平均时间保持在10min左右，但随着参加挖矿的人增加及设备性能的提升，系统的总算力会不断地增强，出块的时间会越来越短，挖矿的难度越来越低。实际上，在比特币系统开发过程中，中本聪便考虑到了这个问题，并设计了一个相应的难度调整算法。

出块时间太短会带来什么问题？
#

出块时间太短，会导致区块链分叉过多，不利于系统达成共识，会让各个节点处于不一致的状态，且会造成算力分散，大大降低了黑客发动51%攻击的成本。

出块时间10min是最优解吗？
#

不一定，比特币选择 10 分钟作为出块时间，是中本聪在设计时权衡多方面因素的结果，10 分钟的间隔让交易有足够时间在全网传播，同时又降低了上述分叉攻击带来的风险。但是无论如何，这个出块时间都要维持在一个稳定的值。

0. 说明

Thu, 09 Oct 2025 00:00:00 +0000

本系列文章是基于北京大学肖臻老师《区块链技术与应用》做的笔记，文章将会从多个角度来探讨区块链技术，在课程的基础上会加入自己的一些理解。文章的整体风格尽量遵循3W原则，即：

Why：为什么
How：如何做
What：是什么

本文不会做过多繁杂概念的介绍，主要内容为一些理解性的内容，概念性的东西大家可以自行google。此外笔记的顺序也不完全按照肖臻老师的课程章节顺序

另外，区块链并不等于比特币，

6. 比特币挖矿设备及矿池

Thu, 09 Oct 2025 00:00:00 +0000

全节点与轻节点
#

前面我们说过比特币的节点分为全节点和轻节点，全节点包含了区块的header及body，轻节点只包含header，下面我们详细地来对比下他们之间的异同。

	轻节点	全节点
是否一直在线	不是一直在线	一直在线
包含信息	在本地硬盘保存完整的区块信息	只保存每个区块的块头
交易信息	在内存中保存完整的utxo集合	不保存全部交易，只保存和自己有关的交易
合法性校验	监听比特币网络上的交易信息，验证每个交易的合法性	无法验证大多数交易的合法性，只能验证与自己有关的交易的合法性
打包交易	决定哪些交易会打包到区块中	无法检测网上发布的区块的正确性
合法性	监听其他矿工挖出的区块，验证其合法性	仅可以验证挖矿难度
挖矿	决定沿着哪条链挖下去&当出现等长分叉，选择哪一个分叉	只能检测哪个是最长链，不知道哪个是最扯昂合法链

比特币网络中大部分节点都是轻节点，在挖矿过程中，如果监听到别人已经挖出一个新的区块，延申了最长合法链，那么应该重新组装一个新的候选区块，重新开始挖矿。这样做是不是有些可惜？并不，因为挖矿是无记忆性的，每一次nonce值的尝试，都不会对下一次的尝试造成影响。

挖矿设备
#

挖矿设备的演化趋势是越来越趋于专业化，从普通的家用电脑，到如今的ASIC矿机。

一代设备：CPU
#

开始的时候大家用普通的家庭电脑的CPU来进行挖矿，但实际上使用家用电脑来挖矿是十分不划算的，因为在挖矿过程只用到了电脑的一部份资源，大部分内存、CPU资源都是在闲置的。如果用通用计算机来挖矿，那么挖矿很快会变得无利可图，因为性价比太低。

7. 比特币网络

Thu, 09 Oct 2025 00:00:00 +0000

比特币网络
#

上篇文章中说到用户打包交易发布到区块链网络中去，那么新发布的区块是如何传播到其他节点上去呢？

比特币网络
#

比特币协议工作在应用层，其底层是一个 P2P Overlay Network（P2P覆盖网络）。

比特币系统中所有节点完全平等，没有所谓的超级节点，要加入这个P2P网络，首先至少要知道一个种子节点，通过种子节点来获取其他节点的信息。节点之间是通过TCP协议进行通信，方便穿透防火墙。

设计原则
#

比特币网络的设计原则是简单、鲁棒，而不是高效，消息在节点中传播是使用flooding的方式，当某个节点收到消息时，会把这个消息传播个他的邻居节点，同时标记该消息已经接收过，避免重复接收消息。邻居节点的选举是随机的，并不是考虑实际的网络拓扑结构，这样做的好处是可以增强鲁棒性。

在比特币的每个节点中都要维护一个等待上链的交易集合，第一次收到交易消息，验证完其合法性后，需要将这个消息放到这个集合中，并且通知其他的邻居节点。

交易冲突
#

假设有A -> B，A -> C两笔交易（A为同一笔交易的UTXO输出），同时广播到网络上，每个节点在网络中的位置不同，有些节点可能先收到A -> B，有些节点可能先收到A -> C。

2. 比特币的数据结构

Thu, 02 Oct 2025 00:00:00 +0000

整体结构
#

比特币中的一个最基本的数据结构就是区块链，即一个一个区块组成的链表。其中，每个区块又可以分为header跟body。

header里存储这个区块的一些元信息，例如版本、时间戳等。body里则存储区块里包含的具体交易。

全节点跟轻节点
#

节点是指接入比特币网络的计算机（或设备），它们通过运行比特币客户端软件参与网络维护、数据同步和交易处理。（了解P2P的同学应该很容易理解节点）

比特币中的节点又分为全节点和轻节点，全节点指存储了整个区块的节点（包括header与body，一般为矿工节点、交易所节点等）。轻节点指仅存储区块部分数据的节点（仅header，一般为手机钱包）。后续我们会再详细述说全节点与轻节点区别，这里只要有个大致的概念即可。

哈希指针
#

前面说过区块链是由一个个区块组成的，跟普通的链表用普通指针来连接数据不一样的是，区块之间是通过哈希指针来连接区块的。

哈希指针会将前一个区块的哈希值存入当前区块中，并且使用指针指向前一个区块。

为什么需要哈希指针
#

防止区块内容被篡改

在普通的链表中，指针指向的数据是可以被修改&替换的。而比特币这样一个去中心化的系统中，区块里的数据都是一笔笔已经发生的交易，是不应该被篡改的。哈希指针在通过指针找到前一个区块的时候，会对前一个区块进行hash运算，并且与当前存储的前一个指针的hash值做对比。假如有人恶意篡改了前一个区块的数据，那么与当前存储的hash值会不一致，则证明了前一个区块被篡改。

1. 哈希与签名

Tue, 23 Sep 2025 00:00:00 +0000

什么是哈希
#

简单来说就是把任意输入通过特定方式（hash函数）处理后生成一个值。或者说，对一个数据生成其对应的摘要。

哈希特性
#

##抗碰撞性指极难找到两个输入，他们的经过哈希函数处理后的哈希值相同。

注意，这里是极难，但并非不可能（找出哈希碰撞的两个输入的代价，要远远大于碰撞带来的收益，所以这里可以近似地认为不可能）

##不可逆性简单来说，就是对于一个哈希函数，不能根据他的输出，去反推他的输入

##难题友好指哈希值的计算不可预测，仅跟据输入很难预测输出，例如：我们需要一个哈希值，存在于某一个范围内，只能通过不停运算查找出来。该性质保证了比特币系统中，只能通过“挖矿”获得比特币。

什么是签名
#

在中心化的系统中，通常有一个账号来代表用户的身份。例如支付宝中的支付系统，用户需要登录自己的账号，再输入支付密码，才能完成一笔交易。但在比特币的世界中，并没有中心化系统中的“账号”、“密码” 这一概念。那么，比特币系统是如何唯一标识用户的呢？答案就是签名。

我们通常会在写信的时候附上自己的签名，其作用是证明这封信是出自此人之手（实际并不能完全证明，签名是可以伪造的，对吧）。并且，信的内容与签名并无直接关联。

在比特币的交易中，需要对每一笔交易生成一个签名，但与写信不同，我们需要生成的签名，是根据交易内容来生成的，并且证明交易是由你发起的。

在比特币系统中，也需要一个“账号”来证明这比交易是由你本人发起的（即对这笔交易进行签名），这个“账号”就是私钥&私钥对。总之，这对密钥就代表了比特币系统中的一个账户，如果其中私钥泄露，则相当于泄露了银行卡的密码。从另一个角度看，只有用于私钥，才能对比特币进行交易，保证了交易的安全性。

这里关于公钥&私钥&签名&验签的内容不再详细赘述，有需要可以参考

pprof抓包教程

Fri, 28 Feb 2025 00:00:00 +0000

无头service

Fri, 08 Nov 2024 00:00:00 +0000

Promise详解

Thu, 26 Sep 2024 00:00:00 +0000

背景
#

在JavaScript的世界中，所有代码都是单线程执行的。由于这个“缺陷”，导致JavaScript的所有网络操作，浏览器事件，都必须是异步执行。假设有这么一个场景，在一个电商系统中，需要根据userId查询到用户购买的商品信息，其步骤如下:

查询用户服务，根据userId查询到用户信息（orderId）
查询订单服务，根据orderId查询到订单信息（productId）
查询商品服务，根据productId查询到商品信息

在ES6之前，我们只能使用回调函数来实现这个功能，其代码示例如下:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'https://api.com/user', true);
xhr.onreadystatechange = function() {
    if (xhr.readyState === 4 && xhr.status === 200) {
        console.log(xhr.responseText);
    }
};
xhr.send();

influx初学

Tue, 25 Jun 2024 00:00:00 +0000

1. introduce
#

InfluxDB是一个用于存储和分析时间序列数据的开源数据库。主要特性有：

内置HTTP接口，使用方便
数据可以打标记，这样查询可以很灵活
类SQL的查询语句
安装管理很简单，并且读写数据很高效
能够实时查询，数据在写入时被索引后就能够被立即查出
…

2. concept
#

name: census
-————————————
time                    butterflies     			honeybees     				location     			scientist
2015-08-18T00:00:00Z      12                   	23                    1                 langstroth
2015-08-18T00:00:00Z      1                     30                    1                 perpetua
2015-08-18T00:06:00Z      11                   	28                    1                 langstroth
2015-08-18T00:06:00Z   		3                     28                    1                 perpetua
2015-08-18T05:54:00Z      2                     11                    2                 langstroth
2015-08-18T06:00:00Z      1                     10                    2                 langstroth
2015-08-18T06:06:00Z      8                     23                    2                 perpetua
2015-08-18T06:12:00Z      7                     22                    2                 perpetua

其中census是measurement，butterflies和honeybees是field key，location和scientist是tag key。

measurement可以理解为表名，这里的measurement为census，可以表示为统计表。
field为列，butterflies和honeybees 都是列，称为fields，fields由field key和field value组成。field key(butterflies和honeybees)都是字符串，他们存储元数据；field key butterflies告诉我们蝴蝶的计数从12到7；field key honeybees告诉我们蜜蜂的计数从23变到22。field value就是你的数据，它们可以是字符串、浮点数、整数、布尔值，因为InfluxDB是时间序列数据库，所以field value总是和时间戳相关联。field是InfluxDB数据结构所必需的一部分——在InfluxDB中不能没有field。还要注意，field是没有索引的。如果使用field value作为过滤条件来查询，则必须扫描其他条件匹配后的所有值。因此，这些查询相对于tag上的查询（下文会介绍tag的查询）性能会低很多。一般来说，字段不应包含常用来查询的元数据。
样本数据中的最后两列（location和scientist）就是tag。 tag由tag key和tag value组成。tag key和tag value都作为字符串存储，并记录在元数据中。示例数据中的tag key是location和scientist。 location有两个tag value：1和2。scientist还有两个tag value：langstroth和perpetua。
series是共同retention policy，measurement和tag set的集合
point简单地理解为时间轴上的一个数据点，即一行数据。

3. grammar
#

读取数据 -> InfluxQL的select语句来自于SQL中的select形式：

MongoDB常用的curd操作

Mon, 10 Jun 2024 00:00:00 +0000

连接mongo
#

#连接mongo
mongo $url

#选择数据库
use $database

索引相关
#

#查询已有的索引
db.collection.getIndexes()

#创建索引
db.$collection.createIndex({$field: 1})

crud相关
#

#查询文档数量
db.$collection.countDocuments({k: v}) // mongodb >= v4.0
db.$collection.count({k: v}) // mongodb < v4.0
 
#查询文档
db.$collection.find({k: v})
db.$collection.find({"$and": [{k1: v1}, {k2: v2}]})
db.collection.find({
  upload_type: 3,
  $or: [
    { 'audit_record.label': '正常' },
    { 'audit_record.label': '轻度违规' }
  ]
}).limit(3).pretty();

#删除文档
db.$collection.deleteOne({k: v})
db.$collection.deleteMany({k: v})

#新增文档

#更新文档

#获取索引
db.$collection.getIndexes();

重学prometheus

Wed, 05 Jun 2024 00:00:00 +0000

1. 数据是如何存储的
#

无论是哪种metrics类型，prometheus在底层都会将所有采集到的样本数据以时间序列的方式存储在内存数据库中，并定时保存到硬盘上。如下图，可以理解为一个以时间为X轴的数字矩阵:

  ^
  │   . . . . . . . . . . . . . . . . .   . .   node_cpu_seconds_total{cpu="cpu0",mode="idle"}
  │     . . . . . . . . . . . . . . . . . . .   node_cpu_seconds_total{cpu="cpu0",mode="system"}
  │     . . . . . . . . . .   . . . . . . . .   node_load1{}
  │     . . . . . . . . . . . . . . . .   . .
  v
    <------------------ 时间 ---------------->

如图，横轴为即时间，矩阵中的点称为一个样本，样本由以下三个部分组成:

Golang之系统排查

Thu, 12 Oct 2023 00:00:00 +0000

系统排查
#

1. 先确定出现问题的进程
#

先排查是否因为程序服务导致的CPU/内存保障，可以使用top命令来排查。

top

确定是服务出问题后，可以使用如下命令持续监测服务进程，$pid即为服务进程的pid。

top -Hp $pid

可以使用top默认根据CPU使用率来排序，可以使用shitft + m 改成使用内存占用率来排序。

2. 使用PProf排查程序内部的问题
#

确定了服务进程的问题后，就可以通过PProf来排查CPU、内存、互斥锁、Goroutines的问题了。下面展示一个demo来简单使用PProf。

import (
	"log"
	"net/http"
	"time"
	_ "net/http/pprof" 
)


func main() {
	go func() {
		for {
			log.Println("do something...")
			time.Sleep(time.Second )
		}
	}()

	_ = http.ListenAndServe("0.0.0.0:6060", nil) //pprof包的init函数里注册了handler 
}

使用web界面查看pprof信息
#

经过上述步骤后，在浏览器打开http://127.0.0.1:6060/debug/pprof/，就能看到pprof界面了。

Golang之内存管理

Mon, 10 Apr 2023 00:00:00 +0000

Golang之内存管理
#

概述
#

Go的内存分配借鉴了Google的TMalloc，其核心思想是内存池+多级对象管理，能加快分配速度，降低资源竞争。

内存分配的方法
#

线性分配法：只需要在内存中维护一个指针，这个指针指向下一片未使用内存的起始位置，如果程序需要新分配一片内存，只要找到这个指针直接分配内存即可。
这种方法实现虽然简单，但有一个致命的缺点，就是无法利用曾经使用过但后面被释放的内存。
空闲链表分配法：会在内部维护一个类似链表的数据结构，当程序需要申请内存时，空闲链表分配器会一次遍历空闲的内存块，找到足够大的内存，然后申请新的资源并修改链表。

Go使用的是空闲链表分配法，再配合隔离适应策略，将内存分割成多个链表，每个链表中内存块大小相等，申请内存时先找到合适的链表，再在链表中找到合适的内存块。

基础结构
#

内存单元相关：mspan、arena
内存池相关：mcache、mcentral、mheap

内存单元
#

首先，在Go程序初始化时，会先将申请到的虚拟内存分为如下几个部分。

Golang之内存逃逸

Mon, 10 Apr 2023 00:00:00 +0000

Golang之内存逃逸
#

内存分配
#

在Golang中，程序申请的一个对象，是在栈上分配，还是在堆上分配，这个是由编译器决定的。

在栈上分配：在程序中，每个函数块都会有自己的内存区域来存储局部变量、返回值等数据，这一块内存区域有特定的数据结构与存储方式，其大小在程序编译的时候就已经分配好了，且这块区域寻址快，开销少，这块内存区域就称为栈区。因为栈的大小在编译的时候就已经确定了，所以当栈存储的数据过大时，会发生“栈溢出”。
在堆上分配：在程序中，全局变量，内存占用大的局部变量，发生了内存逃逸的局部变量就分配在堆上，这一块内存区域没有特定的结构，也没有固定的大小，可以根据需要进行调整。当一个变量分配在堆上的时候，开销会比较大，对Golang这种自带GC的语言来说，会增加GC压力，同时也会带来内存碎片。

内存逃逸
#

在计算机语言编译器优化原理中，逃逸分析是指分析指针动态范围的方法，它同编译器优化原理的指针分析和外形分析相关联。当变量（或者对象）在方法中分配后，其指针有可能被返回或者被全局引用，这样就会被其他过程或者线程所引用，这种现象称作指针（或者引用）的逃逸（Escape）。

Golang中的内存逃逸
#

在Golang中可以使用go run -gcflags “-m -l” (-m打印逃逸分析信息，-l禁止内联编译)来分析内存逃逸。使用如下代码来分析内存逃逸：

func foo() *int {
    i := 10
    return  &i
}

func main() {
    a := *foo()
    _ = a
}

执行结果如下：

Oauth2.0

Tue, 28 Mar 2023 00:00:00 +0000

cat Oauth2.0
#

简介
#

OAuth2.0协议是一个开放标准，允许用户授权第三方程序访问他们存储在另外的服务提供者上的信息，而不需要将用户和密码提供给第三方应用或分享他们数据的所有内容。

运用场景
#

几乎每个人在使用一个APP或网页应用的时候都看过他们支持第三方登录比如微信登录、 QQ 登录、微博登录、 Google 账号登录、github 授权登录等等。这些都是典型的 OAuth2 使用场景。

授权流程
#

这里以网页应用微信授权登录为例。

准备工作
#

在进行微信OAuth2.0授权登录接入之前，在微信开放平台注册开发者帐号，并拥有一个已审核通过的网站应用，并获得相应的 AppID 和AppSecret，申请微信登录且通过审核后，可开始接入流程。

NSQ设计

Mon, 27 Mar 2023 00:00:00 +0000

nsq
#

NSQ是实时的分布式消息处理平台，其设计的目的是用来大规模地处理每天数以十亿计级别的消息。NSQ具有分布式和去中心化拓扑结构，该结构具有无单点故障、故障容错、高可用性以及能够保证消息的可靠传递的特征，是一个成熟的、已在大规模生成环境下应用的产品。

组成
#

NSQ由三个守护进程够成：

nsqd：用于接收保存和传送消息到客户端的守护进程。
nsqlookupd：是管理拓扑信息，维护着所有的nsqd的状态，并提供最终一致发现服务的守护进程。
nsqadmin：一个 Web UI 来实时监控集群和执行各种管理任务。

概念
#

topic：生产者将消息写入topic中，一个topic下可以有多个channel，每个channel都是topic完整的副本。
channel：消费者从channel处订阅消息，如果有多个消费者订阅同一个channel，那么channel中的消息会被随机传递到其中的一个消费者上。

Golang之内存泄漏

Sat, 18 Mar 2023 00:00:00 +0000

Golang之内存泄漏
#

内存泄漏
#

内存泄漏说白了就是分配的内存(或者变量)不再使用，但是并没有被gc回收，而是继续占用内存。在Golang中内存泄漏大部分都跟channel的不正确使用有关。泄漏的原因是goroutine操作channel后，处于发送阻塞或者接收阻塞状态，而channel处于满或者空的状态，一直得不到改变。同时，垃圾回收器也不会回收此类资源，进而导致goroutine会处于一个一直等待的队列中，不见天日。

场景分析
#

案例1: channel没有接收者
#

下面这段程序展示了并发地向3个站点请求资源，接收者只接收最快返回的那个。

func goroutineLeak1() string {
	responses := make(chan string) //正确姿势：responses := make(chan string, 3)
  //3个发送者
	go func {responses <- request("asia.gopl.io")}()
	go func {responses <- request("europe.gopl.io")}()
	go func {responses <- request("americas.gopl.io")}()
  //1个接收者
	return <- responses
}

goroutineLeak1能正确地接收到最快返回的站点资源，但两个慢的goroutien会因为没有人接收而永远卡住，造成这两个goroutine永远没法被回收。正确的姿势是创建一个带3个buffer的channel，可以回收两个返回比较慢的goroutine。

系统与网络排查工具

Tue, 14 Mar 2023 00:00:00 +0000

Mongodb架构设计

Fri, 10 Mar 2023 00:00:00 +0000

Mongodb
#

1. 简介
#

MongoDB 是一个基于分布式文件存储的数据库。它具有开源、高性能、无模式等优点，由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。MongoDB支持的数据结构类似于JSON，叫做 BSON，所以它既可以存储比较复杂的数据类型，又相当的灵活。

2. 关系型与非关系型数据库
#

3. 高可用架构
#

高可用性 HA（High Availability）指的是缩短因正常运维或者非预期故障而导致的停机时间，提高系统可用性。

Kafaka之简介

Thu, 09 Mar 2023 00:00:00 +0000

Kafaka简介
#

1. 简介
#

Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用与大数据实时处理领域。其主要设计目标如下：

以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
高吞吐率。即使在非常廉价的机器上也能做到单机支持每秒100K条消息的传输。
支持消息分区及分布式消费，同时保证每个partition内的消息顺序传输，同时支持离线数据处理和实时数据处理

2. 组件
#

Broker：一台 Kafka 机器就是一个 Broker。一个集群是由多个 Broker 组成的且一个 Broker 可以容纳多个 Topic。
Topic：可以简单理解为队列，Topic 将消息分类，生产者和消费者面向的都是同一个 Topic。
Producer：即消息生产者，向 Kafka Broker 发消息的客户端。
Consumer Group：即消费者组，消费者组内每个消费者负责消费不同分区的数据，以提高消费能力。一个分区只能由组内一个消费者消费，不同消费者组之间互不影响。
Partition：为了实现Topic扩展性，提高并发能力，一个非常大的 Topic 可以分布到多个 Broker 上，一个 Topic 可以分为多个 Partition 进行存储，每个 Partition 是一个有序的队列。
Replica：即副本，为实现数据备份的功能，保证集群中的某个节点发生故障时，该节点上的 Partition 数据不丢失，且 Kafka 仍然能够继续工作，为此Kafka提供了副本机制，一个 Topic 的每个 Partition 都有若干个副本，一个 Leader 副本和若干个 Follower 副本。我们的 Producer 端在发送数据的时候，只能发送到Leader Partition里面，然后Follower Partition会去Leader那自行同步数据, Consumer 消费数据的时候，也只能从 Leader 副本那去消费数据的。
Leader：即每个分区多个副本的主副本，生产者发送数据的对象，以及消费者消费数据的对象，都是 Leader。
Offset：消费者消费的位置信息，监控数据消费到什么位置，当消费者挂掉再重新恢复的时候，可以从消费位置继续消费。
ZooKeeper服务：Kafka 集群能够正常工作，需要依赖于 ZooKeeper，ZooKeeper 帮助 Kafka 存储和管理集群元数据信息。在最新版本中, 已经慢慢要脱离 ZooKeeper。
Controller: 其实就是一个 Kafka 集群中一台 Broker。它除了具有普通Broker 的消息发送、消费、同步功能之外，还需承担一些额外的工作。Kafka 使用公平竞选的方式来确定 Controller ，最先在 ZooKeeper 成功创建临时节点 /controller 的Broker会成为 Controller ，一般而言，Kafka集群中第一台启动的 Broker 会成为Controller，并将自身 Broker 编号等信息写入ZooKeeper临时节点/controller。

3. 集群架构
#

![640 (6)](http://storage.chuckchan.top/uploads/640 (6).png)

GPM<4>-场景分析

Wed, 08 Mar 2023 00:00:00 +0000

GPM<4>场景分析
#

场景分析
#

场景一: 创建/执行G
#

当某个G1创建一个新的G2时：

1.运行一个G

2.当本地队列未满，则直接加入本地队列(满足局部性)

3.如果本地队列已满，则将P1本地队列中的前一半(G3/G4)+G7顺序打乱，一同放到全局队列中去。

场景二: 唤醒正在休眠的M
#

当创建一个G时，会尝试唤醒M的休眠队列，假定G2唤醒了M2，M2绑定了P2，此时P2本地队列里没有G，M2此时为自旋线程（没有G可以运行，不断地寻找可运行的G）。自旋线程的存在是为了通过短期的自旋来防止线程被销毁。但过多的自旋线程会白白浪费CPU，所以结合两种情况，系统中最多存在GOMAXPROCS个自旋线程。

场景三: 被唤醒的M从全局队列取G
#

在场景二中被唤醒的M会从全局队列取出n个G来运行，n的计算法则：n = min(len(GQ)/GOMAXPROCS + 1, len(GQ/2))，至少从全局队列取1个G，但每次不要从全局队列移动太多的G到P本地队列，这是从全局队列到P本地队列的负载均衡。

熔断与限流

Wed, 08 Mar 2023 00:00:00 +0000

微服务限流
#

限流顾名思义，就是对请求或并发数进行限制；通过对一个时间窗口内的请求量进行限制来保障系统的正常运行。如果我们的服务资源有限、处理能力有限，就需要对调用我们服务的上游请求进行限制，以防止自身服务由于资源耗尽而停止服务。在限流中有两个概念需要了解：

阈值：在一个单位时间内允许的请求量。如 QPS 限制为10，说明 1 秒内最多接受 10 次请求。
拒绝策略：超过阈值的请求的拒绝策略，常见的拒绝策略有直接拒绝、排队等待等。

1. 固定窗口算法
#

固定窗口算法又叫计数器算法，是一种简单方便的限流算法。主要通过一个支持原子操作的计数器来累计 1 秒内的请求次数，当 1 秒内计数达到限流阈值时触发拒绝策略。每过 1 秒，计数器重置为 0 开始重新计数。

Golang之gin源码分析

Tue, 07 Mar 2023 00:00:00 +0000

gin
#

gin是一个用Go语言编写的web框架。

demo
#

package main

import "github.com/gin-gonic/gin"

func main() {
    r := gin.Default()
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "message": "pong",
        })
    })
    r.Run()
}

流程分析
#

以下分析基于：

github.com/gin-gonic/gin v1.5.0

1. 创建Engin
#

Engin即引擎，Engin是 Web Server 的基础支持，也是服务的入口和根级的数据结构。下面是Engin的定义。

Golang之slice

Tue, 07 Mar 2023 00:00:00 +0000

slice
#

简介
#

本文旨在讲解slice的数据结构及扩容策略，以下内容基于：

go version go1.16.2 darwin/amd64

slice数据结构
#

type slice struct {
	array unsafe.Pointer  //指向底层数组的指针
  len   int   //slice的长度 len(s)的返回值 for range 遍历slice的话也是以这个为终点
  cap   int   //slice的容量 cap(s)的返回值
}

slice扩容策略
#

可以使用append函数给slice添加元素

pod流程状态

Tue, 07 Mar 2023 00:00:00 +0000

pod状态分析
#

1. 一个pod的状态之旅
#

从宏观的角度上来看，pod的一生要经历以下5个状态：

Pending：Pod被K8s创建出来后，起始于Pending阶段。在Pending阶段，Pod将经过调度，被分配至目标节点开始拉取镜像、加载依赖项、创建容器。
Running：当Pod所有容器都已被创建，且至少一个容器已经在运行中，Pod将进入Running阶段。
Succeeded：当Pod中的所有容器都执行完成后终止，并且不会再重启，Pod将进入Succeeded阶段。
Failed：若Pod中的所有容器都已终止，并且至少有一个容器是因为失败终止，也就是说容器以非0状态异常退出或被系统终止，Pod将进入Failed阶段。
Unkonwn：因为某些原因无法取得 Pod 状态，这种情况Pod将被置为Unkonwn状态。

一般来说，对于Job类型的负载，Pod在成功执行完任务之后将会以Succeeded状态为终态。而对于Deployment等负载，一般期望Pod能够持续提供服务，直到Pod因删除消失，或者因异常退出/被系统终止而进入Failed阶段。

2. pod的异常场景
#

上面从宏观角度上介绍了pod的几种状态，但pod还有一些细分的状态如：Ready/NotReady、Initialized、 PodScheduled/Unschedulable 等等。这些细分状态描述造成Pod所处阶段的具体成因是什么。比如，Pod 当前阶段是Pending，对应的细分状态是 Unschedulable，这就意味着Pod调度出现了问题。

与此同时，容器也有自己的生命周期：Waiting、Running和 Terminated，并且也有其对应的状态原因（Reason），例如ContainerCreating、Error、OOMKilled、CrashLoopBackOff、Completd等。而对于发生过重启或终止的容器，上一个状态（LastState）字段不仅包含状态原因，还包含上一次退出的状态码（Exit Code）。例如容器上一次退出状态码是137，状态原因是OOMKilled，说明容器是因为OOM被系统强行终止。在异常诊断过程中，容器的退出状态是至关重要的信息。

Pod在其生命周期的许多时间点可能发生不同的异常，按照Pod容器是否运行为标志点，我们将异常场景大致分为两类：

在pod进行调度并创建容器的过程中发生异常，此时pod将卡在pending阶段。
在pod容器运行中发生异常，此时pod按照具体的场景处于不同的阶段。

具体场景分析：

一致性哈希

Mon, 06 Mar 2023 00:00:00 +0000

一致性hash
#

如何分配请求
#

当数据库的量太大时，可能会考虑分库分表，当分库分表之后，那就需要考虑对应的数据如何存储的问题。这里以用户库分表为例。当一个获取用户信息的请求过来，如何根据user_id去对应的表找对应的用户信息？

其实不仅是分库分表，在一些负载均衡中间件里，也有同样的问题（比如利用用户ip来决定请求流量往哪个服务器走）。

普通哈希
#

很容易想到，解决请求如何分配的一个解决方法就是将sharding_key哈希，得到hash值后对节点数进行取模运算。获取节点的公式即为：

hash(key) % num_of_nodes

还是以用户表为例子，假设有将用户表分成三个表，分别是user_table_1，user_table_2，user_table_3。具体计算流程如图所示。

普通哈希的方法根据user_id定位到具体的表，这样看似是解决了问题，但是如果用户量突然增长，需要再加一张表时，原先的表数量将由3变成4，sharding的计算方式也变hash(user_id)%4，并且需要进行大量的数据迁移。

要解决这个问题，需要对user表的数据重新按照节点4进行迁移，坏情况下所有数据都需要迁移，所以它的数据迁移规模是 O(M)，这样数据的迁移成本太高了。

一致性哈希
#

一致性哈希可以解决我们当节点变化时数据迁移量太大的问题。**一致性哈希的也是用取模的方法，但它不是对节点数取模，而是对2^64-1取模。**一致性哈希将哈希值对2^64-1所有的结果组织成一个圆环，称为哈希环。

web安全

Thu, 02 Mar 2023 00:00:00 +0000

web安全
#

1. CSRF攻击
#

CSRF是跨站请求伪造的缩写，也被称为XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。**因为CSRF攻击利用的是冲着浏览器分不清发起请求是不是真正的用户本人。**也就是说，简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

a. CSRF的基本攻击原理
#

用户Alice登录和访问某银行网站A，保留cookie。
Alice被某些信息诱导访问危险网站B。
危险网站B上有一个<img>标签：
这个标签的src不指向一张图片，而是一个http请求，这个请求向银行要求将Alice的1000元转给Badman，由于Alice的浏览器上有cookie，这样浏览器发出的这个请求就能得到响应执行。
这样Alice的钱就被偷了。

b. CSRF的防范
#

黑客仅仅靠CSRF发起攻击，他只能借助受害者的cookie骗取服务器的信任，但是黑客并不能凭借拿到cookie，也看不到 cookie的内容。这就告诉我们，我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行csrf的保护。而保护的关键，是 在请求中放入黑客所不能伪造的信息。

Kafaka之数据消费

Wed, 01 Mar 2023 00:00:00 +0000

kafaka之消费数据
#

消费方式
#

我们知道消息队列一般有两种实现方式,(1)Push(推模式) (2)Pull(拉模式)，那么 Kafka Consumer 究竟采用哪种方式进行消费的呢？其实 Kafka Consumer 采用的是主动拉取 Broker 数据进行消费的即 Pull 模式。

推模式： Push 模式最大缺点就是 Broker 不清楚 Consumer 的消费速度，且推送速率是 Broker 进行控制的，这样很容易造成消息堆积，如果 Consumer 中执行的任务操作是比较耗时的，那么 Consumer 就会处理的很慢，严重情况可能会导致系统 Crash。
拉模式：如果选择 Pull 模式，这时 Consumer 可以根据自己的情况和状态来拉取数据, 也可以进行延迟处理。但是如果 Kafka Broker 没有消息，这时每次 Consumer 拉取的都是空数据, 可能会一直循环返回空数据。针对这个问题，Consumer 在每次调用 Poll() 消费数据的时候，顺带一个 timeout 参数，当返回空数据的时候，会在 Long Polling 中进行阻塞，等待 timeout 再去消费，直到数据到达。

消费者组
#

为什么 Kafka 要设计 Consumer Group, 只有 Consumer 不可以吗？ 我们知道 Kafka 是一款高吞吐量，低延迟，高并发, 高可扩展性的消息队列产品，那么如果某个 Topic 拥有数百万到数千万的数据量，仅仅依靠 Consumer 进程消费，消费速度可想而知，所以需要一个扩展性较好的机制来保障消费进度，这个时候 Consumer Group 应运而生， Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。 Kafka Consumer Group 特点如下:

k8s组件

Mon, 27 Feb 2023 00:00:00 +0000

k8s组件
#

1. 控制平面与工作节点
#

一组工作机器，称为节点，节点会运行容器化的应用程序。整个k8s集群由控制平面（master节点）与worker节点构成。

控制平面的组件用来存储、管理集群状态，其中包括：

etcd分布式持久化存储
API服务器
调度器
控制器管理器

而运行容器的任务依赖千每个工作节点上运行的组件：

Kubelet
Kubelet服务代理( kube-proxy)
容器运行时(Docker、rkt或者其他）

出了这些组件外，还有一些附加组件，他们共同构成了整个k8s集群。

Kubemetes DNS服务器
仪表板
Ingress控制器
Heapster (容器集群监控）
容器网络接口插件

整体构造入下图所示：

可以使用如下命令来查看当前k8s集群的组件状态：

kubect1 get componentstatuses

2. 组件分析
#

2.1 etcd
#

负责存储集群中各种资源对象的信息，k/v方式存储，所有的 k8s 集群数据存放在此

MySQL之explain

Mon, 27 Feb 2023 00:00:00 +0000

Explain
#

简介
#

MySQL 提供了一个 EXPALIN 命令，可以用于对 SELECT 语句 的执行计划进行分析，并详细的输出分析结果，供开发人员进行针对性的优化。

字段介绍
#

id: SELECT查询序列号，即为sql语句执行的顺序
select_type: SELECT的类型，他有以下几种类型：
- simple: 最简单的select，表示没有union与子查询
- primary: 在有子查询的语句中，外面的那一层select即为primary
- union: union查询语句的第二个语句，即为union
- union result: union语句的结果
table: 所用到的表
type: 连接类型，后面再详细介绍
possible_keys: 可能使用到的索引
key: 实际选择的索引
key_len: 使用的索引长度
ref: 索引的哪一列被使用了
rows: 估计要扫描的行，数字越大select的效率越低
extra: 额外信息，后面再详细介绍

type详解
#

type表示SQL语句对表的访问方式（MySQL在表中找到所需行的方式），又称访问类型，通常用type的值来判断SQL语句是否使用到索引。type的值有以下几种，由好到差依次是：

Golang之GC

Thu, 23 Feb 2023 00:00:00 +0000

Golang之GC
#

为什么要有GC
#

当程序启动的时候，操作系统会给程序分配堆区与栈区，栈区里的内存是可以自动管理的，当栈区变量的作用域结束，可以被自动收回。堆区属于程序员自己管理的区域，即使堆区变量的作用域结束，后续可能继续使用。所以对于堆区的内存，程序员需要实时关注，如果内存一直增长没有释放，则会溢出，如果内存释放后还继续访问，则会出现非法访问。那有没有一种机制能够让堆区的闲置的内存自动回收？GC可以帮我们做到。GC(Ggrbage Collect)即垃圾回收，它可以通过一定的策略，让程序自动管理内存，让开发者更增加专注业务的开发。

GC常用的策略
#

引用计数法。引用计数法为对象维护一个计数器，当对象被引用时，计数器加1，引用被释放，计数器减1，当计数器为0时，表示没有被引用，清除这个对象。引用计数法实现简单，但频繁更新计数器会带来一定开销，且无法解决循环引用的弊端。
标记-清除法。标记-清除法是对对象定时进行标记，标记为“正在使用”与“没有被使用”两种，标记完后对标记为“没有被使用”的进行清除。由于程序是动态在运行的，随时有可能改变对象引用指向，因此，在标记的时候需要STW(Stop The World)，即程序停止一段时间，这段时间专门用来做标记。

Golang中的GC策略
#

Golang在v1.5之前是使用清除-标记法的策略进行GC，但v1.5使用了三色标记法，所谓三色标记法就是通过三个阶段来去定对象的状态（黑色/白色/灰色分别代表三个不同的状态）。

白色：初始对象
灰色：要被清除的对象
黑色：任然在使用的对象

1.创建新对象，全部为白色

Etcd

Wed, 22 Feb 2023 00:00:00 +0000

etcd
#

etcd是CoreOS基于Raft协议开发的分布式key-value存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）。

简单：curl可访问的用户的API（HTTP + JSON）
安全：可选的SSL客户端证书认证
快速：单实例每秒1000次写操作
可靠：使用Raft算法保证一致性

架构
#

Client层：client层包括client v2和v3两个⼤版本API客⼾端库，提供了简洁易⽤的API，同时⽀持负载均衡、节点间故障⾃动转移，可极⼤降低业务使⽤etcd复杂度，提升开发效率、服务可⽤性。
API网络层：API⽹络层主要包括client访问server和server节点之间的通信协议。⼀⽅⾯，client访问etcd server的API分为v2和v3两个⼤版本。v2 API使⽤HTTP/1.x协议，v3 API使⽤gRPC协议。同时v3通过etcd grpc-gateway组件也⽀持HTTP/1.x协议，便于各种语⾔的服务调⽤。另⼀⽅⾯，server之间通信协议，是指节点间通过Raft算法实现数据复制和Leader选举等功能时使⽤的HTTP/2协议。
Raft算法层：Raft算法层实现了Leader选举、⽇志复制、ReadIndex等核⼼算法特性，⽤于保障etcd多个etcd是典型的读多

节点间的数据⼀致性、提升服务可⽤性等，是etcd的基⽯和亮点。
功能逻辑层：etcd核⼼特性实现层，如典型的KVServer模块、MVCC模块、Auth鉴权模块、Lease租约模块、Compactor压缩模块等，其中MVCC模块主要由treeIndex模块和boltdb模块组成。
存储层：存储层包含预写⽇志(WAL)模块、快照(Snapshot)模块、boltdb模块。其中WAL可保障etcd crash后数据不丢失，boltdb则保存了集群元数据和⽤⼾写⼊的数据。

读取数据
#

etcd有两种读取数据的模式，分别是串行读与线性读，其中线性读是默认的读取方式。再说读取数据之前先简单说明下写的流程。当client发起⼀个更新hello为 world请求后，若Leader收到写请求，它会将此请求持久化到WAL⽇志，并⼴播给各个节点，若⼀半以上节点持久化成功，则该请求对应的⽇志条⽬被标识为已提交，etcdserver模块异步从Raft模块获取已提交的⽇志条⽬，应⽤到状态机(boltdb等)。

GeoHash算法

Wed, 22 Feb 2023 00:00:00 +0000

GeoHash
#

背景
#

经纬度是经度与纬度的合称组成一个坐标系统，称为地理坐标系统，它是一种利用三度空间的球面来定义地球上的空间的球面坐标系统，能够标示地球上的任何一个位置。

GeoHash
#

GeoHash是空间索引的一种方式，其基本原理是将地球理解为一个二维平面，通过把二维的空间经纬度数据编码为一个字符串，可以把平面递归分解成更小的子块，每个子块在一定经纬度范围内拥有相同的编码。简单地说就是将二维的坐标转换成一维坐标，从而提高对位置数据的检索效率。

编码规则
#

先将纬度范围(-90, 90)平分成两个区间(-90, 0)和(0, 90)，如果目标维度位于前一个区间，则编码为0，否则编码为1，然后根据目标纬度所落的区间再平均分成两个区间进行编码，以此类推，直到精度满足要求，经度也用同样的算法，对(-180, 180)依次细分，然后合并经度和纬度的编码，奇数位放纬度，偶数位放经度，组成一串新的二进制编码，按照Base32进行编码。

编码示例
#

以经纬度值：（116.389550， 39.928167）进行算法说明，对纬度39.928167进行逼近编码 (地球纬度区间是[-90,90]）

Golang之channel源码分析

Mon, 20 Feb 2023 00:00:00 +0000

Golang之channel源码分析
#

1. channel
#

channel是支撑Go语言高性能并发编程模型的重要结构，channel是一个用于同步和通信的有锁环形队列，使用互斥锁解决程序中可能存在的线程竞争问题。以下内容基于：

go version go1.16.2 darwin/amd64

2. channel的数据结构
#

channel其是用runtime.hchan来表示的。

type hchan struct {
	qcount   uint           // 缓冲区buffer里有几个元素
	dataqsiz uint           // 缓冲区buffer最多有几个元素 即缓冲区大小
	buf      unsafe.Pointer // 指向底层循环数组的指针
	elemsize uint16         // 元素大小
	closed   uint32        // 是否关闭
	elemtype *_type        // 元素的类型
	sendx    uint         // 已发送元素在环形数组中的索引
	recvx    uint         // 已接收元素在环形数组中的索引
	recvq    waitq        // 等待接收的goroutine队列
	sendq    waitq        // 待发送的goroutine队列
    
	lock mutex            //锁 保护数据
}

recvq与sendq是waitq类型的数据，分别代表接受的g队列与发送的g队列，waitq是一个双端链表。

设计模式之简介

Mon, 20 Feb 2023 00:00:00 +0000

设计模式
#

简介
#

什么是设计模式？

“软件设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解并且保证代码可靠性。”

一句大白话可以总结：“在一定环境下，用固定套路解决问题。”

分类
#

常用的设计模式共有23种，其中包括：

创建型(Creational)模式：如何创建对象；
1. 单例模式
2. 简单工厂模式
3. 工厂方法模式
4. 抽象工厂模式
结构型(Structural )模式：如何实现类或对象的组合；
1. 代理模式
2. 装饰模式
3. 适配器模式
4. 外观模式
行为型(Behavioral)模式：类或对象怎样交互以及怎样分配职责。
1. 模版方法模式
2. 命令模式
3. 外观模式
4. 观察者模式

原则
#

名称	定义
单一职责原则	类的职责单一，对外只提供一种功能，而引起类变化的原因都应该只有一个。
开闭原则	类的改动是通过增加代码进行的，而不是修改源代码。
里氏代换原则	任何抽象类（interface接口）出现的地方都可以用他的实现类进行替换，实际就是虚拟机制，语言级别实现面向对象功能。
依赖倒转原则	依赖于抽象(接口)，不要依赖具体的实现(类)，也就是针对接口编程。
接口隔离原则	不应该强迫用户的程序依赖他们不需要的接口方法。一个接口应该只提供一种对外功能，不应该把所有操作都封装到一个接口中去。
合成复用原则	如果使用继承，会导致父类的任何变换都可能影响到子类的行为。如果使用对象组合，就降低了这种依赖关系。对于继承和组合，优先使用组合。
迪米特法则	一个对象应当对其他对象尽可能少的了解，从而降低各个对象之间的耦合，提高系统的可维护性（黑盒原理）

Golang之boltdb源码分析

Wed, 15 Feb 2023 00:00:00 +0000

blotdb
#

1. 简介
#

boltdb是一个纯go编写的支持事务的文件型单机kv数据库。 其具有以下特点：

单机部署：不需要考虑CAP
支持事物：仅允许多个只读事务和最多一个读写事务同时运行
索引结构：因为是kv型的数据库，所以天然地只有主键索引（B+树实现），减少了磁盘IO
缓存管理：仅管理写缓存，利用mmap管理读缓存

2. 核心数据结构分析
#

先从介绍一下bolt使用的一些底层的数据结构。

db
page
node
bucket
cursor

1. db
#

在boltdb中，它的数据全部都是存储在文件上，一个db对应一个真实的磁盘文件。

Golang之context源码分析

Wed, 15 Feb 2023 00:00:00 +0000

Golang之context源码分析
#

Context是什么
#

Context是Golang中独特的数据结构，可以用来设置截至日期、同步信号、传递请求相关值，总地来说就是在goroutine构成的树形结构中对信号进行同步以减少计算资源的浪费。以下内容基于：

go version go1.16.2 darwin/amd64

Context的数据结构
#

Context是一个接口，来看下它的接口定义

type Context interface {

	//Deadline方法是获取设置的截至时间，到了这个截至时间，
	//Context会自动发起取消，第二个返回值ok代表是否有设置
	//截至时间
 	Deadline() (deadline time.Time, ok bool) 

 	//Done方法返回一个只读的chan，当这个chan收到消息时代
 	//表Parent Context已经发起了取消请求，当前goroutine
 	//要开始做清理操作了
	Done() <-chan struct{} 

	//Err返回Context被取消的原因
	Err() error

	//Value方法返回Context绑定的对应的key的值，这个是线程安全的
	Value(key interface{}) interface{}
}

context包提供了6种创建Context的方法。每个方法都会返回一种类型的结构体，这些结构体都实现了Context接口。

Golang之map源码分析

Wed, 15 Feb 2023 00:00:00 +0000

Golang之map源码分析
#

哈希表
#

map即哈希表，也称为散列表，是根据关键码值(key value)而直接进行访问的数据结构。也就是说，它通过把关键码值映射（哈希函数）到表中一个位置来访问记录，以加快查找的速度。

哈希碰撞
#

哈希函数是整个哈希表的关键。所以为了更好的性能，我们希望在尽可能短的时间内，相同的key经过哈希函数的计算，可以得到相同的索引，不同的key经过哈希函数的计算，可以得到不同的索引，但在实际中往往事与愿违，不同的key小概率会计算出相同的索引，这就是哈希冲突（collision），几乎所有的哈希函数都存在这个问题。常见的解决哈希冲突的方法有：

开放寻址法：开放寻址法是如果通过哈希函数计算出的key所对应的空间已经被占用了，就从数组尾部再找一个还没被占用的空间将数据存进去。
拉链法：实现拉链法一般会使用数组加上链表，数组的每个索引位置装的是一个链表，当发生hash冲突时，将新的kv挂在这个链表的尾部。

版本
#

以下内容基于：

go version go1.16.2 darwin/amd64

map的数据结构
#

Golang里map由runtime.hmap实现。

Golang之sync.Once源码分析

Wed, 15 Feb 2023 00:00:00 +0000

Golang之sync.Once源码分析
#

sync.Once简介
#

sync.Once 是 Go 语言实现的一种对象，用来**保证某种行为只会被执行一次。**sync.Once通常用来实现单例模式的初始化。

源码分析
#

以下内容基于：

go version go1.16.2 darwin/amd64

sync.Once结构

type Once struct {
	done uint32  //用来表示是否已经执行 0-未执行 1-以执行
	m    Mutex   //互斥锁
}

Sync.Once只提供了一个Do的方法。

func (o *Once) Do(f func()) {
  // 一种错误的方式是使用cas锁 atomic.CompareAndSwapUint32
	//	if atomic.CompareAndSwapUint32(&o.done, 0, 1) {
	//		f()
	//	}
  // cas锁虽然保证了原子操作，但可能会出现Do里的流程还没执行完就返回的情况
  // 比如：A号groutine先执行了cas操作，将o.done改为1，然后执行Do流程，B号goroutine
  // 也执行cas操作，发现o.done已经为1了，直接返回，但这时Do流程可能还未执行完！sync.Once
  // 是要保证函数返回后Do流程一定是执行完的，所以这违反了它设计的原则。

	if atomic.LoadUint32(&o.done) == 0 { //如果 o.done==1 则说明方法已执行 直接返回 
		// 如果是0 说明还未执行 进入执行doSlow流程（注意！！！这里可能有好几个goroutine进入这里去执行）
		o.doSlow(f)
	}
}

once.doSlow是正真执行Do流程的函数。

延迟队列

Wed, 15 Feb 2023 00:00:00 +0000

延迟队列
#

定义
#

队列是一种FIFO的数据结构，即先进队的数据先出队。延时队列相对于普通队列的来说，最大的区别在于他的延迟属性。延迟队列在入队的时候会指定一个延迟时间，表示其希望在经过改指定时间后处理这个任务。从某种意义上来讲，延迟队列的结构并不像一个队列，而更像一种以时间为权重的有序堆结构。

应用场景
#

在淘宝、京东等购物平台上下单，15分钟内未付款，订单会自动取消。
打车的时候，在规定时间没有车主接单，平台会取消你的单并提醒你暂时没有车主接单。
点外卖的时候，如果商家在10分钟还没接单，就会自动取消订单。
收快递的时候，如果我们没有点确认收货，在一段时间后程序会自动完成订单。
在平台完成订单后，如果我们没有在规定时间评论商品，会自动默认买家不评论。

如何实现
#

如果是数据量较小且时实时性不高的场景，可以使用轮询的方式，比如每秒轮询数据库的所有数据，然后处理到期的任务。轮询的方式只能处理数据量较小且实时性不高的数据，如果像处理淘宝订单15分钟内未付款自动取消订单这种任务，就需要更加高效的处理方式了。

1. Redis的Zset
#

Redis中有一种有序集合的数据结构zset，zset中每一个元素都有对应的score，zset中所有的数据都是按照score来排序的。

分布式理论

Tue, 14 Feb 2023 00:00:00 +0000

分布式理论
#

CAP理论
#

C：Consistency，即一致性。所有节点都访问同一份数据节点。
A：Availability，即可用性。每次请求都能获取到非错的响应，但不保证获取的数据为最新的数据。
P：Partition tolerence，即分区容错性。在某个节点或者网络分区故障的时候，仍然能够对外提供一致性和可用性服务，也就是说部分故障不影响整体的使用。

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想像两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

BASE理论
#

BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统打到最终一致性。

BA：Basically Available，即基本可用。假设系统某个模块出现了不可预知的故障，但其他模块依然可用。如双十一活动时，评论模块出现故障，但不会影响交易、商品等核心模块的使用。
S：Soft Status，即软状态。指允许系统中出现中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
E：Eventually Consistent，即最终一致。上面讲到的软状态不可能一直是软状态，必须有时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性，因此所有客户端对系统的数据访问最终都能够获取到最新的值，而这个时间期限取决于网络延时，系统负载，数据复制方案等因素。

总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。

Raft协议
#

分布式存统通常通过维护多个副本来进行容错，提高系统的可用性。要实现此目标，就必须要解决分布式系统的最核心问题：维护多个副本的一致性。Raft协议将一致性协议的核心内容分拆成为几个关键阶段，以简化流程，提高协议的可理解性。

Golang之sync.Map源码分析

Mon, 13 Feb 2023 00:00:00 +0000

Golang之sync.Map源码分析
#

map的并发操作
#

从前面文章的分析可以看到，原生的map如果并发读写的话，会抛出异常。

	if h.flags&hashWriting != 0 {
		throw("concurrent map read and map write")
	}

也就是说原生的map不是并发安全的。如果要实现并发安全，可以在操作map的时候加一把mutex锁。但官方提供了更高效的sync.Map，使其能在并发安全的前提下更加高效地读写。sync.Map使用了写时复制（即Copy On Write）技术来实现安全的高并发的map。sync.Map适用于读多写少的场景。

sync.Map数据结构
#

type Map struct {

	mu Mutex //互斥锁 保护dirty字段

	read atomic.Value //只读数据 实际类型为sync.readOnly

	dirty map[interface{}]*entry //写入数据 操作前需先加锁
 
	misses int //每次从read读取失败（read穿透） misses+1
}

其中sync.readOnly的数据结构

GPM<1>-进程-线程-协程

Thu, 09 Feb 2023 00:00:00 +0000

GPM<1> 进程/线程/协程
#

进程/线程/协程
#

进程
#

进程是一个具有一定独立功能的程序在一个数据集上的一次动态执行的过程，是操作系统进行资源分配和调度的一个独立单位，是应用程序运行的载体。每一个进程都有自己独立的地址空间。

线程
#

线程是进程的一个实体，是CPU调度和分派的基本单位，线程自己基本上不拥有系统资源，但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。线程的上下文切换比进程的上下文切换快得多，所以对他的调度的开销会小很多，从而提高系统资源的利用率和吞吐量。

进程/线程联系与区别
#

其实Linux下并没有线程，只是为了迎合开发口味，搞了个轻量级进程出来就叫做了线程。轻量级进程和进程一样，都有自己独立的task_struct进程描述符，也都有自己独立的pid。从操作系统视角看，调度上和进程没有什么区别，都是在等待队列的双向链表里选择一个task_struct切到运行态而已。只不过轻量级进程和普通进程的区别是可以共享同一内存地址空间、代码段、全局变量、同一打开文件集合而已。线程切换和进程切换之间的主要区别在于，在线程切换期间，虚拟内存空间保持不变，而在进程切换期间则不然。那么CPU从一个task_struct切换到另一个task_struct时，是如何断定它进程间切换还是线程间切换呢？我我们可以通过task_struct里的tgid （thread group id）这个字段来判断。tgid这个字段在task_struct里代表线程的组id，即同一组（同一进程下）的线程拥有相同的tgid，当CPU切换task_struct时发现两个task_struct的tgid不同，则认为是进程切换，需要重新加载虚拟内存空间。

GPM<2>-协程的实现

Thu, 09 Feb 2023 00:00:00 +0000

GPM<2> 协程的实现
#

协程的实现
#

协程
#

前面我们说过利用协程具有轻量/上下文切换成本低等特点，那么他是如何在计算机中体现的? 到底协程是在那里被承载的?

线程分为用户态线程与内核态线程，一个用户态线程必须绑定一个内核态线程，但CPU并不知道用户态线程的存在，也就是说CPU没法管到用户空间的事。既然CPU管不到用户空间的事，那用户空间就成了“三不管”地带了，那就决定在用户空间搞点事情。

这样内核线程依然叫“线程”，用户线程就叫“协程”。

既然一个协程能绑定到一个线程上，那为什么不能将多个协程绑定到一个或多个线程上呢？下面分析三种协程与线程的绑定关系。

N:1模式
#

N个协程绑定在一个线程上，优点是协程的切换都在用户态，不用陷入内核态，切换迅速且切换的成本低。但其也有很明显的缺点。

因为N个协程都绑定到一个线程上了，即使是多核的计算也没有办法实现并行，浪费了计算机的性能。一旦某个协程阻塞，本线程下的其他协程都无法执行，没有了并发能力。

1:1模式
#

解决了N:1模式没有并发能力的不足，但每次切换协程都要切换线程，成本太高，失去了协程存在的意义。

GPM<3>-调度设计

Thu, 09 Feb 2023 00:00:00 +0000

GPM<3> 调度设计
#

GPM
#

G: Goroutine，Goroutine这个概念来自协程，一个Goroutine必须必须绑定到P上才能被CPU执行。Goroutine非常轻量，创建一个Goroutine只需要几kb的内存资源(实际上这个内存资源是动态的，如果有需要runtime会为goroutine自动分配资源)。

P: Processer, 即为G和M的调度对象，用来调度G和M之间的关联关系，其数量可通过GOMAXPROCS()来设置，默认为CPU核心数。

M: Machine, OS 内核线程抽象，代表着真正执行计算的资源，在绑定有效的 P 后，执行P调度出来的G。M的数量由runtime决定(默认最大1000)。M 并不保留 G 状态，这是 G 可以跨 M 调度的基础。

Go调度器的是由GPM构成的。

调度器初期设计
#

调度器初期的设计是并没有P，仅有G与M，造成了如下弊端。

1.如每次M调度G都需要获G全局队列的锁，造成了激烈的锁竞争。

2.无法实现G的局部性（即从当M1执行G1时，G1创建出来的G1’无法保证任然被M1执行）

3.M需要经常互相传递可运行的 G，引入了大量的延迟；

调度器进阶设计
#

基于旧的调度器的弊端，Go设计了一个全新的调度器。再新的调度器中，加入了P。M是G运行的实体，P负责把G分配到M上进行执行，M才是真真正正的“干活者”。

Golang之内存管理2

Wed, 08 Feb 2023 00:00:00 +0000

Golang之内存管理
#

概述
#

Golang的内存分配借鉴了Google的TMalloc，其核心思想是内存池+多级对象管理，能加快分配速度，降低资源竞争。

Golang内存模型层次结构
#

MCache
#

访问mcache依然不需要加锁而是直接访问，且MCache中依然保存各种大小的Span。MCache是与Golang协程调度模型GPM中的P所绑定，而不是和线程绑定。因为Golang调度的GPM模型，真正可运行的线程M的数量与P的数量一致，即GOMAXPROCS个，所以MCache与P进行绑定更能节省内存空间使用，可以保证每个G使用MCache时不需要加锁就可以获取到内存。

MCentral
#

当MCache中某个Size Class对应的Span被一次次Object被上层取走后，如果出现当前Size Class的Span空缺情况，MCache则会向MCentral申请对应的Span。Goroutine、MCache、MCentral、MHeap互相交换的内存单位是不同，向Mcentral申请内存是需要加锁的。

Golang之内存对齐

Tue, 07 Feb 2023 00:00:00 +0000

Golang之内存对齐
#

现象
#

type foo struct {
	a bool   //1字节
	b int32  //4字节
	c int8   //1字节
	d int64  //8字节
	e byte   //1字节
}

func main() {
    f := foo{}
    fmt.Println("size of foo: ", unsafe.Sizeof(f))
}

这个输出结果是各个字段占用内存的和15字节吗？答案并不是，输出的结果是32字节，要大于所有字段占用内存大小的总和15字节。

内存对齐
#

可能很多人认为在结构体中各个字段的内存是连续的，cpu按各个字段的大小按需读取相应的值。

但实际上，cpu读取内存是以块为单位的，块的大小可以为 2、4、6、8、16 字节等大小（也称为内存粒度），cpu每次都读去内存里的“若干块”数据。在内存分布上，内存也是“一块一块”分布的，数据不是按照其本身的大小排布，而是按照内存粒度的来排布，以方便cpu快速读取数据，这就是内存对齐。

为什么需要内存对齐？
#

1.平台原因：不是所有硬件平台都能访问任意地址上的任意数据。例如：特定的硬件平台只允许在特定地址获取特定类型的数据，否则会导致异常情况。

Golang之mutex源码分析

Fri, 03 Feb 2023 00:00:00 +0000

Golang之mutex
#

互斥锁Mutex
#

在Golang中用于表示互斥锁的是sync.Lock，其作用是保护临界区，确保任意时间只有一个goroutine能拿到锁。

正常模式&饥饿模式
#

为了保证公平性，Golang在v1.9的互斥锁版本中引入了饥饿模式与正常模式。

如果当前锁正在被持有，抢不到锁就会进入一个等待的队列，当锁被释放后，从这个队列的队头里唤醒一个goroutine（等待者），但是锁不会直接给这个等待者，而是必须与正在获取锁但还未进入等待队列的goroutine竞争这把锁，与刚唤醒的等待者相比，这个goroutine正持有CPU，所以获取到锁的概率较大。如果等待者抢锁失败，那么它就会被放回队列头部，如果它超过1ms都还没获取到锁，就从正常模式切换为饥饿模式。
在饥饿模式下，当锁释放后，锁会直接交给等待队列的第一个等待者，不必再与新来的goroutine竞争，新来的goroutine会直接加到等待队列的队尾。当满足以下两个条件时，饥饿模式将切换回正常模式。（1）当前被唤醒的等待者获得锁后，发现队列只剩它自己一个了，那么切换回正常模式。（2）当前被唤醒的等待者获得锁后，发现自己的等待时间不超过1ms，那么切换回正常模式。

在正常模式下，当前拥有CPU的goroutine比起等待队列里的goroutine有很大几率获得锁，这样可以避免协程上下文的频繁切换。但这样又会导致等待队列里的goroutine活活“饿死”，所以又必须有饥饿模式，保证等待已久的goroutine能够获取到锁，以保证公平性。

sync.Lock
#

type Mutex struct {
	state int32 //表示锁的状态，有锁定、饥饿、唤醒等状态
	sema  uint32 //表示信号量 用于实现mutex阻塞队列的定位
}

const (
	mutexLocked = 1 << iota //1 state & 1 == 1 表示上锁状态
	mutexWoken	            //2 state & 2 == 1 表示唤醒状态 
	mutexStarving           //4 state & 4 == 1 表示饥饿状态
	mutexWaiterShift = iota //3 state >> 3 获取等待者的数量	

	starvationThresholdNs = 1e6 //进入饥饿状态的阈值
)

state字段总共占用32个bit，其中用前三位表示三个状态，后29个bit表示等待的goroutine个数。

Golang之ants源码分析

Tue, 24 Jan 2023 00:00:00 +0000

ants
#

1. 简介
#

ants 是一个高性能的协程池，实现了对大规模 goroutine 的调度管理、goroutine 复用，允许使用者在开发并发程序的时候限制协程数量，复用资源，达到更高效执行任务的效果。其具体特点如下：

自动调度海量的 goroutines，复用 goroutines
定期清理过期的 goroutines，进一步节省资源
提供了大量有用的接口：任务提交、获取运行中的 goroutine 数量、动态调整 Pool 大小、释放 Pool、重启 Pool
优雅处理 panic，防止程序崩溃
资源复用，极大节省内存使用量；在大规模批量并发任务场景下比原生 goroutine 并发具有更高的性能
非阻塞机制

本文从pool顶层方法开始，到底层workArray的实现，由上至下分析整个ants的工作流程。以下代码分析基于：

github.com/panjf2000/ants/v2 v2.6.0

2. 项目结构
#

ants                		       root directory
├── interal                    
    ├── spinlock                  自实现的自旋锁
├── ants.go                 		  定义常量、errors显示、默认goroutine池、封装一些方便用户操作查看goroutine池的函数
├── options.go                    goroutine池的相关配置
├── pool.go 											普通pool(不绑定特定函数)的创建以及对pool相关的操作
├── pool_func.go                  创建绑定某个特定函数的pool以及对pool相关的操作
├── worker.go                     goWorker的定义及方法
├── worker_array.go               workerArray的接口和一个能返回实现该接口的函数
├── worker_loop_queue.go 					loopQueue的定义及方法 loopQueue实现了workerArray
├── worker_stack.go               workerStack的定义及方法 workerStack实现了workerArray

3. 数据结构及实现原理
#

3.1 概念
#

首先需要明白ants代码两个概念，worker及task（任务）

k8s服务发现

Sat, 07 Jan 2023 00:00:00 +0000

K8S之服务发现
#

Serivce
#

概念
#

Pod存在生命周期，有销毁，有重建，无法提供一个固定的访问接口给客户端。并且为了同类的Pod都能够实现工作负载的价值，由此Service资源出现了，可以为一类Pod资源对象提供一个固定的访问接口和负载均衡。当Pod宕机后重新生成时，其IP等状态信息可能会变动，Service会根据Pod的Label对这些状态信息进行监控和变更，保证上游服务不受Pod的变动而影响。

类型
#

Service一共有四种类型，分别是ClusterIP、NodePort、LoadBalancer、ExternaName。

1.ClusterIP
#

默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP。

DDD领域驱动设计

Thu, 22 Dec 2022 00:00:00 +0000

领域驱动设计
#

1.分层架构
#

用户界面层：网络协议的转化/统一鉴权/Session 管理/限流配置/前置缓存/异常转换
应用层：业务流程编排（仅编排，不能存在业务逻辑）/ DTO 出入转化
领域层：领域模型/领域服务/仓储和防腐层的接口定义
基础设施层：仓储和防腐层接口实现/存储等基础层能力

2. todo…
#

MySQL之mvcc

Sun, 04 Dec 2022 00:00:00 +0000

MVCC
#

概念
#

MVCC 的英文全称是 Multiversion Concurrency Control ，中文意思是多版本并发控制技术。原理是，通过数据行的多个版本管理来实现数据库的并发控制，简单来说就是保存数据的历史版本。可以通过比较版本号决定数据是否显示出来。读取数据的时候不需要加锁可以保证事务的隔离效果。

MVCC是如何实现的？

我们需要先了解两个知识：

Read View 中四个字段作用；
聚簇索引记录中两个跟事务有关的隐藏列；

隐藏列

InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。也就是说，数据表中的一行记录，其实可能有多个版本 (row)，每个版本有自己的 row trx_id。每个版本之间可以用回滚指针相连接。

对于使用 InnoDB 存储引擎的数据库表，它的聚簇索引记录中都包含下面两个隐藏列：

trx_id，当一个事务对某条聚簇索引记录进行改动时，就会把该事务的事务 id 记录在 trx_id 隐藏列里；
roll_pointer，每次对某条聚簇索引记录进行改动时，都会把旧版本的记录写入到 undo 日志中，然后这个隐藏列是个指针，指向每一个旧版本记录，于是就可以通过它找到修改前的记录。

MySQL之死锁

Sun, 04 Dec 2022 00:00:00 +0000

死锁
#

概念
#

死锁是并发系统中常见的问题，同样也会出现在数据库MySQL的并发读写请求场景中。当两个及以上的事务，双方都在等待对方释放已经持有的锁或因为加锁顺序不一致造成循环等待锁资源，就会出现“死锁”。常见的报错信息为 Deadlock found when trying to get lock...。

检测语句
#

可以使用下面这条命令来查看MySQL最近的一次死锁日志：

show engine innodb status

查看当前执行的事务：

select * from information_schema.innodb_trx

查看当正在等锁的事务：

select * from information_schema.innodb_lock_waits

场景分析
#

sql准备：

MySQL之索引调优

Sun, 04 Dec 2022 00:00:00 +0000

索引
#

索引是什么？
#

索引是提升查询速度的一种数据结构。索引之所以能提升查询速度，在于它在插入时对数据进行了排序（显而易见，它的缺点是影响插入或者更新的性能）。InnoDB 存储引擎支持的索引有 B+ 树索引、全文索引、R 树索引。这里讲使用最广泛的 B+ 树索引。

设计模式之行为型模式

Tue, 15 Nov 2022 00:00:00 +0000

行为型模式
#

1.模版方法模式
#

在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。模版方法模式中的角色与职责如下：

AbstractClass（抽象类）：在抽象类中定义了一系列基本操作(PrimitiveOperations)，这些基本操作可以是具体的，也可以是抽象的，每一个基本操作对应算法的一个步骤，在其子类中可以重定义或实现这些步骤。同时，在抽象类中实现了一个模板方法(Template Method)，用于定义一个算法的框架，模板方法不仅可以调用在抽象类中实现的基本方法，也可以调用在抽象类的子类中实现的基本方法，还可以调用其他对象中的方法。
ConcreteClass（具体子类）：它是抽象类的子类，用于实现在父类中声明的抽象基本操作以完成子类特定算法的步骤，也可以覆盖在父类中已经实现的具体基本操作。

package main

import "fmt"

type WorkInterface interface {
	GetUp()
	Work()
	Sleep()
}

type worker struct {
	WorkInterface
}

func NewWorker(w WorkInterface) worker {
	return worker{WorkInterface: w}
}

func (w worker) Daily()  {
	w.GetUp()
	w.Work()
	w.Sleep()
}


//具体子类
type Coder struct {}

func (Coder) GetUp()  {
	fmt.Println("coder get up")
}

func (Coder) Work()  {
	fmt.Println("coder work")
}

func (Coder) Sleep()  {
	fmt.Println("coder sleep")
}



type Farmer struct {}

func (Farmer) GetUp()  {
	fmt.Println("farmer get up")
}

func (Farmer) Work()  {
	fmt.Println("farmer work")
}

func (Farmer) Sleep()  {
	fmt.Println("farmer sleep")
}

func main()  {
	worker1 := NewWorker(Coder{})
	worker1.Daily()

	fmt.Println("---------------")

	worker2 := NewWorker(Farmer{})
	worker2.Daily()
}

优点：

Nginx

Mon, 14 Nov 2022 00:00:00 +0000

Nginx
#

1. 常用命令
#

nginx -s stop  快速关闭nginx，可能不保存相关信息，并迅速终止web服务
nginx -s quit  平稳关闭nginx，保存相关信息，有安排的结束web服务
nginx -s reload  因改变了Nginx相关配置，需要重新加载配置而重载
nginx -s reopen 重新打开日志文件
nginx -s filename 为 Nginx 指定一个配置文件，来代替缺省的
nginx -s test 不运行，仅仅测试配置文件。nginx 将检查配置文件的语法的正确性，并尝试打开配置文件中所引用到的文件
nginx -v 显示 nginx 的版本
nginx -V 显示 nginx 的版本，编译器版本和配置参数

2. 实战
#

a. 反向代理
#

#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
  worker_connections  1024;
}


http {
  include       mime.types;
  default_type  application/octet-stream;

  #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
  #                  '$status $body_bytes_sent "$http_referer" '
  #                  '"$http_user_agent" "$http_x_forwarded_for"';

  #access_log  logs/access.log  main;

  sendfile        on;
  #tcp_nopush     on;

  #keepalive_timeout  0;
  keepalive_timeout  65;

  #gzip  on;

  #上游服务器
  upstream my_server{
    server  localhost:8081;
    server  localhost:8082;
  }

  server {
    listen       8080;
    server_name  localhost;

    location / {
      root   html;
      index  index.html index.htm;
      proxy_pass http://my_server;
      proxy_set_header Host $host;
    }

  include servers/*;
}

b. 负载均衡
#

在前面反向代理的基础上，可以拓展出请求上游服务器负载均衡的策略。

git代码管理工具

Thu, 10 Nov 2022 00:00:00 +0000

git
#

简介
#

Git是目前世界上最先进的分布式版本控制系统。

工作流程
#

Workspace：工作区
Index / Stage：暂存区
Repository：仓库区（或本地仓库）
Remote：远程

wrk性能测试工具

Thu, 10 Nov 2022 00:00:00 +0000

wrk
#

简介
#

wrk 是一款针对 Http 协议的基准测试工具，它能够在单机多核 CPU 的条件下，使用系统自带的高性能 I/O 机制，如 epoll，kqueue 等，通过多线程和事件模式，对目标机器产生大量的负载。

使用
#

基本命令

Usage: wrk <options> <url>
  Options:
    -c, --connections <N>  总的http连接数
    -d, --duration    <T>  压测时间
    -t, --threads     <N>  使用多少个线程进行压测

    -s, --script      <S>  指定lua脚本路径
    -H, --header      <H>  为每一个http请求添加http头部
        --latency          在压测结束后，打印延迟统计信息
        --timeout     <T>  超时时间
    -v, --version          版本信息
    
  <N>代表数字参数，支持国际单位 (1k, 1M, 1G)
  <T>代表时间参数，支持时间单位 (2s, 2m, 2h)

测试报告

缓存策略

Thu, 10 Nov 2022 00:00:00 +0000

缓存策略
#

1. 双写策略
#

双写即当数据修改时，即要更新数据库也要更新缓存。下面看看具体的双写的两种场景。

a. 先更新数据库，再更新缓存
#

请求A先更数据库为1
请求B更新数据库为2
请求B先更新缓存为2
请求A更新缓存为1

先更新数据库，再更新缓存这种策略会导致数据库与缓存不一致

b. 先更新缓存，再更新数据库
#

请求A先更新缓存为1
请求B更新缓存为2
请求B先更新数据库为2
请求A更新数据库为1

与先更新数据库，再更新缓存这种策略一样，先更新缓存，再更新数据库会因为并发原因导致数据库与缓存数据不一致。

设计模式之创建型模式

Tue, 01 Nov 2022 00:00:00 +0000

创建型模式
#

1.单例模式
#

单例模式保证知有一个类、只有一个实例存在，同时提供能对该实例加以访问的全局访问方法。单例模式的三个要点：

这个类只能有一个实例
这个类必须自己创建这个实例
这个类必须自行向整个系统提供这个实例

下面是一个单例模式的demo

package singelton

import "fmt"

type singelton struct {}

func (*singelton) Foo()  {
	fmt.Println("call singleton.Foo")
}

func (*singelton) Bar()  {
	fmt.Println("call singleton.Bar")
}

var instance = new(singelton)

func GetInstance() *singelton {
	return instance
}

//.... in main.go
func main() {
  s := singelton.GetInstance()
  s.Foo()
  s.Bar()
}

上面这个demo模式展示了单例模式的一种，属于饿汉模式。其含义是在初始化单例唯一指针的时候，就已经提前开辟好了一个对象，申请了内存。饿汉式的好处是，不会出现线程并发创建，导致多个单例的出现，但是缺点是如果这个单例对象在业务逻辑没有被使用，也会客观的创建一块内存对象。那么与之对应的模式叫懒汉模式，代码如下：

幂等设计

Wed, 26 Oct 2022 00:00:00 +0000

幂等设计
#

什么是幂等？
#

幂等指的是对某个资源来说，一次请求与多次请求，具有相同的副作用。用数学的语言的来表示就是f(x) = f(f(x))。为什么需要幂等？当我们将系统节藕隔离后，服务间的调用可能有三种状态：成功、失败、超时。前两者是明确的状态，而超时则是一种不明确的状态，可能这个请求还没到达服务端就已经超时了，也有可能请求已经到服务端，但是在返回给客户端的过程中超时或者丢包了，客户端完全不知道服务端是否有接受到数据。举几个例子：

订单支付时，第一次支付超时了，然后客户端再次调用，是否会多扣一次钱？
在页面提交form表单时，保存按钮不小心快速按了两次，表中产生了两条重复的数据数据。
mq消费的时候，有时候会读取到重复的消息，造成重复消费。

接口性幂等是指用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

如何保证幂等？
#

1. insert前先select
#

在insert数据前，先用唯一id（例如订单id）查询一下数据库是否有这个订单记录，如果没有则insert，否则返回订单信息。这种方法很简单，但是很明显，在并发的情况下一样会有产生重复订单。

2. 悲观锁
#

当有多个重复请求到达时，只有一个请求能够进行操作。比如在支付场景中，用户A的账户中有150元，某个请求扣件100元后，此时账户还剩50元。如果出现多次重复的请求，那么用户的余额可能出现负数。为了解决这个问题，可以使用悲观锁先锁住用户的账号，MySQL中可以用如下sql语句锁住数据。

设计模式之结构型模式

Wed, 26 Oct 2022 00:00:00 +0000

结构型模式
#

1.代理模式
#

代理模式可以为其他对象提供一种代理以控制对这个对象的访问。所谓代理，是指具有与代理元（被代理的对象）具有相同的接口的类，客户端必须通过代理与被代理的目标类交互，而代理一般在交互的过程中（交互前后），进行某些特别的处理。代理模式的角色与职责如下：

Subject（抽象主题角色）：真实主题与代理主题的共同接口。
RealSubject（真实主题角色）：定义了代理角色所代表的真实对象。
Proxy（代理主题角色）：含有对真实主题角色的引用，代理角色通常在将客户端调用传递给真实主题对象之前或者之后执行某些操作，而不是单纯返回真实的对象。

package main

import "fmt"

type Goods struct {
	Kind string //商品种类
	Fact bool //商品真伪
}

// =========== 抽象层 ===========
//抽象的购物主题Subject
type Shopping interface {
	Buy(goods *Goods) //某任务
}

// =========== 实现层 ===========
type KoreaShopping struct {}
func (ks *KoreaShopping) Buy(goods *Goods) {
	fmt.Println("去韩国进行了购物, 买了 ", goods.Kind)
}

type AmericanShopping struct {}
func (as *AmericanShopping) Buy(goods *Goods) {
	fmt.Println("去美国进行了购物, 买了 ", goods.Kind)
}

type AfricaShopping struct {}
func (as *AfricaShopping) Buy(goods *Goods) {
	fmt.Println("去非洲进行了购物, 买了 ", goods.Kind)
}

//代理层
type OverseasProxy struct {
	shopping Shopping //代理某个主题，这里是抽象类型
}

func NewProxy(shopping Shopping) *OverseasProxy {
	return &OverseasProxy{
		shopping: shopping,
	}
}

func (op *OverseasProxy) Buy(goods *Goods)  {
	if op.distinguish(goods) { //代理验货
		op.shopping.Buy(goods) //进行购买 调用真实主题角色的具体任务
		op.check(goods) //海关安检
	}
}

//代理验货
func (op *OverseasProxy) distinguish(goods *Goods) bool {
	fmt.Println("对[", goods.Kind,"]进行了辨别真伪.")
	if goods.Fact == false {
		fmt.Println("发现假货",goods.Kind,", 不应该购买。")
	}
	return goods.Fact
}

//安检流程
func (op *OverseasProxy) check(goods *Goods) {
	fmt.Println("对[",goods.Kind,"] 进行了海关检查， 成功的带回祖国")
}

func main()  {
	g1 := &Goods{Kind: "韩国面膜", Fact: false}
	g2 := &Goods{Kind: "米国鞋子", Fact: true}

	//不使用代理模式
	koreaShopping := &KoreaShopping{}
	if g1.Fact == true {
		fmt.Println("对[", g1.Kind,"]进行了辨别真伪.")
		koreaShopping.Buy(&g1)
		fmt.Println("对[",g1.Kind,"] 进行了海关检查， 成功的带回祖国")
	}


	//使用代理模式
	proxy1 := NewProxy(&KoreaShopping{})
	proxy1.Buy(g1)

	proxy2 := NewProxy(&AmericanShopping{})
	proxy2.Buy(g2)
}

优点：

MySQL之next-key lock

Mon, 24 Oct 2022 00:00:00 +0000

Next-key lock
#

Innodb 引擎为了解决「可重复读」隔离级别使用「当前读」而造成的幻读问题，就引出了 next-key 锁，就是记录锁和间隙锁的组合。这里强调**「当前读」，是因为在「快照读」的情况下，由mvcc来保证不会产生幻读。mvcc相关的内容具体可以参考另一篇文章。这里只讨论「当前读」的情况。以下内容全部基于「可重复读」隔离级别**。

记录锁&间隙锁
#

记录锁，锁的是记录本身；
间隙锁，锁的就是两个值之间的空隙，以防止其他事务在这个空隙间插入新的数据，从而避免幻读现象。

加锁规则
#

对记录加锁时，加锁的基本单位是 next-key lock，它是由记录锁和间隙锁组合而成的，next-key lock 是前开后闭区间，而间隙锁是前开后开区间。但是，next-key lock 在一些场景下会退化成记录锁或间隙锁。另外，文章后面提到的next-key lock、间隙锁、记录锁都是加在索引上的，而不是加在数据行上的。

场景分析
#

先准备测试表，其中id为主键（唯一索引），age上有一个普通索引，name上没有索引

分布式ID

Thu, 13 Oct 2022 00:00:00 +0000

分布式ID
#

1. 什么是分布式ID
#

在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求。特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。

分布式ID需要满足哪些条件？

全局唯一：必须保证ID是全局性唯一的，基本要求
高性能：高可用低延时，ID生成响应要块，否则反倒会成为业务瓶颈
高可用：100%的可用性是骗人的，但是也要无限接近于100%的可用性
好接入：要秉着拿来即用的设计原则，在系统设计和实现上要尽可能的简单
趋势递增：最好趋势递增（防止索引数据页频繁发生页分裂），这个要求就得看具体业务场景了，一般不严格要求

2. 如何生成分布式ID
#

a. uuid
#

想要得到一个具有唯一性的ID，首先被想到可能就是UUID，毕竟它有着全球唯一的特性。那么UUID可以做分布式ID吗？答案是可以的，但是并不推荐。

优点：

生成足够简单，本地生成无网络消耗，具有唯一性

缺点：

LSM树

Mon, 10 Oct 2022 00:00:00 +0000

LSM树
#

简介
#

LSM树，即日志结构合并树(Log-Structured Merge-Tree)。其实它并不属于一个具体的数据结构，它更多是一种数据结构的设计思想。大多NoSQL数据库核心思想都是基于LSM来做的，只是具体的实现不同。传统关系型数据库使用btree或一些变体作为存储结构，能高效进行查找。但保存在磁盘中时它也有一个明显的缺陷，那就是逻辑上相离很近但物理却可能相隔很远，这就可能造成大量的磁盘随机读写。随机读写比顺序读写慢很多，为了提升IO性能，我们需要一种能将随机操作变为顺序操作的机制，于是便有了LSM树。LSM树能让我们进行顺序写磁盘，从而大幅提升写操作，作为代价的是牺牲了一些读性能。

定义
#

LSM树是一个横跨内存和磁盘的，包含多颗"子树"的一个森林。
LSM树分为Level 0，Level 1，Level 2 … Level n 多颗子树，其中只有Level 0在内存中，其余Level 1-n在磁盘中。
内存中的Level 0子树一般采用排序树（红黑树/AVL树）、跳表或者TreeMap等这类有序的数据结构，方便后续顺序写磁盘。
磁盘中的Level 1-n子树，本质是数据排好序后顺序写到磁盘上的文件，只是叫做树而已。
每一层的子树都有一个阈值大小，达到阈值后会进行合并，合并结果写入下一层。
每一层的子树都有一个阈值大小，达到阈值后会进行合并，合并结果写入下一层。

LSM树的增删改查
#

1. 增加
#

插入比较简单，直接在level 0 树插入即可，因为level 0 树是有序的，并且level 0 树是在内存中，所以插入的速度快，时间复杂度为o(logn)，如果插入的key已经存在，那么直接转换为更新操作。

Golang之defer

Sun, 18 Sep 2022 00:00:00 +0000

Golang之defer
#

defer
#

Golang的defer会在函数返回前去执行传入的函数，它会经常被用于关闭文件描述符、关闭数据库连接以及解锁资源。

常见使用场景
#

1.关闭文件

func foo1()  {
	file, err :=  os.OpenFile("your file path", os.O_RDONLY, 0755)
	if err != nil {
		return
	}
	defer file.Close()
	//use file do something
	//...

	return
}

2.解锁

func foo2(mu *sync.Mutex)  {
	mu.Lock()
	defer mu.Unlock()
	//do something
	//...

	return
}

defer数据结构
#

type _defer struct {
	siz       int32  //参数和结果的内存大小
	sp        uintptr //栈指针
	pc        uintptr //调用方的程序计数器
	fn        *funcval //defer中传入的函数
	_panic    *_panic //触发延迟调用的结构体，可能为空
	link      *_defer //指向下一个defer
}

defer调用链
#

当goroutine获取到一个defer，就会创建一个runtime._defer结构体，然后将runtime._defer追加到当前goroutine的defer链表的最前面。

布隆过滤器

Sun, 18 Sep 2022 00:00:00 +0000

布隆过滤器
#

简介
#

本质上布隆过滤器是一种数据结构，比较巧妙的概率型数据结构（probabilistic data structure），特点是高效地插入和查询，可以用来告诉你 “某样东西一定不存在或者可能存在”。相比于传统的 List、Set、Map 等数据结构，它更高效、占用空间更少，但是缺点是其返回的结果是概率性的，而不是确切的。

HashMap
#

在讲布隆过滤器之前，我们先想有一下，判断某个元素是否存在用什么数据结构？HashMap是一个好选择，HashMap能在o(1)的时间复杂度内判断一个元素在不在，效率极高。如果数据量很小，那么HashMap确实是一个最佳选择，但是如果HashMap里存储的是上亿的key，那么他就有点力不从心了。存储上亿key的HashMap需要占用大量的空间内存，并且如果HashMap触发rehash，对那么多的key进行迁移必然会导致内存抖动。所以，HashMap并不适合存放亿级别的key。

Bloom Filter
#

前面说了HashMap不合适存放数量过多的key，那么有什么可以存放大数量的key且不会占用大量的内存？可以使用bit数组，也叫bitmap，布隆过滤器就是用bitmap来存储数据的。

如果我们要讲一个数据添加到布隆过滤器中，我们需要多个hash函数生成多个哈希值，再将这些hash值映射到对应的bit数组对的bit上，将这个bit置为1。例如针对值 “baidu” 和三个不同的哈希函数分别生成了哈希值 1、4、7，则上图转变为：

Golnag之interface

Tue, 23 Aug 2022 00:00:00 +0000

Golang之interface
#

接口
#

接口（interface）是一组仅包含方法名、参数、返回值的未具体实现的方法的集合。接口只定义规范而不去实现，细节由具体的对象来实现。Golang中接口是一种抽象的类型。

实现
#

Golang中interface通常分为两大类，一种是空接口，这种接口不带任何方法。

type a interface{}

另一种是非空接口，这种接口带有方法

type duck interface {
	quack()
}

这两种类型的接口底层分别对应两个不同的结构，空接口对应runtime.eface，非空接口对应runtime.iface

eface的定义如下

type eface struct {
	_type *_type  //记录类型信息（_type是GO语言中所有类型的公共描述，Go语言几乎所有的数据结构都可以抽象成 _type，是所有类型的公共描述，type负责决定data应该如何解释和操作）
	data  unsafe.Pointer //指向数据的指针
}

iface的定义如下

type iface struct {
	tab  *itab //
	data unsafe.Pointer //指向数据的指针
}

itab是最重要的结构，每一个 itab 都占 32 字节的空间。itab里面包含了interface的一些关键信息，比如method的具体实现。

Prometheus

Tue, 16 Aug 2022 00:00:00 +0000

Mon, 01 Jan 0001 00:00:00 +0000

1. 提示词
#

提示词也叫Prompt，是我们与大模型应用交互的唯一桥梁，简单来说就是我们给大模型的输入，例如我们在ChatGPT里的提问的问题，就是一个提示词：

用户提示词，除了用户提示词外，还有系统提示词。系统提示词可以简单地理解为一个自我介绍，例如扣子平台上的人设与回复逻辑：

提示词是贯通整个大模型应用的灵魂，所有应用层的技术，都是为了拼出一条合适的Prompt，在应用技术层无论我们做多炫酷的设计，最终都是为了传递合适的Prompt给大模型。

Prompt分类
#

Prompt的内容可以大致分为以下几类：

身份设定：例如“你是一个法律领域的智能助手”
背景设定：例如“你的年龄是在20岁左右的女生”
参考资料：例如“请你参考xx资料”
样例：例如一些门店提前准备的样例话术，下面会举例说明
指令：例如“请你帮我总结一些这段文本”
条件限制：例如“回答的时候不要超过200个字，尽量口语化”

在这些内容中，参考跟样例是比较重要的两个点，如果可以，提问的时候尽量将这两个内容加入Prompt中。

Zero-Shot、One-Shot、Few-Show
#

我们以Prompt中样例的数量给Prompt划分为三种类型：

Zero-Shot：没有一条样例
One-Shot：仅有一条样例
Few-Show：有多条样例

我们可以使用扣子平台来搭建一个Sony智能销售的客服，来看看不同的样例数对大模型的输出会造成什么影响。假设我们有以下一个场景：

场景：妈妈在给小孩挑游戏机做礼物，正在比较Switch和PS5 用户：感觉价格方面，Switch性价比高，PS5要贵不少吧？

来看下没有样例的回答，这个回答不能说错，但是算不上出色，其回答仅仅基于大模型在其训练的数据组装而成，并没有对问题本身做一些针对性的回答（从表面上看，用户可能是价格敏感性的）。

Mon, 01 Jan 0001 00:00:00 +0000

1. 什么是Agent
#

Agent 就是能像 “人” 一样自主完成任务的 AI 程序：你只需要告诉它 “要做什么（目标）”，不用告诉它**“怎么做（步骤）”**，它会自己规划步骤、调用工具、解决问题、完成目标，甚至中途遇到问题会自主调整策略。

维度	普通大模型（如 ChatGPT）	RAG	AI Agent
核心能力	理解 + 生成文本，无自主规划 / 工具调用	大模型 + 知识库检索，补全知识	规划 + 工具 + 记忆 + 执行，自主完成任务
交互方式	被动响应单步指令	被动响应问答需求	主动承接整体目标
任务处理	单步、简单、无依赖的任务	知识类问答任务	多步、复杂、有依赖的复合任务
你需要做的事	拆解步骤，一步步指挥	准备知识库，提精准问题	只给目标，无需拆解步骤
核心定位	「AI 聊天助手」	「AI 知识问答助手」	「AI 工作伙伴 / 执行者」

Agent可以大致分为Workflow Agent 与 ReAct Agent 两种。

Mon, 01 Jan 0001 00:00:00 +0000

1. 视觉和语言的打通
#

如何打通：一个模型，能同时看懂语言和视觉

进阶能力：能输出文字，也能输出图片、视频

好处：视觉转译、融合推理、视觉编辑

2. 视觉识别与视觉推理
#

传统视觉识别模型 vs 多模态模型

	传统视觉识别模型	多模态模型
产品	Yolo、UNet	Gemini、GPT
优势	模型小、部署和使用成本低、识别精度高	无需标注、无需训练、直接使用、有推理能力
劣势	需要单独标注数据、训练模型	部署和使用成本较高，精度中等

3. 视觉生成
#

模型能力不足：只是写提示词给模型，生成的视频&图片无法满足需求。

3.1 用AI做海报
#

Mon, 01 Jan 0001 00:00:00 +0000

1. LangChain
#

LangChain 是一套开源的 Python/JavaScript 框架，核心是通过模块化组件与可组合的链（Chain）将大语言模型（LLM）与外部数据源、工具（如搜索、数据库、API）连接，实现上下文管理、多步推理、智能交互等复杂 AI 应用的快速开发。

代码地址：https://github.com/langchain-ai/langchain
官方文档：https://docs.langchain.com/
中文文档：https://langchain-doc.cn/ （机翻，凑合着看）

LangChain的一些组件：

Models：模型，比如GPT-4o
Prompts：提示，包括提示管理、提示优化和提示序列化
Memory：记忆，用来保存和模型交互时的上下文
Indexes：索引，用于结构化文档，方便和模型交互如果要构建自己的知识库，就需要各种类型文档的加载，转换，长文本切割，文本向量计算，向量索引存储查询等
Chains：链，一系列对各种组件的调用
Agents：代理，决定模型采取哪些行动，执行并且观察流程，直到完成

2. 核心组件
#

代理
#

代理即Agent，其将语言模型与工具结合，创建能够对任务进行推理、决定使用哪些工具并迭代寻求解决方案的系统，简单来说，Agent像“人”一样能够通过思考来解决问题。

模型
#

模型即我们常说的大模型（如ChatGPT、Deepseek），能够像人类一样理解和生成文本。它们用途广泛，可用于撰写内容、翻译语言、总结信息和回答问题，而无需针对每项任务进行专门训练，模型是整个Langchain框架的大脑。模型可以通过两种方式使用：

Mon, 01 Jan 0001 00:00:00 +0000

1. 主流Agent框架
#

框架	优势	适用场景
LangChain+LangGraph	全能型框架，管道式编排与丰富生态	企业级复杂应用、RAG + 工具混合
AutoGen	对话式多 Agent	科研、代码生成、多角色辩论
Qwen-Agent	针对中文场景优化，对长文本友好	私有化部署、对接通义千问 / 阿里云生态
Coze/Dify	低代码可视化	业务人员快速搭建应用

这里仅仅列举了几个不同类型的框架，另外还有CrewAI、Semantic Kernel等一系列框架，不再一一列举。

2. Agent框架功能
#

一个Agent框架需要有哪些功能，解决哪些核心问题？

1.1 LLM层适配
#

LLM是Agent框架的大脑，一个Agent框架首先要具有LLM适配功能。一般来说，框架都具有以下特性：

统一调用方式
统一了参数配置（如 temperature）
输出格式（统一转为 Message 对象）

具体例子可以查看上一篇，这里不再赘述如何调用LLM。简单来说，就是各家LLM都定义了自己的一套API接口，如果要开发者自己去集成这些API，会花费很多功夫，所以这些框架都会在API层的基础上再包装一层，以适配不同的LLM。当开发者需要修改模型时，只需要修改对应的参数即可。

Mon, 01 Jan 0001 00:00:00 +0000

Hugging Face
#

Hugging Face 是什么？你可以把HuggingFace看成：

AI 界的 GitHub：程序员找代码去 GitHub，AI 工程师找模型和数据去 HuggingFace，它托管了全球最主流的开源模型（Llama, BERT, Stable Diffusion 等）。
AI 界的 App Store：它提供了很多现成的 Pipeline，你不需要懂原理，就能在你的代码里跑起来（比如一键实现情感分析）。

Hugging Face 的核心
#

1）Transformers (库)：

工具箱。提供了统一的 Python 接口，可以用几乎相同的代码加载 BERT、GPT 或 Llama。

2）Model Hub (网站)：

仓库。存放模型权重文件（.bin 或 .safetensors）和配置文件（config.json）。

3）Datasets (库)：

燃料库。一键下载维基百科、医疗问答、电商评论等海量数据集，并自动处理成模型能读的格式。

Hugging Face 中常用的模型
#

NLP（自然语言处理）领域
#

基础理解类（Encoder-Only）：

Mon, 01 Jan 0001 00:00:00 +0000

1. Transformer模型
#

在深度学习序列建模的发展中，RNN、LSTM等传统模型因难以捕捉长距离依赖、无法并行计算的瓶颈，难以满足大规模数据处理需求，Transformer模型应运而生。2017年，Google Brain团队发表《Attention Is All You Need》，正式提出这一纯注意力架构，打破循环结构的局限；历经多年演进，它从机器翻译任务起步，衍生出BERT、GPT等经典模型，如今已成为所有现代大模型的核心基础，支撑着多模态、千亿级参数模型的发展，奠定了当前人工智能产业化的技术根基。

2. 模型架构
#

Transformer模型的架构图如下所示，总共可以分成6个步骤

Tokenization：文本变成token
Embedding：token变成向量
Positional Encoding：在向量中加入位置信息
Encoder & Decoder：深度理解语义
Linear：生成“下一个字”的权重分布
Softmax：将权重分布转换成概率分布

2.1 Tokenization
#

第一步要做的是Tokenization，即把一段文本（这里应该叫输入更合适，但为了好理解还是用文本吧），变成一组Token。⽐如：

“subword"这个词，可以拆分成"sub"和"word"两个⼦词
“encoded"可以拆解为"encod”+“ed”
“encoding"可以拆解为“encod”+“ing”

使用OpenAI的tiktoken对“海南麒麟瓜”进行词元化，输出如下：

可见通过GPT-3.5模型拆分出来的token跟中文汉字的UTF-8编码并不是一一对应的。

Mon, 01 Jan 0001 00:00:00 +0000

传统模型
#

上一篇文章中我们说过，相较于现今的大语言模型，传统的模型使用的是RNN循环神经网络

这种神经网络模式有几个缺点：

信息丢失
无法处理较长句子
不能并行计算

注意力机制
#

什么叫注意力机制？

Mon, 01 Jan 0001 00:00:00 +0000

索引相关
#


# 创建索引 并设置mapping&分片数&副本数
curl -XPUT 'http://user:password@url:9200/books' -H 'Content-Type: application/json' -d'
  {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1
    },
    "mappings": {
      "properties": {
          "book_id": {
              "type": "keyword"
          },
          "book_name": {
              "analyzer": "standard",
                  "type": "text"
          },
          "update_time": {
            "type": "date"
          },
        "create_time": {
          "type": "date"
        }    
      }
    }

  }'

# 查询索引 
curl -XGET 'http://user:password@url:9200/books?pretty'

# 删除索引
curl -XDELETE 'http://user:password@url:9200/books'

# 查询索引 
  curl -XGET 'http://user:password@url:9200/books?pretty'

查询相关
#

Mon, 01 Jan 0001 00:00:00 +0000

前言
#

Elasticsearch是基于Lucene的，所以它的评分机制也是基于Lucene的。在Lucene中把这种相关性称为得分（score），确定文档和查询有多大相关性的过程被称为打分（scoring）。

ES最常用的评分模型是 TF/IDF和BM25，TF-IDF属于向量空间模型，而BM25属于概率模型，但是他们的评分公式差别并不大，都使用IDF方法和TF方法的某种乘积来定义单个词项的权重，然后把和查询匹配的词项的权重相加作为整篇文档的分数。

ES v5.0 之前使用TF/IDF算法，之后的版本使用BM25算法。

名词解释
#

Mon, 01 Jan 0001 00:00:00 +0000

pmp题纲
#

情景模拟学习法
#

识别时间点
- 问现在
  - 重要优先
  - 识别方法
    - 1. 项目经理现在应该做什么？
    - 1. 项目经理能够如何完成这项工作？
    - 1. 项目经理应该使用什么来进行回复？
  - 应对思路
    - 1. 重要优先：如果多个答案都合理，选择其中最重要的，最能解决问题的方法
    - 1. 原则优先：选择最符合PMI价值观的方法
    - 1. 合规优先：必须遵守规则、流程和计划
    - 1. 响应题目：对于题目中给出的制约因素，要进行考虑和响应
- 问首先（步骤在前）
  - 识别方法
    - 1. 项目经理首先应该做什么
    - 1. 项目经理下一步应该做什么
    - 1. 项目经理应该指示团队下一步做什么
  - 应对思路
    - 1.如果多个选项都是正确的行为，要选择其中执行顺序在前的
- 问事先（规避防范）
  - 识别方法
    - 1. 项目经理事先应该采取什么不同的做法
    - 1. 项目经理要如何在项目开始时管理此情形
    - 1. 若要避免这种情况，项目经理应该做什么
    - 1. 下列哪一项可以预防该问题
  - 应对思路
    - 1. 先分析问题的根本原因，再从根源上和流程制度上消除这个原因
    - 1. 主要的解决办法
      - a. 制定正确的计划和过程
      - b. 确保执行正确的计划和过程
      - c. 让相关方尽早参与
      - d. 充分识别风险并制定对应的计划
      - e. 充分收集需求
- 问未来（积累经验）
识别项目阶段
- 启动阶段
- 规划阶段
- 执行阶段
- 收尾阶段
识别典型场景
- 要求变更/私自变更
- 资源短缺/技能不足
- 新节点

解析pmi核心价值观
#

新节点
新节点

Posts on

VibeCoding个人配置

过目不忘：CLAUDE

核心概念 #

工作原理 #

基础结构 #

gmview设计

背景 #

设计 #

git删除远程文件

why #

how #

触类旁通：Skill

Skill的背景 #

Skill的类型 #

参考型 #

防微杜渐：Hook

Hook出现背景 #

Hook事件 #

Hello World

你好 #

我好 #

大家好 #

各司其职：SubAgent

为什么需要SubAgent #

什么是SubAgent #

15. 交易树与收据树

交易树与收据树 #

交易树 #

收据树 #

16. 以太坊的共识协议

前言 #

GHOST协议 #

14. 以太坊的状态树

以太坊的状态树 #

方案1: 哈希表 #

方案2: Merkle Tree #

11.比特币思考

哈希指针 #

区块恋 #

分布式共识 #

比特币的稀缺性 #

量子计算 #

12. 以太坊

概述 #

核心功能 #

共识机制 #

经济模型 #

性能与扩展 #

13. 以太坊的账户

前言 #

比特币账户 #

以太坊账户 #

如何解决 #

10. 比特币匿名性

比特币的匿名性 #

账号关联 #

身份关联 #

如何提高匿名性 #

4. 比特币挖矿

比特币共识 #

为什么需要共识 #

如何达成共识 #

挖矿 #

发行货币 #

9. 比特币分叉

什么是分叉 #

软分叉与硬分叉 #

硬分叉 #

软分叉 #

3. 比特币的交易

UTOX模型 #

传统的中心化交易 #

去中心化交易 #

双花攻击 #

8. 比特币脚本

5. 比特币挖矿难度

挖矿难度 #

调整挖矿难度原因 #

出块时间太短会带来什么问题？ #

核心概念
#

工作原理
#

基础结构
#

背景
#

设计
#

why
#

how
#

Skill的背景
#

Skill的类型
#

参考型
#

Hook出现背景
#

Hook事件
#

你好
#

我好
#

大家好
#

为什么需要SubAgent
#

什么是SubAgent
#

交易树与收据树
#

交易树
#

收据树
#

前言
#

GHOST协议
#

以太坊的状态树
#

方案1: 哈希表
#

方案2: Merkle Tree
#

哈希指针
#

区块恋
#

分布式共识
#

比特币的稀缺性
#

量子计算
#

概述
#

核心功能
#

共识机制
#

经济模型
#

性能与扩展
#

前言
#

比特币账户
#

以太坊账户
#

如何解决
#

比特币的匿名性
#

账号关联
#

身份关联
#

如何提高匿名性
#

比特币共识
#

为什么需要共识
#

如何达成共识
#

挖矿
#

发行货币
#

什么是分叉
#

软分叉与硬分叉
#

硬分叉
#

软分叉
#

UTOX模型
#

传统的中心化交易
#

去中心化交易
#

双花攻击
#

挖矿难度
#

调整挖矿难度原因
#

出块时间太短会带来什么问题？
#

出块时间10min是最优解吗？
#

全节点与轻节点
#

挖矿设备
#

一代设备：CPU
#

比特币网络
#

比特币网络
#

设计原则
#

交易冲突
#

整体结构
#

全节点跟轻节点
#

哈希指针
#

为什么需要哈希指针
#

什么是哈希
#

哈希特性
#

什么是签名
#

背景
#

1. introduce
#

2. concept
#

3. grammar
#

连接mongo
#

索引相关
#