- 博客(169)
- 收藏
- 关注
RSS订阅原创 Kafka 不背锅：中高级 Go 程序员最容易犯的错，你中几个？
Kafka作为现代分布式系统的核心消息队列，具有高吞吐和可扩展性，但开发过程中存在诸多“暗坑”。本文针对中高级Go工程师，总结了Kafka使用中的常见误区，重点分析了生产者配置和消费者组管理两大问题。 在生产者配置方面，错误设置acks、重试策略等参数可能导致消息丢失、重复或乱序。典型错误包括使用acks=1、关闭幂等性、未启用批量发送等。正确做法应配置acks=all、开启幂等性、合理设置重试策略，并采用单例Producer并发发送，同时监控发送结果和正确处理关闭流程。 消费者组管理方面，忽视再平衡事件、
2025-10-25 19:00:00
823
原创 Kubernetes 之海，Go 之舟：避开那些吞噬性能的隐形暗礁
本文深入探讨了在Kubernetes上部署Go程序的隐藏陷阱，重点分析了三个关键问题：Goroutine并发与资源泄漏、优雅停机与信号处理、Go Runtime与容器资源限制。在并发场景下，Goroutine泄漏、不受控并发、数据竞争等问题可能导致资源耗尽或服务雪崩；在信号处理方面，PID 1的特殊行为、终止流程顺序等问题可能引发请求丢失；而容器资源限制与Go Runtime的交互则可能导致意外的OOM或CPU节流。文章通过真实案例揭示了这些"看似正确"却暗藏风险的细节，并提供了针对性的
2025-10-11 23:30:00
905
原创 WebRTC 探秘：构建你自己的实时视频应用
**WebRTC是一项开源技术标准，通过浏览器原生API实现实时音视频和数据通信，无需依赖插件。其核心功能包括安全加密的点对点连接、低延迟传输（100-300毫秒）和NAT穿透能力。虽然采用P2P架构，但仍需信令服务器、STUN/TURN服务器辅助建立连接。WebRTC已广泛应用于视频会议、远程医疗、在线教育等领域，其架构包含信令平面、SDP媒体协商、ICE框架等关键组件，通过STUN/TURN服务器解决网络穿透问题，TURN服务器作为备用方案会显著增加运营成本。该技术重新定义了服务器在实时通信中的角色，使
2025-09-19 23:30:00
815
原创 上下文工程：从“炼金术”到“方法论”，构建高确定性AI系统的核心引擎
摘要： 《上下文工程：构建高确定性LLM应用的方法论》深入探讨了如何通过系统化信息管理提升大型语言模型的可靠性。核心在于选择、组织和投递关键信息，而非依赖提示词技巧。文章提出三大设计原则：最小必要上下文（避免噪声干扰）、证据可核验（确保答案可追溯）、显式契约化输出（结构化+工具调用）。同时剖析了六大反模式（如盲目扩展Top-K、仅用向量检索等），并给出带约束条件的完整落地案例。该框架平衡了效果、成本与合规性，为企业级AI应用提供了可复用的工程范式。
2025-08-30 11:30:00
1287
原创 Go 程序员的 LoRA 指南：为 AI 巨擘打上“补丁”
摘要：LoRA——高效定制大型语言模型的轻量级补丁方案 大型语言模型(LLM)的完全微调面临三大挑战：高昂计算成本、存储管理难题和部署灵活性差。LoRA（低秩适配）创新性地采用"动态补丁"思路，通过冻结预训练模型参数，仅训练注入的低秩适配器模块（ΔW=BA），实现了高效模型定制。该方法将参数更新量压缩为两个小矩阵乘积（如8×4096和4096×8），使训练参数量锐减250倍以上。最终产出仅需存储几十MB的适配器文件，而非完整的模型副本。LoRA特别适用于Transformer的自注意力机
2025-08-22 23:15:00
1631
原创 Go map 的性能革命：深入解析从链表到 Swiss Table 的优化之路
Go 1.24版本对map数据结构进行了重大优化，从传统的"哈希桶+链表"结构升级为Swiss Table实现。传统方案通过哈希桶存储键值对，使用tophash预筛选和溢出桶处理冲突，但存在缓存不友好、内存碎片化和删除效率低等问题。Swiss Table采用元数据与数据分离的设计，使用控制字节数组快速定位数据槽位，显著提升了CPU缓存利用率。这种连续内存布局减少了指针跳转和内存分配开销，同时优化了删除操作的处理效率。新设计通过更现代的数据结构大幅提升了map操作的性能和内存使用效率。
2025-08-09 10:45:00
1286
原创 【硬核拆解】你的代码还在 `if-else` 走天下？是时候深入规则引擎了！
本文深入探讨了规则引擎的核心原理与应用价值。规则引擎通过将业务逻辑与代码解耦，解决了传统if-else结构带来的维护困难、响应迟缓等问题。其核心工作流程是"匹配-解决-执行"循环，采用Rete算法实现高效模式匹配。该算法通过构建Alpha和Beta网络，实现了增量计算和智能匹配，大幅提升了规则执行效率。文章以电商促销场景为例，展示了规则引擎如何将复杂业务规则转化为可维护的决策系统，显著提升业务敏捷性。
2025-08-09 00:42:50
995
原创 AI 记忆管理系统：工程实现设计方案
本文提出了一套新一代AI记忆系统的工程实现方案，采用分层微服务架构，通过RESTful API与上层应用交互。系统分为工作记忆(Redis)、偏好/画像(PostgreSQL)、情节记忆(向量数据库+PostgreSQL)和语义知识库(向量数据库+PostgreSQL)四个层级，实现读写分离。读取路径采用意图分析路由+并行检索+上下文融合的三步流程，支持缓存优化和轻量级分类器预筛；写入路径通过消息队列异步处理。技术选型上结合了Redis的低延迟、关系型数据库的强一致性以及向量数据库的语义检索优势，并采用Py
2025-08-08 21:45:00
1169
原创 从毫秒到真义：构建工业级RAG系统的向量检索优化指南
摘要： 本文提出构建一个高性能企业级RAG（检索增强生成）系统的四阶段框架，旨在1秒内精准检索200万页文档信息。第一阶段聚焦数据预处理，包括语义分块和嵌入模型微调；第二阶段通过降维量化（如IVF-PQ）优化索引存储；第三阶段实现混合检索与智能排序；第四阶段进行系统工程优化。关键创新点包括领域自适应的嵌入微调、量化压缩技术（256维向量可压缩至原体积1/24），以及分层检索架构，在有限算力下实现毫秒级响应。该系统如同"信息高铁"，通过精细化数据工程与算法协同设计，平衡精度与效率，为企业知
2025-08-02 13:30:00
1189
原创 从“健忘”到“懂我”：构建新一代AI记忆系统
AI记忆管理系统的分层设计与读写分离 本文提出了一套分层、动态的AI记忆管理系统，旨在解决现有AI助手的“健忘症”问题。系统采用分层记忆架构（工作记忆、情节记忆、语义记忆、偏好记忆）和读写分离机制，实现了关键信息的精准唤醒与高效存储。工作记忆通过滚动窗口和层级摘要维持对话连贯性；情节记忆采用向量检索+元数据过滤记录事件；语义记忆通过RAG机制存储可信知识；偏好记忆沉淀用户画像。系统通过意图分析路由查询，并在响应后通过写入门控筛选有价值信息存入长期记忆。这种设计在保证响应速度的同时，实现了记忆的精准沉淀与更新
2025-07-31 22:02:26
860
原创 高并发流式语音合成管线：分片、调度与秒级响应
摘要：本文探讨了实时语音交互面临的三大核心挑战——增量文本处理、低延迟要求和高并发管理，并提出了一套基于差分感知的四层流式语音合成管线架构。该架构通过语义缓冲层精准识别文本变化，增量TTS编排层并行合成以降低延迟，供应商适配层统一管理多供应商资源，音频缓冲层实现无缝拼接。关键技术包括最长公共前缀策略、字符级Diff算法、投机性并行请求和动态降级机制，最终在保证语音自然度的同时，实现了500ms内的首包延迟和高效资源利用。
2025-07-27 11:45:00
918
原创 从 Attention 到 Multi-Head：Go 工程师也能看懂的大模型注意力机制全解析
本文为Golang程序员详解注意力机制（Attention Mechanism）的核心原理。文章首先通过键值对存储的类比，引入注意力机制中Query-Key-Value（QKV）三元组的概念，解释模型如何通过相关性分数动态关注上下文信息。核心部分深入剖析缩放点积注意力的计算过程，包括分数计算、Softmax归一化和加权求和三个步骤，并用缓存命中率类比注意力权重分配。最后介绍进阶的多头注意力机制（Multi-Head Attention），通过并行化多个注意力"头"来捕捉更丰富的语义特征。
2025-07-27 10:50:41
838
原创 架构演进：为“AI语音伴侣”构建永不中断的实时通信网关
这意味着网关不仅要能将后端的 AI 响应精确路由到连接在任意 Pod（Kubernetes 最小部署单元）上的用户，还必须能在服务更新、扩缩容导致 Pod 实例生灭时，让用户的对话无缝迁移，不丢失任何上下文，实现真正的“永不中断”服务。本文将以(Real-Time Communication Gateway) 为例，沿着一条清晰的方案演进路径，层层递进，最终解决这个核心挑战。
2025-07-26 15:00:00
600
原创 从 Redis 和 MySQL 到向量数据库：你的下一代数据存储利器
文章摘要：向量数据库是AI时代的新型数据库，专注于语义相似性搜索而非精确匹配。其核心流程包括：通过Embedding模型将数据转换为向量，存储并建立索引，利用近似最近邻算法(ANN)快速查询相似结果。与传统数据库不同，向量数据库在CRUD操作上存在显著差异，如写入吞吐较低、更新成本高、删除异步处理等。常用索引算法包括HNSW、IVF和PQ，各具性能权衡。向量数据库适用于语义搜索、推荐系统等场景，但需注意其与传统数据库在功能和设计哲学上的区别。
2025-07-21 22:11:18
1166
原创 状态压缩与前缀和的魔力：破解LeetCode 1371元音之谜
摘要：本文详细解析了LeetCode 1371题"每个元音包含偶数次的最长子字符串"，提出了一种高效的状态压缩+前缀和+哈希表的解法。通过将元音奇偶性压缩为5位二进制状态，利用XOR运算动态更新状态，并使用哈希表记录状态首次出现的位置，可以在O(N)时间复杂度内解决问题。相比暴力法的O(N³)复杂度，这种方法显著提升了效率。文章还总结了识别类似问题的关键特征（奇偶性、多元素状态）和通用解题框架，强调状态压缩与前缀思想的巧妙结合。核心技巧在于初始化seen = {0: -1}和利用mask
2025-06-18 22:51:40
1059
原创 优化了个寂寞：当“聪明”反被“聪明”误，那些让人哭笑不得的性能调优
性能优化的旅程，既有成功的喜悦，也免不了“优化了个寂寞”的苦涩。但正是这些“寂寞”的时刻，让我们对代码、对系统、对优化的本质有了更深刻的理解。所以，下次当你又想“秀操作”进行一番“神级优化”时，不妨先冷静一下，祭出分析器和基准测试这两大法宝。记住，我们的目标是创造卓越的软件，而不仅仅是追求微秒级的数字游戏。别让你的聪明才智，最终只换来一声“唉，又优化了个寂寞”的叹息。祝你的优化之路，少点寂寞，多点星光！
2025-05-30 15:10:33
783
原创 为什么kafka放弃了zookeeper呢？
例如，可以更灵活地设计 Broker 间的交互协议，或者探索更高级别的集群管理功能，而不必考虑如何将其适配到 ZooKeeper 的模型中。用内部的 Raft 协议和日志存储替换它，虽然 Raft 本身也复杂，但将复杂性控制在了 Kafka 内部，交互逻辑更直接。Kafka 和 ZooKeeper 拥有不同的部署模型、设置和工具，增加了初次部署和后续支持的复杂性。Kafka 和 ZooKeeper 之间的通信并非无缝，可能导致元数据更新延迟甚至丢失，这对延迟敏感的应用是不利的。
2025-04-20 19:47:24
693
原创 如何实现一个MCP server呢？
以github.com/mark3labs/mcp-go为例开始以一个简单的查看文件列表工具作为范例，来展示该如何开发mcp server。
2025-04-19 11:18:40
630
原创 Kafka负载均衡挑战解决
本文为阅读笔记kafka通过利用分区来在多个队列中分配消息来实现并行性。然而每条消息都有不同的处理负载，也具有不同的消费速率，这样就有可能负载不均衡，从而使得瓶颈、延迟问题和整体系统不稳定，进而导致额外的维护工作或额外的资源分配。在 Kafka 中，分区器和分配器策略会影响消息分发。Producer 分区器Consumer 分配器这些策略都是基于两个主要的假设。
2025-04-07 23:54:14
1075
原创 RAG了解与实践
RAG(Retrieval-Augmented Generation) 是一种授予生成式人工智能模型信息检索功能的技术。它修改与大型语言模型的交互 （LLM），以便模型响应用户对一组指定文档的查询，使用此信息来增强从其自身庞大的静态训练数据中提取的信息。这允许LLMs使用特定于域和/或更新的信息。可以简单理解为"检索+生成"的人工智能技术。想象你正在做一个复杂的研究项目，除了大脑里已有的知识，你还需要查阅额外的资料来提高回答的准确性和深度。RAG就是AI模型的这个"查阅资料"过程。
2025-03-06 22:34:55
1172
原创 Redis 实现延迟队列的方案
在分布式系统中，延迟队列是一种常见的需求，例如订单超时取消、任务定时执行等。Redis 作为高性能的内存数据库，提供了多种实现延迟队列的方案。本文将介绍几种不同的 Redis 方案，并分析其优缺点及适用场景。
2025-03-04 23:34:51
733
原创 流式抽样唯一元素方案设计
根据不同的应用场景和需求，可以选择不同的流式抽样方案。如果需要高效且简单的实现，可以考虑确定性哈希抽样或布隆过滤器方案；如果对数据量和性能有更高要求，Redis HyperLogLog和分层采样则是更合适的选择；对于需要时间维度分析的场景，可以使用时间窗口 + 一致性哈希方案。
2025-02-27 23:19:53
947
原创 啥是滚动哈希？
滚动哈希（Rolling Hash）是一种，允许在时间内计算的哈希值，而不需要重新遍历整个子串。它常用于字符串匹配、子串查找等问题，比如就是基于滚动哈希的。在说滚动哈希方法之前，先谈谈一般窗口内哈希值是如何计算的例如对于字符串hello，那么哈希值是hashCodehelloh−a∗pow1310e−a∗pow1311l−a∗pow1312l−a∗pow1313o−a∗pow1314。
2025-02-20 23:35:02
907
原创 实验流量统计设计
当我们需要统计实验中每个分支的实际进入次数时，如何设计一个高效、可靠且对业务影响最小的方案，成为了关键。以下是几种常见的流量统计方案的分析与实现设计目标。
2025-02-20 22:48:24
986
原创 如何检测一次性流水线任务处理完成呢？
在任务处理过程中，特别是在多阶段、多线程的流水线任务中，如何检测所有任务是否已经完成是一个常见且关键的设计问题。流水线任务通常涉及多个环节，如管理器、请求器、转换器、导出器等，每个环节处理完毕后将结果传递给下一个环节。当所有环节都完成处理后，任务才算真正完成。本文将探讨几种检测流水线任务处理完成的常见方案，分析其实现步骤、优缺点和适用场景。
2025-02-15 16:14:11
710
原创 高并发读多写少场景下的高效键查询与顺序统计的方案思路
之前在某平台看到一篇有意思的场景——对于高并发读多写少场景下，如何进行高效键查询与统计早于其创建时间且没有被删除的数量（只需要先入先出，不需要从中间删元素）传统的数据库索引或简单的哈希存储难以同时满足这两个需求，尤其是在高并发环境下，如何在不影响查询效率的前提下维持顺序统计成为关键挑战。
2025-02-09 23:36:18
577
原创 elasticsearch是如何进行搜索的？
以 TF - IDF 为例，如果文档中某个词出现的频率高（词频高），但在整个语料库（索引中的所有文档集合）中该词比较少见（逆文档频率高），那么这个词所在的文档相关性得分就会相对较高。例如，在一个美食相关的索引中，如果 “全聚德烤鸭” 这个词在某篇介绍全聚德的文档中多次出现，而在其他文档中很少出现，那这篇文档在以 “烤鸭” 为查询词时相关性得分就会比较高。是一个不变的、独立的倒排索引，储存了文档的字段、倒排表、储存字段以及其他索引元数据。分片会从它的所有 Segment 中收集匹配的文档，并按相关性排序。
2024-12-03 21:49:34
588
原创 Redis集群节点如果出现故障了，会如何处理呢？
此外在哨兵故障检测之外还存有节点自检，目的在于确保节点间通信正常，维护集群状态。以保证其他主节点知晓该主节点已经下线，并且防止从节点同时启动选举。如果手动配置新主节点或者槽迁移恰好碰上了故障选举，使得同一选举期存在多个主节点，那么该如何处理冲突呢？从节点会计算选举期，若获取的票不在本轮选举中，则不会进行计数。NodeID字典序更小的节点将成为唯一的主节点，并递增选举期。若故障节点为主节点，集群尝试从主节点的从节点中选取新主节点。会不会存在一个从节点收到了同主节点的两轮选举的投票呢？主节点在投票一次后，在。
2024-11-23 15:17:48
996
1原创 本地缓存少更改、小数据、低一致表的思考
对于那些少更改、小数据的表，以及对一致性要求不高的业务，其实完全可以通过本地缓存将表数据缓存到本地内存中，然后通过定时机制拉取表更新数据直接从内存中获取数据，将会使得查询性能得到巨大的提升，并且由于更改少，数据量小，同时内存压力也不会很大，除了一致性不高外，完全是利大于弊的策略那么如果我想设计这样的本地缓存，该如何进行呢？
2024-10-21 23:53:35
530
原创 从automaxprocs库浅窥Linux容器的资源控制
automaxprocs能够自动调整Go程序中的Goroutine数量，以充分利用系统资源并提高程序的性能。automaxprocs通过读取系统信息，如CPU核心数和Cgroups限制，来动态调整Goroutine的数量automaxprocs获取CPU限额的关键方法在可以看到是先获取到cgroup的实现，然后调用实现方法获取限制获取cgroup2实现如下具体算限制方法如下其实就是取cpu.max文件中指定的限额。
2024-10-11 22:51:40
1084
原创 mysql json查询为什么这么快？
在本地测试中我发现了一件令我惊讶的事情，在300w数据量对json字段里面值进行筛选的时间都在100ms左右！那么为什么mysql json查询这么快呢？
2024-09-01 12:23:23
1276
原创 如何设计数据库排序字段
在很少会有中间插入或者对查询排序有较高要求的情况：较短间隔的int是更优的方法在中间插入情况较多的时候：可能float类型更为合适链表方法在插入情况较多的时候也是非常适用的，可是查询性能属实太差数据量少：可以用配置文件或者直接在缓存中设置排序。
2024-08-31 09:52:18
779
原创 GO goroutine状态流转
go池是所有拥有goroutine的地方，包括P的runnext、P本地队列和全局队列Gidle -> Grunnable: 初始化g，放入go池Grunnable -> Grunning: 从go池取出，绑定M，执行实际代码Grunning-> Gdead: 解绑M，重置g，重新放入go池-> Gwaiting: 解绑M，等待被唤醒-> Grunnable: 解绑M，放入go全局队列Gwaiting -> Grunable: 被唤醒后放入go池。
2024-08-01 22:42:20
1212
原创 go内存返还系统相关代码
在go中内存返还系统相关代码主要由sysUnusedOS实现在Linux中默认是通过madvice方法的_MADV_FREE进行释放，在这种释放中内存其实是被延迟回收的。sysUnusedOS被scavengeOne调用，scavengeOne在给定的内存块（chunk）中搜索可回收的连续页面，并尝试回收指定数量的内存值得注意的是，在回收之后内存还是可以再次分配的scavengeOne继而被scavenge调用该过程分块进行，从最高地址开始，一直持续到清除指定字节数(nbytes)或耗尽堆。
2024-07-05 21:00:00
939
原创 Golang栈空间管理
连续栈核心原理是当当前栈内存不足时，会触发中断，从而分配更大充足的栈空间，并迁移原栈内容到新栈。此外，除了扩容，连续栈还会在已使用的栈空间未超过了总可用空间的四分之一，将新栈收缩到原来的一半。在Go1.3之前，所有goroutine在初始化时都会分配一块固定大小的内存空间。分段栈能够按需为当前goroutine分配内存，并及时减少内存占用，但。迁移过程会被指针也同样迁移过来，不过没关系根据逃逸分析不变性——，所以指向栈中变量的指针只能在栈上。与堆类似，栈也有全局和局部栈空间。
2024-07-05 20:30:00
471
原创 Go堆内存管理
heapArena: heapArena 是由 mheap 管理的更小的内存块。按 Span class 对 Span 分类，串联成链表，当 mcache 的某个级别 Span 的内存被分配光时，它会向 mcentral 申请 1 个当前级别的 Span。微分配器将多个微小块分配请求合并到同一个内存块中，只有当内存块中的所有对象都需要被回收时，整片内存才可能被回收。mcache: 每个P所有的cache，包含多个空闲内存块链表，不同的链表上的内存块大小可能是不相同的。Go按照不同对象大小有不同的分配逻辑。
2024-07-05 14:48:04
937
原创 Linux文件数据写入
结构体fdfd也就是文件描述符，用于标识已经打开的文件、管道、socket等。是进程和内核的桥梁，允许进程执行各种文件操作struct fd { struct file *file; unsigned int flags;};fileLinux内核中表示打开文件的结构体，包含了文件操作所需的各种信息和元数据。这是文件系统操作的核心结构之一，允许内核跟踪每个打开的文件及其相关的状态。struct file { // 用于链接或者引用计数 union { // 链表节点
2024-07-02 22:45:00
1878
原创 Linux自旋锁
面对没有获取锁的现场，通常有两种处理方式。本文主要讲述自旋锁自旋锁其实是一种很乐观的锁，他认为只要再等一下下锁便能释放，避免了操作系统进程调度和线程切换。
2024-06-17 21:15:00
1540
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人