Chasing__Dreams的博客

原创 大模型应用开发--3--RAG--问题

原创 Kafka--基础知识点--20--消费者平衡协议的增量式重平衡协议

Kafka 的增量式重平衡协议（Incremental Rebalance Protocol），也称为（Incremental Cooperative Rebalancing），是一项旨在改进传统消费者组重平衡过程的重大优化。这项改进通过提案，从版本开始正式引入。它的核心目标，就是解决早期“停止-世界”（Stop-the-World，STW）式重平衡带来的服务中断问题。

原创 Redis--基础知识点--32--redis底层存储结构

在运行过程中是会动态扩缩容的。

原创 Mysql--基础知识点--113--innodb一张表最多适合2100万条数据的原因

你问的应该是和的区别（“B数”是笔误）。这两种都是平衡多路搜索树，广泛用于数据库和文件系统，但结构上有几个关键不同。

原创 Mysql--基础知识点--112--聚簇索引和非聚簇索引

你问的应该是和的区别（“B数”是笔误）。这两种都是平衡多路搜索树，广泛用于数据库和文件系统，但结构上有几个关键不同。

原创 Mysql--基础知识点--111--innodb中的change buffer为什么只针对非唯一二级索引

特性非唯一二级索引唯一索引是否需要实时查重不需要需要修改时能否延迟读页可以不可以(必须立即读页以验证唯一性)Change Buffer是否生效生效不生效典型优化场景大量随机插入、批量加载需保证字段值全局唯一的业务 (如用户ID、订单号)

原创 大模型应用开发--2--AGENT问题

主要有以下四种失败原因：

原创 大模型应用开发--0--知识点

大模型应用开发–1–AGENT问题

原创 分布式--4--雪花算法

雪花算法

原创 Redis--基础知识点--31--集群哈希槽为什么是16384？

不是“有了全局表就不需要位图”，而是两者从不同维度建模数据全局表是槽为中心（槽 → 节点），加速路由。位图是节点为中心（节点 → 槽集合），加速节点自身的判断、迁移和 Gossip 广播。内存占用上，每个节点多 2KB 完全可接受，带来的性能、网络和代码清晰度收益却很大。如果去掉位图，许多操作会变得笨拙且低效。

原创 Redis--基础知识点--30--Redis瓶颈

Redis 的性能极高（单机可达 10w+ QPS），但在实际生产环境中，瓶颈通常出现在以下几个层面，其中和最为常见。

原创 Redis--基础知识点--29--HyperLogLog

HyperLogLog 是 Redis 中一个非常轻量级的基数估算工具，它以 12KB 的固定内存和 0.81% 的误差，解决了海量数据去重计数的痛点。适用于 UV、独立 IP、唯一词条等场景，是在精确性和内存之间取得良好平衡的工程方案。了解即可好的，我们抛开官方术语，从最直观的概率小实验开始讲起，一步一步让你真正理解 HyperLogLog 是如何“算”出基数的。HyperLogLog 就像一个拥有 16384 个记分员的公司。

原创 Mysql--基础知识点--105--分布式事务

它在二阶段提交的基础上，采用本地undo log记录数据修改前后的状态，一阶段执行完后可立即释放锁和连接资源，吞吐量比XA模式更高。：TCC 将事务拆分为 Try（预留资源）、Confirm（确认提交）、Cancel（回滚释放）三个阶段，由业务代码实现每个阶段的接口，配合全局事务协调器（如 DTM）完成两阶段提交。所有示例中的 SQL 语句（INSERT、UPDATE、SELECT）均包含完整的表名和 FROM 子句，您可以直接在 MySQL 中执行建表语句后测试。命令实现两阶段提交。

原创 Mysql--基础知识点--104--大表添加字段

简单来说，两者都是通过创建临时表并复制数据来完成的。pt-osc就像在原来的办公室里增加了一个“触发器”小组来同步信息；而gh-ost则是另外拉了一根专线（Binlog）来负责信息同步。以上就是这两款主流工具的核心原理。如果你对其中某个步骤的细节，比如原子切换的具体实现或 Binlog 的应用过程，想有更深入的了解，我们可以随时继续探讨。

转载 Mysql--基础知识点--103--连接池

因为前面聊到过，所有的客户端连接都需要一条线程去维护，而线程资源无论在哪里都属于宝贵资源，因此不可能无限量创建，所以这里的连接池就相当于Tomcat中的线程池，主要是为了复用线程、管理线程以及限制最大连接数的。对于不同的机器配置，可以适当的调整连接池的最大连接数大小，以此可以在一定程度上提升数据库的性能。连接池的优化思想与Java线程池相同，会将数据库创建出的连接对象放入到一个池中，一旦出现新的访问请求会复用这些连接，一方面提升了性能，第二方面还节省了一定程度上的资源开销。

