自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(70)
  • 收藏
  • 关注

原创 从 Loop 到 Graph:AI 智能体两大工程范式深度解析

摘要:本文深入解析AI智能体领域的Loop Engineering(循环工程)与Graph Engineering(图工程)两大工程范式。首先厘清了与向量嵌入技术(Embedding)的区别,指出前者属于数据表示层,后者是Agent系统架构方法论。循环工程聚焦单个智能体的自主闭环系统,通过五层闭环和六大设计要素实现任务自动化,但存在上下文腐烂等固有缺陷。图工程则通过多单元协同编排(节点、边、状态、策略)解决复杂任务,支持并行、验证和人工介入,但带来更高复杂度与成本。

2026-08-18 00:05:33 398

原创 彻底吃透 Harness 工程:Claude Code 企业级智能体底层架构全拆解

文章摘要:本文系统解析了支撑生产级AI智能体的Harness工程体系,提出十二层模块化架构设计,从基础循环到多智能体协作逐层递进。该体系通过工具权限管控、任务锚定机制、上下文压缩、异步任务等核心技术,构建安全可控的智能体运行环境,实现业务逻辑与底层框架的彻底解耦。其核心设计哲学强调"环境赋能智能"而非硬编码规则,采用分层防御机制保障稳定性,通过极致解耦适配长期迭代,为区分Demo级与工业级智能体提供了系统化工程方案。

2026-08-17 23:56:03 410

原创 什么样的评测集才算是“能打”的?

文章摘要: 本文探讨了如何构建有效的RAG系统评测集,提出评测集的核心目标是暴露系统短板而非追求高分。作者指出优质评测集需具备四个关键特征:1)题型丰富多样,覆盖简单查询、多跳推理、模糊提问等场景;2)严格贴合业务领域,避免使用通用数据集;3)确保标准答案(Ground Truth)的准确性和结构化;4)支持多环节诊断(检索/生成)。文末提供自检清单,强调评测集的价值在于"精准"而非"题量",需同时考察系统回答能力和拒答机制。

2026-07-19 23:32:16 219

原创 RAG 评测数据集,到底该怎么准备?

本文探讨了RAG评测数据集准备的核心方法。数据集准备分为两个关键部分:获取"题目"与"标准答案",以及收集RAG系统的"实际作答"。 获取"题目"主要有两种途径:1) 让LLM基于知识文档自动生成问题和标准答案;2)从历史交互数据或专家构建中获取真实问题和答案。但仅此还不够,必须再将这些问题输入RAG系统,才能获得系统生成的AI回答和实际检索到的参考资料。 特别注意:自动生成数据集中的"参考资料"是生成标准答案的依据,而评测检索质量所需的"参考资料"必须是RAG系统实际检索到的内容,二者不能混淆。

2026-07-19 23:22:23 274

原创 RAGAS 评测分数不稳定?5 种方案抑制 LLM 裁判幻觉与波动

摘要 本文针对RAGAS评测分数不稳定的问题,分析了LLM裁判范式的两大核心原因:指标设计边界(如Answer Relevancy仅衡量切题性而非完整性)和LLM本身的随机性与幻觉特性。提出了五级优化方案:1)扩大测试集规模取均值(零成本必做);2)固定temperature和seed降低随机性(零成本);3)多次评估取平均(中等成本);4)更换更稳定的评估模型(有成本);5)人工抽检兜底(必备环节)。强调正确理解指标边界,按优先级实施优化,并理性看待自动化评测的工具属性。

2026-07-18 21:47:14 323

原创 RAGAS 框架与实现原理

RAGAS 的本质是LLM 语义判断 + 数学统计计算的结合。大模型负责做语义层面的 “好不好、对不对” 的判断,再用经典的信息检索指标(Precision、Recall、F1)做量化,最终输出稳定可对比的分数。

2026-07-18 21:36:43 452

原创 LLM-as-a-Judge 与四大主流 RAG 评测框架

本文介绍了LLM-as-a-Judge(大模型作为裁判)的核心评估范式及其在RAG(检索增强生成)评测中的应用,并详细分析了四大主流RAG评测框架的特点和适用场景。传统评测方法如BLEU/ROUGE、人工评估和规则匹配在RAG场景下存在效率低、准确性不足或灵活性差的问题。LLM-as-a-Judge通过使用高性能大模型自动评估语义质量,解决了规模化与语义理解的矛盾,支持无参考和有参考两种评估模式。

2026-07-18 21:17:06 459

