排序算法没有绝对的“最强者”。快速排序很适合通用的内存排序，归并排序能够稳定地保证 O(n log n)，而计数排序、桶排序和基数排序则可以利用数据特征，在特定场景下接近 O(n)。
本文按照这些算法在实际开发中的常见程度大致排序。这个顺序不是严格排名：不同语言的标准库和不同业务场景会采用不同方案，而且实际排序函数通常会组合多种算法，而不是只使用一种纯算法。
文中的符号含义如下：
- n：待排序元素的数量。
- k：取值范围大小、桶数量，或单个位上的可能取值数。
摘要：消息队列（MQ）是分布式系统的基石，但“至少一次投递”的语义决定了消息重复是常态，幂等是必须。本文从重复消费的根源出发，深入剖析三种常见幂等策略（消费记录表、Redis+DB、数据库唯一索引）的适用场景与陷阱，并提供一套可落地的选型指南。
在生产环境中，我们几乎不可能保证消息“只被消费一次”。更常见的语义是 “至少一次投递（At Least Once）”，即消息可能被重复投递，消费者必须自行保证幂等性——多次消费同一条消息，最终的业务影响与消费一次完全相同。
路由选 RabbitMQ，可靠选 RocketMQ，海量选 Kafka。本文从 Broker 模型、存储机制、可靠性保障等维度，一次性讲透三款主流消息队列的核心差异。
消息队列（Message Queue）是分布式系统中解耦、异步、削峰填谷的核心组件。然而，面对 RabbitMQ、RocketMQ、Kafka 这三款主流产品，许多开发者在选型时常常陷入困惑：它们到底有什么本质区别？各自的适用场景是什么？
本文将从 Broker 队列模型、消费者模型、消息存储机制、可靠性保障 等维度，对这三款消息队列进行深度对比分析。
在大模型 ChatBot、AI Agent 等应用中，为了提供类 ChatGPT 的实时体验，服务端通常采用 SSE（Server-Sent Events）将模型生成的 Token 逐字推送到前端。典型流程为：用户提问 → 后端调用 LLM → LLM 持续生成 Token → SSE 实时推送 → 前端打字机展示。
然而，SSE 基于 HTTP 长连接，无法保证永久稳定。用户刷新页面、网络抖动、切换 WiFi、关闭标签页等行为都会导致连接断开。若不处理，用户将丢失未完成的生成结果，体验大幅下降。
核心问题在于：`SSE 断开后，如何让用户重连并继续接收未完成的输出？
当知识库规模达到百万甚至千万级别时，如果每次查询都需要与所有向量计算相似度，搜索效率会非常低。因此，在工程实践中通常会引入ANN（Approximate Nearest Neighbor，近似最近邻）算法，通过构建索引结构减少搜索范围。其中，HNSW（Hierarchical Navigable Small World，分层可导航小世界图）是目前应用非常广泛的一种向量索引结构。
常见框架：Mem0 、Letta（MemGPT）、 Zep（及其开源组件 Graphiti）
Agent三层记忆：
存什么、什么时候存、怎么存；
取什么、什么时候取、怎么取;
一句话概括：AOF 重写 = 子进程基于当前内存快照生成新 AOF + 父进程继续处理请求 + COW 保证快照稳定 + rewrite buffer 保证新写入不丢失。
Redis 的 AOF 持久化，本质是把每一条写命令追加到 AOF 文件里。比如客户端依次执行：
SET name zhangsan
SET name lisi
SET name wangwu# Langchain主要是agent、Message、chat_model、embedding、rate_limiters、tools这六个包
# from langchain.agents
# from langchain.messages
# from langchain.tools
# from langchain.chat_models
# from langchain.embeddings
# from langchain.rate_limiters[TOC]
记录第一次排查生成环境下，mysql CPU飚高100%占用，应用程序拖慢，记录，解决后占用降为正常。
A2A = Agent-to-Agent，是一套标准化的 Agent 间通信协议。它定义了 Agent 如何：