原创 Mysql--基础知识点--101--在线扩容

维度mysqldump备份原理逻辑导出 SQL物理拷贝数据文件 + redo log是否需要前滚/回滚不需要（MVCC 直接提供一致快照）需要（--prepare阶段）备份速度慢（尤其大表）快恢复速度慢（重放 SQL）快（直接拷贝文件）对主库影响较轻（有查询负载）较轻（有 IO 负载）是否支持增量备份否是额外依赖无需安装 Percona XtraBackup主从复制关键信息从backup.sql头部注释获取 binlog 位置从获取典型数据量< 50 GB> 200 GB维度备份方式。

原创 Mysql--基础知识点--102--redo log内容

下面以的 redo log 为例，给出一个典型的产生的 redo log 内容示例。

原创 Mysql--基础知识点--110--select ... lock in share mode VS select ... for share

简单来说，FOR SHARE是更现代、功能更强的写法。建议在新的开发工作中优先使用它。语法示例对比-- 旧语法 (仍可用，但不推荐)-- 新语法 (推荐使用)-- FOR SHARE 的高级用法示例 (连接查询中只锁定特定表，并设置等待策略)总结来说，FOR SHARE和的核心功能相同，但FOR SHARE提供了更灵活的锁控制能力，推荐在新项目中使用。

原创 Mysql--基础知识点--109--SERIALIZABLE事务隔离级别

SERIALIZABLE 通过让所有读操作都加锁来获得最高隔离性，但会严重限制并发，通常只在对数据一致性要求极高且写入很少的场景下使用。对于绝大多数应用，使用 InnoDB 默认的 REPEATABLE READ 即可获得足够的一致性保障。

原创 Mysql--基础知识点--100-- insert VS select...for update 加锁

维度INSERT核心目的插入新数据，保证唯一性与数据完整性锁定已有数据，防止并发修改/删除，并避免幻读表级意向锁✅ 加IX（意向排他锁），必加✅ 加IX（意向排他锁），必加自增锁✅ 可能有（表级 AUTO-INC 锁或轻量级互斥锁），取决于和语句类型❌ 无间隙锁通过插入意向锁）标记间隙，仅用于协调并发插入根据隔离级别和查询条件，可能加间隙锁X, GAP）或Next-Key 锁X），用于阻止幻读记录锁✅ 插入成功后加排他记录锁），锁定新行✅ 对扫描到的每一行加排他记录锁锁定对象。

原创 Mysql--基础知识点--99--两个线程同时给同一个间隙加锁 造成死锁的原因

隔离级别SELECT … FOR UPDATE (记录不存在时)能否避免死锁原因加间隙锁(Gap Lock)否间隙锁不互斥，允许多个事务同时持有，但它们都与插入意向锁互斥，从而形成等待环路导致死锁。不加锁是仅对存在的行加记录锁，从根本上杜绝了针对不存在记录的间隙锁冲突。对于这种后再INSERT的业务模式（通常称为），一个更推荐的解决方案是直接使用语句，这通常能在一条SQL内原子化地完成操作，既保证了并发安全，也无需在应用层编写复杂的加锁逻辑。

原创 Mysql--基础知识点--98--临键锁 VS 间隙锁

在 MySQL InnoDB 中，和。

原创 Mysql--基础知识点--97--UNION ALL VS UNION

特性UNION ALLUNION去重否是性能快（无额外操作）慢（排序/哈希去重）内存/临时表低高适用场景默认选择，除非必须去重明确需要全局唯一行最佳实践默认写UNION ALL。如果你写了UNION，请注释说明为什么需要去重。避免在生产查询中无意识地使用UNION，否则随着数据增长，性能会急剧下降。

原创 Mysql--基础知识点--96--count * VS count 列

需求正确写法错误写法（或更差写法）统计总行数（含 NULL）COUNT(*)COUNT(列名)（可能漏掉 NULL）统计某列非 NULL 行数COUNT(列名)COUNT(*)（结果不对）提高性能（总行数）COUNT(*)COUNT(1)（等价，但不推荐）最佳实践需要行数 →总是用COUNT(*)，语义清晰、性能最优。需要某列非 NULL 行数 → 明确使用COUNT(列名)。不要为了“看起来快”而用COUNT(1)或COUNT(主键)，它们和COUNT(*)性能相同，但可读性差。

原创 Mysql--基础知识点--95--为什么避免使用长事务