原创 RAG 系统评测全梳理:三元组方法论 + 分层指标体系

本文系统梳理了RAG(检索增强生成)系统的评测体系与方法论。核心观点指出,RAG评测是区分"Demo可用"与"生产落地"的关键门槛,需贯穿开发全周期。文章提出RAG Triad三元组方法论(上下文相关性、忠实度、答案相关性),实现无需人工标注的自动化评估。评测体系分为三层:检索层(召回率/精准率等)、生成层(忠实度/答案相关性等)、端到端工程层(性能/成本/安全)。通过分层指标可精准定位系统瓶颈,平衡效果与落地性。强调生产级RAG必须建立标准化评测,避免"碰运气式"开发,尤其对医疗金融等高危场景至关重要。

2026-07-18 21:00:54 241

原创 读懂 Harness,掌握智能体工程化的核心骨架

文章摘要: AI Agent 技术正从提示词优化(Prompt Engineering)迈向Harness Engineering阶段,核心观点为Agent = Model + Harness,即智能体需结合大模型与外围工程体系(工具调用、记忆存储、任务规划等)才能落地应用。Harness 包含七大核心组件: 工具+执行循环(赋予行动能力); 记忆+规划(持久化存储与任务拆解); 规则+技能+MCP工具(知识注入与行为约束); 子Agent; 多Agent团队; 上下文压缩;安全钩子+Ralph Loop等

2026-06-07 23:24:13 354

原创 从Demo到生产落地:9种RAG架构逐级演进,搞定企业AI知识库全场景

摘要:企业级RAG架构演进全解析 本文系统剖析了企业级RAG(检索增强生成)架构从Demo到生产落地的9种演进路径。针对90%的RAG项目"PoC能跑,生产必崩"的痛点,作者指出生产级RAG需要从简单的检索技巧转变为涵盖数据处理、检索编排、查询优化等全链路工程体系。文章提出了生产级RAG的八大分层架构和六大硬性标准,强调多维评估体系的重要性。重点解析了9种RAG架构的特点、适用场景和生产级代码实现,从最基础的Naive RAG到支持复杂推理的高阶架构,为企业AI知识库建设提供了完整的解决方案和演进路线。

2026-06-07 02:47:28 561

原创 SpringAI + SpringDoc + Knife4j 构建企业级智能问卷系统

文章摘要 本文介绍如何基于Spring Boot 3、Spring AI、SpringDoc和Knife4j构建企业级智能问卷系统。系统设计目标包括低耦合、高并发、可扩展和可治理能力,核心功能涵盖问卷模板管理、AI智能生成、答卷解析和高并发答题等。文章详细阐述了技术选型理由,包括Spring Boot 3的现代化特性、Spring AI的模型抽象能力以及SpringDoc+Knife4j的文档治理优势。系统采用四层架构设计,通过模块化拆分实现业务解耦,并提供了数据库表结构示例。

2026-04-23 00:33:36 471

原创 Elasticsearch 生产环境全栈最佳实践:从架构设计到故障排查一站式落地指南

本文全面总结了Elasticsearch生产环境落地的最佳实践,涵盖集群架构设计、JVM优化、索引管理、性能调优等关键环节。针对不同规模集群提供了节点角色规划与硬件配置建议,详细阐述了JVM内存分配和GC调优策略,并深入解析了索引分片、Mapping设计等核心优化方法。文章还提供了可直接复用的配置模板和代码示例,帮助开发者构建高性能、高可用的ES集群,避免常见生产环境问题。

2026-03-19 01:13:15 597

原创 Elasticsearch 实战系列(二):SpringBoot 集成 Elasticsearch,从 0 到 1 实现商品搜索系统

本文是Elasticsearch实战系列第二篇,详细介绍如何在SpringBoot项目中集成Elasticsearch,实现商品搜索系统。主要内容包括:ES Java客户端选型建议,重点推荐Spring Data Elasticsearch;环境准备中的版本匹配关系;通过注解方式定义商品实体类与ES索引的映射;以及分层架构设计思路。文章提供了完整的Maven依赖配置和YAML配置文件示例,帮助开发者从零开始构建ES集成方案,涵盖基础CRUD到复杂搜索功能的全流程实现。

2026-03-19 00:58:32 714

原创 Elasticsearch 实战系列(一):从核心基础概念入门到实战落地