问题后果锁持有过久阻塞并发，响应变慢日志膨胀磁盘爆满，服务宕机回滚困难故障恢复时间长连接占用连接池枯竭主从延迟读不一致最佳实践：让事务尽可能短、快、小——仅将真正需要原子性的数据库操作放在事务内，完成后立即提交。

原创 Mysql--基础知识点--94.1--嵌套子查询转关联查询

嵌套子查询（Non-correlated subquery）是指子查询独立于外层查询，不引用外层的列。它先执行子查询得到结果集，然后外层查询利用这个结果集进行过滤或计算。关联子查询（Correlated subquery）是指子查询引用了外层查询的列，对外层每一行都要执行一次子查询（通常可以利用索引快速判断）。在某些场景下，将嵌套子查询改写成关联查询（如EXISTS或JOIN）可以大幅提升性能，避免子查询产生巨大的中间结果集，或者避免NULL带来的逻辑陷阱。写法子查询类型执行次数适用场景。

原创 Mysql--基础知识点--94--in vs exist

含义：选出至少有过一次订单的客户。原理：外层每行客户，子查询去orders表检查是否存在匹配的。优势：关联子查询 + 存在性判断，尤其适合大表关联小表，且只需判断“有没有”的场景。希望这个解释能帮你完全理解这条 SQL！如果还有疑问，欢迎继续追问。

原创 Linux--操作系统--7--IPC、RPC

很多 RPC 框架底层会使用 TCP/HTTP 等网络协议，并在其上封装序列化、服务发现、负载均衡等能力。现代微服务架构中，gRPC 和 Thrift 是使用最广泛的跨语言 RPC 框架。

原创 python--设计模式--13.1--结构性--享元模式

享元模式是一种结构型设计模式，通过共享技术来支持大量细粒度对象的复用。它的核心思想是：当系统中存在大量相同或相似的对象时，只创建一个共享实例，而不是为每个使用场景都创建新对象。享元模式（Flyweight Pattern）实际应用示例: 文字处理器（字符共享）

原创 Go--2--垃圾回收

深入 Go 语言核心：垃圾回收（三色标记法）

原创 python--基础知识点--协程的一些疑问

原创 kafka--基础知识点--19--消息重复

acks = 1 或 -1，当消息已经写入leader或ISR中的folloer后，brocker给生产者发送确认响应后发送网络抖动或leader崩溃又崩溃重启，生产者发现没有确认响应再次发送，导致消息brocker中出现了两条重复的消息，重复发送导致。解决: 精确一次发送方案 = (acks=-1) + 事务 + 重试。

原创 kafka--基础知识点--18--消息积压

消息积压的原因: 生产者生产速度持续性大于消费者消费速度。

原创 kafka--基础知识点--6.4--LSO

有两个生产者将消息发往同一分区，一个是事务生产者，一个是非事务生产者；该分区的消费者设置参数isolation.level=read_committed。LSO: LastStableOffset，分区中第一个未完成事务的起始偏移量，或如果没有未完成事务则为HW。

原创 kafka--基础知识点--6.3--leader epoch机制

在 0.11.0.0 版本之前， Kafka使用的是基于HW的同步机制，这种会在故障恢复时出现和的情况。请看中的和两部分。

原创 kafka--基础知识点--3.2--消息的磁盘存储文件结构

每个分区实际上由多个日志段（LogSegment）组成。日志段是Kafka数据存储的最小单元，包括一个日志文件（存储消息）和两个索引文件（偏移量索引和时间戳索引）。例如，假设日志段的BaseOffset是100，那么偏移量105的索引条目中，相对偏移量为5，物理位置为1050（表示从日志文件的第1050字节开始）。日志段不会无限增长，当达到一定条件时会滚动创建新的日志段。消息格式（V2版本，Kafka 0.11.0之后）主题（Topic）和分区（Partition）消息批次（RecordBatch）

原创 kafka--基础知识点--3.1--生产者架构

在生产端主要有两个线程：main和sender，两者通过共享内存RecordAccumulator通信。

原创 kafka--基础知识点--17--如何保证顺序消费

Kafka本身不保证整个Topic的全局消息顺序，但能保证单个分区(Partition)内的消息是有序的。这就像一个快递站，所有包裹（消息）都先送到总站(Topic)，但总站内部会分给不同的快递员（分区）去送，每个快递员手里的包裹顺序是固定的，但不同快递员之间的顺序就乱了。

原创 kafka--基础知识点--9.1--consumer 至多一次、至少一次、精确一次

Kafka 消费者后台线程每隔 auto.commit.interval.ms 自动提交最近一次 poll() 的 offset无需开发者干预。

原创 kafka--基础知识点--5.3--producer事务

【代码】kafka--基础知识点--5.3--producer事务。