本文介绍了Elasticsearch的核心概念与应用场景。首先阐述了ES作为分布式搜索分析引擎的特性,包括高可用架构、近实时检索和强大的全文搜索能力。通过与MySQL的对比,明确了ES适用于全文检索、日志分析等场景。重点讲解了ES的核心概念:索引(类比数据库)、文档(类比数据行)、映射(定义字段类型)以及分片机制(实现水平扩展)。最后提供了版本选择建议,推荐使用7.17.10稳定版。全文帮助开发者快速理解ES的核心功能与适用场景。

2026-03-19 00:45:13 619

原创 利用SpringCloud Gateway 重试 + 降级解决第三方接口频繁超时问题,提升性能

本文介绍了在SpringCloud Gateway层实现统一重试+降级方案的完整实践。针对第三方接口不稳定的问题,传统业务层重试存在代码重复、逻辑分散、无降级兜底和POST请求无法重试等四大缺陷。通过Gateway层的统一处理,可以无侵入地解决这些问题。方案核心包括请求体缓存机制(解决POST重试难题)、指数退避重试机制和异常降级兜底机制,形成完整的闭环。重点实现了请求体缓存过滤器,通过装饰请求支持重复读取,同时设置合理的缓存策略防止内存溢出。该方案显著提升了微服务架构下对接第三方接口的稳定性。

2026-02-25 23:56:55 889

原创 消息队列消费性能优化:批量消费 + 手动 ACK 提升吞吐量

摘要:本文针对高吞吐场景下消息队列消费效率低下的问题,提出"批量消费+手动ACK"优化方案。通过分析传统单条消费模式的四大痛点,对比两种方案的核心差异,详细阐述了批量消费机制、手动ACK机制和消费节奏控制三大模块的设计思路。文章提供了基于Spring AMQP的完整实现方案,包括服务端核心逻辑和客户端监控系统,并总结了批量大小设置、等待时间优化等5个关键实践要点。该方案经实际验证可将消费速度提升10倍,CPU使用率降低60%,显著提升系统吞吐量和稳定性。

2026-02-22 23:58:11 922

原创 千万级数据批处理实战:SpringBoot + 分片 + 分布式并行处理方案

本文提出了一种基于SpringBoot和分布式协调的高性能并行处理方案,用于解决千万级数据批处理的性能瓶颈问题。传统单线程批处理存在效率低、资源浪费、容错差等痛点。该方案采用"分而治之"思想,通过三层架构(调度中心、分片协调器、执行节点)实现任务拆分和并行处理,支持ID范围分片和哈希分片两种策略。关键技术包括:利用Redis实现分布式协调和原子操作,集成Spring Batch构建健壮执行引擎,优化数据读取避免内存溢出。实验表明,该方案可将处理时间从天级缩短至小时级,提升系统性能和扩展性

2026-02-15 03:18:48 1093

原创 SpringBoot + Redis 滑动窗口计数:打造高可靠接口防刷体系

本文针对互联网应用的接口防刷需求,提出基于SpringBoot与Redis ZSET的滑动窗口计数算法方案。该方案通过三层架构(请求入口→切面拦截→Redis存储)实现无侵入式防护,有效解决传统固定窗口算法的边界漏判问题。核心采用Redis ZSET存储请求时间戳,通过清理过期数据、实时统计请求数实现精准限流,并提供普通版与原子性版(Lua脚本)两种实现。方案支持多维度限流配置,异常时自动降级保障主业务,适用于登录、短信、支付等高危接口,可防御暴力破解、资源挤占等攻击,兼顾系统安全性与性能。

2026-02-15 03:02:13 881

原创 深度分析:RocketMQ 如何保证消息不丢失 —— 全链路防丢机制与生产实践

本文深入分析了RocketMQ如何通过全链路机制保证消息不丢失。文章指出消息丢失可能发生在三个阶段:生产者发送、Broker存储和消费者消费。针对每个阶段提出了解决方案:生产者应使用同步发送并开启重试;Broker需配置同步刷盘和同步主从;消费者必须确保业务处理完成后再ACK。最后强调消息可靠性是生产者、Broker和消费者三方协同的结果,给出了生产环境最佳实践配置方案,包括同步刷盘、同步主从等金融级保障措施。

2026-02-10 03:53:32 729

原创 深度分析 RocketMQ 四大核心消息:事务、顺序、批量、延时

消息类型核心解决问题核心机制性能典型场景事务消息分布式事务一致半消息 + 两阶段 + 回查中订单、支付、库存顺序消息消息严格有序同队列 + 单线程消费较低订单流程、状态机批量消息高吞吐、少 IO一次发送多条极高日志、数据同步延时消息延迟 / 定时执行定时调度 + 内部 Topic高超时关单、定时任务RocketMQ 的事务、顺序、批量、延时四大消息,覆盖了分布式系统90% 以上的复杂异步场景。事务消息保证数据一致顺序消息保证流程有序批量消息保证高吞吐延时消息实现定时能力。

2026-02-10 03:46:41 579

原创 深度分析 RocketMQ 幂等性设计与生产级实现方案

本文深入探讨了RocketMQ消息幂等性的设计与实现方案。首先分析了消息重复的必然性及其产生原因,包括Producer重试、Broker重投等场景。文章提出了幂等的核心概念,强调业务层必须自行实现去重机制。重点介绍了五种生产级幂等方案:数据库唯一索引、去重表+事务、Redis分布式锁、状态机幂等以及多级防御方案,其中状态机方案最为推荐。文章还提供了消费端编码模板,并总结了幂等设计的三大原则和生产最佳实践。最后强调幂等是分布式系统高可用的基础,通过合理设计可以实现“重复消息=安全跳过=最终一致“的效果。

2026-02-10 03:42:00 519

原创 深度分析 RocketMQ 消息存储机制 —— 高吞吐与高可靠的底层设计

RocketMQ 的高性能存储机制采用极简架构设计:所有消息全局顺序写入 CommitLog 文件,异步构建消费索引 ConsumeQueue 和查询索引 IndexFile。这种设计通过顺序写提升吞吐量,数据与索引分离确保写入不影响消费。消息写入流程包含同步写 CommitLog、异步构建索引、可选同步/异步刷盘策略。文件管理采用滚动生成和定时删除机制,保障性能稳定。同时支持主从同步和宕机自动恢复,兼顾高可用性。通过 mmap+PageCache+零拷贝技术实现磁盘性能最大化,是高性能消息中间件的典范设计

2026-02-10 03:34:17 906

原创 深度分析 RocketMQ 消息重试(重读)机制

RocketMQ的消息重试机制是分布式系统高可靠性的核心保障。当消费失败时,消息会自动进入专属重试队列(%RETRY%+消费组名),按照10s、30s、1m等18级延迟策略进行重试。默认最多重试16次,超过则转入死信队列(%DLQ%+消费组名)等待人工处理。生产环境必须注意:消费逻辑必须实现幂等性,合理设置重试次数(推荐3-5次),严格监控重试和死信队列,区分可重试与不可重试异常。该机制确保了消息至少投递一次(At Least Once),是构建高可靠消息服务的关键。

2026-02-10 03:22:16 553

原创 TCP 和 UDP 对比如何?

TCP和UDP是传输层两大核心协议。TCP面向连接、可靠但速度慢,通过三次握手、重传机制等保证数据不丢不乱,适用于网页、文件传输等场景。UDP无连接、不可靠但速度快,没有握手和拥塞控制,适用于游戏、直播等实时应用。关键区别在于:TCP保证数据完整性,UDP追求传输速度。实际应用中,HTTP/HTTPS用TCP,而HTTP/3基于UDP优化,体现了二者在不同场景下的取舍。

2026-02-08 01:15:36 544

原创 有了HTTP,为什么还需要WebSocket呢?

HTTP与WebSocket的区别及适用场景 HTTP协议存在单向通信、短连接等先天不足,无法满足实时通信需求,导致轮询等低效方案。WebSocket作为全双工、长连接的协议,实现了服务端主动推送、低延迟双向通信,显著降低了实时应用的开销。两者的核心区别在于通信方式(单向vs双向)、连接状态(短连接vs长连接)和服务端推送能力。典型场景中,HTTP适合资源获取,WebSocket则专精于聊天、直播、游戏等实时交互。两者互补共存,WebSocket通过HTTP升级建立连接,为现代Web应用提供了高效的实时通信

2026-02-08 01:08:00 661 1

原创 HTTP状态码与缓存机制

本文全面介绍了HTTP状态码和缓存机制。状态码分为5类:1xx(处理中)、2xx(成功)、3xx(重定向)、4xx(客户端错误)、5xx(服务端错误),详细解析了200、304、401、404、500等常见状态码的含义。HTTP缓存分为强制缓存(直接使用本地缓存)和协商缓存(向服务器验证),重点讲解了Cache-Control、ETag等核心字段,以及完整的缓存流程。文章还提供了企业级缓存策略建议,如HTML使用no-cache、静态资源设置长期缓存等,并解答了常见问题。掌握这些知识能有效提升Web性能优化

2026-02-08 01:02:17 566

原创 HTTP各版本演进与区别

HTTP协议演进历程摘要:HTTP/0.9(1991)仅支持GET请求,无状态无头;HTTP/1.0(1996)引入请求头/响应头和多种方法;HTTP/1.1(1999)成为主流,支持长连接和Host头但存在队头阻塞;HTTP/2(2015)采用二进制分帧和多路复用提升性能,但仍有TCP层阻塞;HTTP/3(2022)基于QUIC/UDP协议,彻底解决队头阻塞,支持0-RTT握手和连接迁移。当前HTTP/1.1仍广泛使用,HTTP/3正逐步成为未来标准。

2026-02-08 00:56:00 1046

原创 有 HTTP 了为什么还要有 RPC?

HTTP与RPC在分布式系统中各有所长。HTTP作为通用协议,适合跨平台、异构系统间的通信,但其报文冗余、序列化效率低、缺乏服务治理能力等特性,难以满足微服务高并发、低延迟的需求。RPC框架通过自定义私有协议、高效二进制序列化、本地化调用体验和内置服务治理能力,针对性解决了分布式通信的痛点。RPC将远程调用封装为本地函数调用,显著提升开发效率和系统性能,更适合服务间高频调用的场景。二者并非替代关系,而是互补共存,HTTP侧重通用性,RPC专注高性能服务治理。

2026-02-07 00:36:22 780

原创 计网核心协议与IP地址分类

本文系统介绍了计算机网络核心协议与IP地址分类。首先阐述了数据链路层的MAC地址、网络层的IP地址和传输层的TCP协议三大核心标识/协议的功能特点与协同关系。其次解析了ARP/RARP协议在IP与MAC地址转换中的关键作用,以及DHCP协议实现IP自动配置的工作原理。最后详细分类说明了A/B/C/D/E五类IPv4地址的划分规则、结构特征及适用场景,并列举了特殊用途IP地址。这些内容构成了计算机网络寻址与通信的基础知识体系。

2026-02-07 00:24:48 938

原创 计网ping原理

摘要:ping命令是基于ICMP协议的网络连通性检测工具,通过发送回送请求报文(Type=8)和接收回送应答报文(Type=0)来测试主机可达性、延迟和丢包率。其工作流程包括DNS解析、报文构造、IP封装、网络传输、应答处理和结果统计。ping具有轻量无连接的特性,但不依赖端口且仅检测IP层连通性,成功不代表应用层服务正常,失败也不一定表示网络不通。常用参数可控制发送次数(-n/-c)和数据大小(-l/-s),输出结果包含延迟、TTL和丢包率等关键指标。

2026-02-07 00:11:00 599

原创 UDP如何访问DNS?

DNS 默认首选 UDP 作为传输协议,主要因其无连接、高效率特性完美匹配 DNS 查询需求。UDP 无需握手降低延迟,小数据包传输效率高,服务器资源占用少可支撑高并发。DNS 通过客户端重试机制弥补 UDP 不可靠性。当响应数据超过 512 字节或进行区域传输时,DNS 会切换至 TCP。EDNS0 扩展机制进一步优化 UDP 传输能力。这种协议选择体现了业务需求与协议特性的精准匹配,UDP 的高效与 TCP 的可靠形成互补,共同支撑 DNS 服务的高性能运行。

2026-02-07 00:03:04 460

原创 计网:输入网址到网页显示

本文详细解析了从输入网址到网页显示的全过程,包括DNS解析、TCP三次握手、HTTP请求与响应、页面渲染以及TCP四次挥手等核心环节。重点阐述了DNS递归与迭代查询原理、TCP连接的可靠建立与断开机制、HTTP报文封装与传输流程,以及浏览器渲染DOM树和CSSOM树的步骤。文章还总结了网络优化策略如DNS缓存、CDN加速、HTTP/2多路复用等技术要点,为理解计算机网络工作原理和应对相关面试提供了系统性的知识框架。

2026-02-06 23:45:11 647

原创 计算机网络核心网络模型

本文系统梳理了计算机网络的两大核心模型:理论标准的OSI七层模型和工业实践的TCP/IP四层模型。OSI模型精细划分通信流程,包含物理层到应用层七层结构;TCP/IP模型则简化为应用层、传输层、网际层和网络接口层四层。文章详细对比了两者的分层差异、协议对应关系,并解析了数据封装/解封装的核心流程,最后总结了路由器、交换机等设备的工作层级以及ARP、TCP/UDP等关键协议的分层归属。作为网络通信的基础架构,这些模型为理解网络协议栈和实际开发提供了重要框架。

2026-02-05 23:50:41 1040

原创 23种设计模式

本文系统介绍了后端开发必备的23种设计模式,分为创建型、结构型和行为型三大类。设计模式是前人总结的可复用解决方案,遵循七大设计原则,能有效提升代码的可复用性、可扩展性和可维护性。文章详细解析了单例、工厂、适配器、策略等高频模式的应用场景和实现要点,并提供了实战选型指南。同时强调要避免过度设计,理解设计原则比死记硬背模式更重要。掌握设计模式能帮助开发者从"会写代码"进阶到"写好代码",构建高内聚低耦合的系统架构。

2026-02-04 23:52:44 593 1

原创 Redis 故障转移:哨兵vs集群

Sentinel 节点:独立运行的特殊 Redis 进程,不存储业务数据,仅负责节点监控、主观 / 客观下线判定、领头选举、故障转移执行,建议部署奇数台(3/5)防止脑裂;Master 主节点:处理业务读写请求,同步数据至从节点;Slave 从节点:默认只读,作为主节点副本,故障时成为新主候选节点。Redis 故障转移是高可用架构的核心环节,哨兵模式适合主从架构的轻量容灾,部署简单、运维成本低;集群模式适合分布式分片场景,兼具扩容与高可用能力。

2026-02-03 23:43:52 923

原创 对比一下RabbitMQ和RocketMQ

RabbitMQ和RocketMQ作为主流消息中间件,在设计理念、架构和性能上存在显著差异。RabbitMQ基于AMQP协议,以灵活路由和企业级集成为核心,采用队列独立存储模式,适合复杂消息分发场景;RocketMQ源自阿里电商业务,专注高吞吐和可靠性,采用存储与索引分离架构,支持亿级消息堆积,适合互联网高并发场景。

2026-02-02 23:59:07 1338

原创 SpringBoot+Caffeine+Redis实现多级缓存

本文系统介绍了多级缓存技术的核心概念、架构设计与实战应用。主要内容包括: 多级缓存定义与分层结构:通过本地缓存(Caffeine)+分布式缓存(Redis)+数据库缓存构建三级缓存体系,各层性能互补 核心优势:对比单一缓存,多级缓存可提升20倍QPS、降低60%延迟、减少87%数据库负载 设计原则:请求就近访问、数据分层存储、失效由上至下 主流架构:详细解析Caffeine+Redis二级缓存的读写流程和数据更新机制 实战实现:基于SpringBoot整合Caffeine和Redis,提供可落地的配置方案。

2026-02-01 21:51:17 1247 4

原创 Apache RocketMQ的原理与实践

摘要:Apache RocketMQ作为阿里开源的分布式消息中间件,具备高可靠性和高吞吐性能,适用于金融、电商等场景。其架构包含NameServer、Broker、Producer和Consumer四大组件,支持主从复制、分布式事务、顺序消息等核心特性。RocketMQ通过消息队列、分组标识等概念实现系统解耦和流量削峰,并提供消息回溯、死信队列等企业级功能,成为互联网后端开发的主流选择。

2026-01-31 23:55:51 999

原创 Redis 哨兵机制

Redis哨兵机制是官方提供的高可用解决方案,基于主从复制架构实现自动故障转移。核心设计目标包括监控节点状态、通知故障信息、自动故障转移和提供配置服务。哨兵集群由主节点、从节点和哨兵节点组成,采用"一主多从多哨兵"的分布式部署架构,建议至少3个哨兵节点。工作机制分为日常监控、故障判定和故障转移三个阶段:通过心跳检测监控节点状态,当主节点被多数哨兵判定为客观下线时触发故障转移,自动选举新主节点并完成主从切换。哨兵机制实现了秒级故障恢复和客户端无感知切换,有效解决了原生主从复制的单点故障问题

2026-01-30 00:49:08 730

原创 Redis 持久化机制

Redis持久化机制解析 Redis提供RDB和AOF两种持久化方式。RDB通过定时全量快照保存数据,采用fork子进程+写时复制机制实现,具有文件小、恢复快的优点,但存在数据丢失风险。AOF通过记录写命令实现持久化,支持不同同步策略,数据安全性更高但文件体积较大。实际生产环境推荐混合使用两种方式,并合理配置持久化参数,在数据可靠性和性能间取得平衡。

2026-01-30 00:42:43 673

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除