- 博客(101)
- 收藏
- 关注
RSS订阅原创 在技术转型中重温基础：机器学习核心领域梳理
机器学习是人工智能的核心技术，主要分为四种类型：监督学习通过标注数据训练模型进行预测分类（如人脸识别）；无监督学习从无标签数据中挖掘隐藏模式（如客户分群）；深度学习通过神经网络自动提取特征，擅长处理图像、语音等复杂数据；强化学习通过试错和奖惩机制优化决策（如AlphaGo）。这四种方法各具特点，共同推动AI在金融、医疗、自动驾驶等领域的应用突破。
2025-12-22 17:28:51
859
原创 自动驾驶记录仪数据提取标准流程（DoIP/UDS）
摘要：本文围绕自动驾驶数据存储系统(DSSAD)的开发实践，解读国标《GB/T44497-2024》并分析DoIP通信协议实施要点。标准将系统分为精简型(I型)和全功能型(II型)，后者需存储8小时以上数据(含视频/激光雷达等)。文章详细阐述了通过DoIP协议读取DSSAD数据的完整流程，包括建立连接、数据整合、文件传输等关键阶段，重点解析了VIN获取、时间事件整合、文件校验等核心环节。实施中需动态生成文件路径(基于VIN)、严格校验CRC值，并处理视频等辅助文件。该方案为满足L3自动驾驶法规要求提供了技术
2025-12-22 14:15:05
952
原创 软考架构-架构风格
软考架构风格分类与核心考点解析 软考架构风格主要基于构件协作方式和数据/控制流模式划分，包含6大类核心风格： 数据流/调用返回风格（批处理、管道-过滤器等） 独立构件风格（事件驱动、进程通信） 虚拟机风格（解释器、规则系统） 仓库系统风格（数据库、黑板系统） 复合风格（C/S、B/S、SOA、REST等） 闭环控制风格（过程控制） 高频考点集中在典型应用场景（如编译器对应管道-过滤器）、优缺点分析（如事件驱动的松耦合特性）和易混点辨析（如C/S与B/S的区别）。需重点掌握各风格的核心协作模式及典型实例。
2025-10-11 09:50:10
681
原创 软考高级-系统架构设计一些概念的串联
本文系统梳理了软件架构领域核心概念的关系网络。架构风格作为通用模板（如分层、微服务），通过领域需求定制形成DSSA（领域特定架构）。ABSD/ABSDM作为架构驱动开发方法，以架构风格或DSSA为输入进行系统设计与实现。SAAM/ATAM则对架构成果进行评估验证，形成从构建到验证的闭环。四大范畴（架构模式、领域架构、设计方法、评估方法）形成完整链路：架构风格→DSSA→ABSD/ABSDM→SAAM/ATAM，并通过医院管理系统案例展示了各概念如何协同工作。理解这些概念的本质定位与递进关系，对掌握软件架构全
2025-10-11 09:38:02
468
原创 “亿级写入 + 10 万 QPS” 的 MySQL 架构设计与主从一致性解决方案
面试官指尖轻敲桌面，目光聚焦：“咱们聚焦实战 —— 设计国民级 App 的计费日志系统，每日亿级写入、高峰 10 万 QPS 读，数据是时序的，查用户 ID 和时间多，几乎无更新删除。你用 MySQL 怎么扛？还要说清主从复制的一致性问题怎么解。
2025-10-09 10:37:31
981
原创 小凯的 LangGraph 进阶记：从 “线性困境” 到 “智能工作流” 的全流程实践
摘要：本文通过开发者小凯的实践案例，系统介绍了如何利用LangGraph框架解决复杂AI流程开发中的典型问题。从基础的天气查询ReActAgent、带记忆的聊天机器人，到多用户长期偏好隔离存储、RAG文档问答系统，最后实现带人工分支的智能RAG流程。文章详细展示了每个场景的核心概念、代码实现和效果验证，突出LangGraph在可视化流程编排、状态管理、条件分支和人工介入等方面的优势。通过节点-边的设计模式，LangGraph有效解决了传统线性代码难以处理的循环调用、上下文记忆、多用户隔离和流程中断恢复等问题
2025-09-25 13:38:46
1021
原创 Function Calling ：让大模型 “连接外部世界” 的关键能力
摘要： Function Calling 是大模型突破自身知识局限的关键技术，通过调用外部工具（如API、数据库）实现从“思考”到“行动”的闭环。其核心流程包括：1）模型根据工具定义和用户请求判断是否调用工具并生成参数；2）执行工具并返回结果；3）模型整合结果生成自然回复。典型应用包括实时检索、私有数据查询、跨模型协作等。该技术推动大模型从“文本生成器”升级为“系统控制器”，扩展了知识时效性、行为能力和系统集成边界，实现从“规则驱动”到“理解驱动”的范式转变。
2025-09-19 11:19:05
1104
原创 高并发系统的通用设计方法：以 “治水” 思维应对大流量
高并发系统设计与治水智慧存在三大核心对应关系：横向扩展对应"分流"思维，通过分布式部署分摊流量；缓存对应"拓宽河道"思维，利用更快存储介质提升数据处理效率；异步处理对应"蓄水错峰"思维，通过消息队列缓冲请求。这三种方法应根据实际流量量级灵活组合，系统设计需遵循循序渐进原则，避免过早追求复杂架构。核心在于用合理方案解决当前流量问题，而非盲目照搬大厂技术。
2025-09-19 10:14:36
1304
原创 LLM 驱动的自主智能体：原理、组件与实践（基于 Lilian Weng 论文解读）
摘要：大语言模型（LLM）自主智能体通过结合规划、记忆和工具使用三大组件，将LLM从文本生成器升级为问题解决者。规划组件负责任务拆解和反思优化；记忆组件实现短期和长期经验存储；工具组件扩展LLM能力边界。典型案例包括ChemCrow（化学研究）、AutoGPT（通用任务）和GPT-Engineer（代码生成）。当前挑战在于上下文窗口限制、长期规划不足和自然语言接口不可靠。未来发展方向包括改进上下文处理、规划算法和记忆检索，以实现更实用的智能体应用。
2025-09-19 08:35:43
745
原创 LangChain 多任务应用开发：AI开发的项目经理
《LangChain：AI开发的项目经理》 LangChain如同AI应用开发的项目经理，核心价值在于让复杂的AI开发变得有条理。类比年会筹备，LangChain提供三大功能：1）模型I/O封装，统一对接不同AI供应商；2）LCEL流程编排，像年会清单一样串联开发步骤；3）数据连接，协助查找处理素材。 核心组件包括： 模型I/O封装：统一对接方式，提供Prompt模板和结构化输出 LCEL流程编排：用管道符串联开发步骤，支持RAG等复杂流程 数据连接：基础文档处理能力 与LlamaIndex的关系：Lang
2025-09-18 19:21:13
1041
原创 LangChain 父文档检索器：解决 “文档块匹配准” 与 “信息全” 的矛盾
本文介绍了RAG（检索增强生成）中文档切分的核心矛盾及解决方案。传统方法面临两难：小文档块匹配精准但信息不全，大文档块信息完整但匹配效率低。LangChain的父文档检索器通过"双层文档块"设计解决了这一矛盾：子文档块（小）用于精准匹配，父文档块（大）提供完整上下文。文章详细解析了两种实现方案（短文档/长文档处理），并提供了代码示例，展示了如何通过协调向量库、文档存储和切割器实现高效检索。该方案显著提升了RAG系统的答案质量和连贯性，有效平衡了检索精度与信息完整性的需求。
2025-09-18 14:42:00
800
原创 Qwen-Agent 构建 RAG：从 “找文档” 到 “解难题” 的三级智能进阶
Qwen-Agent是基于通义千问开发的RAG框架，通过三级智能体架构解决检索增强生成的核心痛点。Lv1基础检索实现"关键词+BM25"精准定位；Lv2分块检索通过语义评估和二次检索提升准确率；Lv3逐步推理能拆解多跳问题并分步解决。评测显示其在百万字文档中"大海捞针"的成功率显著优于传统方案，并通过银行考核案例验证了落地效果。该框架支持从简单问答到复杂推理的全场景需求，能灵活平衡效率与效果。
2025-09-18 14:09:14
956
原创 阿凯的 “热点救火记”：Weitter 如何扛住顶流明星的离婚微博
Weitter微博系统优化之路：从"全推"到"推拉结合"，通过缓存策略、CDN分发和数据库分片，成功应对明星热点事件带来的高并发压力。系统采用分层处理：在线用户实时推送，离线用户拉取；7天内内容全缓存；全国部署CDN节点；用户数据哈希分片。最终实现60万QPS下0.5秒加载，让用户体验"无感"的技术升级。
2025-09-17 11:37:13
821
原创 阿凯和小美的 “寻友算法之争”：APP 的近邻匹配优化记
Liao交友APP的"附近"功能在用户量激增后出现性能问题。算法工程师阿凯与产品经理小美评估了四种优化方案：SQL算法（全表扫描效率低）、地理网格算法（固定格子大小不灵活）、动态网格算法（开发维护成本高）和GeoHash算法。最终选择GeoHash，通过将经纬度编码为5位字符实现快速定位，在Redis中仅占用1G内存即可覆盖500万个有效格子，将查询时间从5秒降至0.3秒，用户卸载率下降15%。该方案兼顾精度、性能和开发效率，成功解决了海量用户场景下的邻近搜索难题。
2025-09-17 09:04:59
608
原创 RAG-小周的 “检索优化记”：让银行系统学会 “多角度找答案”
浦发银行西安分行的客户经理小李遇到系统检索难题，当查询"客户经理考核标准"时，系统仅返回字面匹配结果，无法获取相关考核细则。IT工程师小周通过诊断发现系统存在"单一查询"问题，于是使用LangChain的MultiQueryRetriever工具进行改造：1）初始化大模型作为"翻译官"生成相近查询；2）配置回调管理器记录查询过程；3）创建多查询检索器实现多角度检索。改造后系统能自动生成3-4个相关查询，显著提升了检索效果。小李测试时成功获取了业绩折
2025-09-16 19:06:08
1544
原创 RAG 优化实战：合理设置 topK
RAG系统中topK参数是平衡召回效果与效率的关键因素。实验表明：topK过小（k=1）会导致漏检关键信息；过大（k=10）会引入冗余干扰；合理范围（k=3-5）能兼顾准确性和效率。建议根据文档结构化程度选择初始值，通过测试验证最优解，并考虑向量库特性调整。在结构化文档场景中，k=5能实现95%相关文档覆盖，同时控制处理时间在1.2秒内，是召回全面性与精度的最佳平衡点。优化时可配置参数化topK，并添加相似度过滤机制提升效果。
2025-09-16 18:16:02
1243
原创 落地实施 RAG 工程的 7 步指南：从数据到生产，逻辑清晰可落地
本文系统介绍了RAG（检索增强生成）技术落地的6个核心步骤：1）数据准备：收集高质量语料并进行结构化处理；2）测试集构建：生成QA对用于效果评估；3）技术选型：根据需求选择零代码、低代码或定制化方案；4）知识库优化：采用7种召回策略提升检索精度；5）测试优化：从功能、性能多维度验证；6）效果评估：使用Ragas工具量化指标。文章强调RAG商业落地需要数据、工具、优化和评估的闭环，并提供了各环节的具体操作方法和工具推荐。
2025-09-16 11:43:48
943
原创 支持三千万用户同时在线的短视频系统设计学习：QuickTok 架构全解析
摘要：QuickTok短视频系统采用分层架构设计，支持三千万用户同时在线、11万播放QPS和年增5200PB存储。核心通过分片上传、责任链处理管道、HDFS+HBase合并存储、CDN主导分发等关键技术，实现高并发低延迟播放和海量视频存储。系统采用异步解耦设计，95%播放流量由CDN承载，结合DASH流媒体协议和个性化缩略图推荐，提升用户体验。多地域部署和容错机制保障99.99%可用性，数据驱动优化使点击率提升25%。该架构兼顾性能、成本和扩展性，满足持续增长的业务需求。
2025-09-16 10:01:35
1092
原创 支持万亿 GB 网盘系统设计学习：秒传与限速的全链路方案
DBox 网盘系统的核心设计逻辑是 “分离元数据与文件内容，用唯一物理存储实现秒传，用资源配额实现限速”，通过分片数据库支撑高频元数据访问，用 Ceph 支撑海量文件存储，最终满足万亿 GB 存储、秒传、限速的核心需求，同时保障高可用、高可靠、数据安全。整个架构可横向扩容，能应对用户量和存储量的持续增长。
2025-09-16 09:42:01
1018
原创 从零搭建 10 万级 QPS 优惠券系统学习：从需求到落地的全流程方案
《10万QPS高并发优惠券系统设计与实践》摘要：本文系统阐述高并发优惠券系统的建设方案，重点解决秒杀发券、库存精准扣减和状态实时同步三大挑战。通过分层架构设计（MySQL+Redis+RocketMQ+Kitex），采用库存分片、二级缓存、循环延迟消息等关键技术，有效应对10万QPS压力。核心创新包括：子库存随机轮询机制突破Redis写瓶颈，循环延迟消息支持超长有效期券，本地缓存+Redis二级缓存保障高可用。经过压测验证，系统在13.5万QPS峰值下保持99.95%成功率，为电商营销活动提供稳定支撑。
2025-09-15 11:17:07
993
原创 支持 10 万 QPS 的会员系统设计学习：从存储到流量的全链路高可用方案
会员系统支撑10万QPS的核心设计采用分层存储架构：MySQL负责写操作（1000+分片双中心部署），ES处理多维度查询（三集群隔离），Redis缓存热点数据（双中心多集群）。通过流量治理（隔离/限流/降级）确保核心请求优先，并采用双中心+自动化故障转移保障高可用。最终实现缓存命中率90%+、核心接口延迟<10ms、全年可用性99.99%，系统具备"提前拦截+分层抗压+故障兜底"三大能力，在保障下单主流程的前提下稳定应对高并发场景。
2025-09-15 09:07:20
1220
原创 数据库优化核心痛点与解决方案学习：从现象到落地的全流程拆解
本文系统分析了数据库性能优化的核心痛点与解决方案。首先拆解四大核心问题：1.SQL执行慢（扫描/回表过多）；2.索引失效（选择性差/函数导致）；3.锁等待（并发冲突）；4.资源耗尽（无效请求）。针对每个问题提供了典型案例和具体优化方案，如减少扫描行数、避免回表、优化索引选择等。文章提出"先上层后底层"的排查流程，强调优先解决SQL和索引问题，最后考虑硬件扩容。同时总结了关键优化原则：合理使用索引、优化多表关联、设置合理慢查询阈值。通过定位本质问题，采用最小成本方案实现高效优化。
2025-09-12 11:02:14
870
原创 QPS 突增 10 倍？全链路设计方案学习：从 “应急抗住” 到 “长期稳跑”
本文系统阐述了应对系统QPS突增10倍的全链路解决方案。从应急层、架构层、数据层到保障层层层递进：应急层通过硬件扩容、入口限流和核心服务熔断快速应对流量冲击；架构层采用微服务拆分、高性能RPC和消息队列优化处理效率；数据层通过三级缓存和分库分表缓解数据库压力；保障层则提供降级预案、数据核对和全链路监控等兜底措施。文章通过"超市收银台"等生动比喻，清晰呈现了从短期扛住流量到长期稳定运行的完整技术方案。
2025-09-12 09:30:09
820
原创 MySQL 备份与复制：类似“手机数据管理”
MySQL备份与复制技术全解析 摘要：本文系统介绍了MySQL数据库的备份与复制技术。备份分为三类：按运行状态（热备/冷备/温备）、按文件格式（逻辑/裸文件）、按内容范围（完全/增量/日志）。重点分析了四种备份工具：ibbackup、XtraBackup、mysqldump和SELECT导出，比较其特性与适用场景。复制技术部分则详解了主从同步的3步流程与2个线程工作机制，及其在读写分离、数据备份和负载均衡中的应用。通过手机数据管理的类比，帮助读者理解这些技术如何共同保障数据安全与业务高效。
2025-09-11 09:25:33
1318
原创 餐厅厨房的 “事务” 修炼记 — InnoDB 事务的 ACID 与日志魔法
《InnoDB餐厅的事务管理之道》摘要 通过餐厅经营场景生动诠释数据库事务机制：以客人订单为事务单位，用ACID四大特性确保操作完整性（原子性）、数据合法性（一致性）、并发隔离性（隔离性）和结果持久性（持久性）。通过RedoLog实现"订单备份"保障故障恢复，利用UndoLog提供"回滚"功能。针对不同业务需求，设置四级隔离规则（从未提交读到串行化）平衡效率与严谨性，并引入分布式事务处理跨店订单。这套机制完美解决了高并发下的数据一致性问题，如同餐厅实现多桌订单精准处理
2025-09-11 09:09:22
589
原创 银行柜员小 In 的 “锁与事务” 修炼记
摘要：市立银行新系统面临"转账慢""余额不准"问题，核心在于并发下的数据一致性。解决方案涉及多种锁机制：事务锁(Lock)保护账户数据，闩锁(Latch)保护临时资源；共享锁(S锁)允许多个查询，排他锁(X锁)确保转账独占；意向锁提升全表扫描效率；MVCC通过快照读提高查询性能。此外，还涉及自增锁分配规则、行锁算法（行锁/间隙锁/Next-Key锁）、事务隔离级别调节数据一致性要求，以及死锁检测机制。这些机制共同保障了银行系统在高并发下既高效又准确。
2025-09-11 08:53:07
684
原创 InnoDB 索引的秘密：图书馆管理员小 In 的 “超高效找书系统”
【摘要】市图书馆藏书量从1万激增至100万册后，管理员小In创新设计了一套"找书系统"：1）建立"馆藏编号"聚集索引实现快速定位；2）增设"书名指引卡"辅助索引支持多维度查询；3）开发"作者-书名"联合索引满足复杂检索需求；4）采用边开馆边更新的OnlineDDL模式；5）通过MRR优化批量查询流程；6）避免低选择性索引。最终实现30秒精准找书，这套系统正是InnoDB索引原理的现实映射，核心在于建立有序指引规则并优化查询路径。
2025-09-10 19:24:39
828
原创 InnoDB 逻辑存储结构：好似 “小区管理” 得层级结构
InnoDB采用"表空间→段→区→页→行"五层逻辑存储结构，类似小区管理体系。表空间是顶层容器，分为共享和独立两种；段按功能划分数据、索引等部分；区由连续页组成确保数据连续性；页是磁盘管理最小单位，包含多种类型；行是最小存储单元，含用户数据和隐藏列。该结构支持索引组织表、多种行格式和分区功能，通过层级化管理实现高效存储和检索，同时保证数据安全性和事务支持。
2025-09-10 16:46:37
711
原创 MySQL 核心文件解析：从配置到存储的 “说明书 + 记录仪” 系统
MySQL文件系统可类比为公司管理制度：参数文件是启动说明书，定义内存、日志路径等基础配置；日志文件类似运营记录仪，包括错误日志（排障）、慢查询日志（优化SQL）、二进制日志（数据恢复/主从复制）；通用文件包含表结构定义文件（.frm）等；InnoDB专属文件包括表空间文件（存储数据）和重做日志（保证事务持久性）。理解这些文件的分工，能针对性配置MySQL并快速定位故障，如生产环境需开启二进制日志和慢查询日志，使用独立表空间提升管理效率。
2025-09-10 16:07:59
912
原创 Mysql-InnoDB 两次写（Doublewrite）：为什么 Redo Log 救不了 “破损的页”
摘要：Doublewrite机制是InnoDB解决"页结构损坏"问题的关键设计。当16KB数据页因断电只写入部分内容时，RedoLog无法修复损坏的页结构。Doublewrite通过在写入数据文件前，先将完整页副本存入共享表空间的安全区来确保页结构完整性。恢复时先用副本修复页结构，再用RedoLog恢复内容。这种机制弥补了操作系统4KB原子写与InnoDB16KB页大小不匹配的缺陷，与RedoLog形成互补：RedoLog负责内容恢复，Doublewrite负责结构恢复，共同保障数据可靠
2025-09-10 09:25:04
1171
原创 Mysql：InnoDB 关键特性
摘要：InnoDB通过五大核心机制优化性能与可靠性：插入缓冲（ChangeBuffer）将非唯一索引的零散写入转为批量处理；两次写（DoubleWrite）防止数据页部分写失效；自适应哈希索引（AHI）自动为热点数据建立快速查询路径；异步IO（AIO）合并磁盘请求减少IO次数；刷新邻接页（FlushNeighborPage）优化机械硬盘的批量刷盘效率。这些设计分别针对写入性能、数据安全、查询速度、IO效率等关键问题，使InnoDB成为MySQL的高效存储引擎。
2025-09-10 09:02:51
1085
原创 Mysql-InnoDB 内存组件：外卖站点的 “高效配送系统”
【摘要】InnoDB核心内存组件通过外卖站点类比：缓冲池相当于"待取餐架"缓存热点数据（数据页/索引页），避免频繁访问磁盘；重做日志缓冲如同"订单暂存本"批量记录事务修改；检查点机制则像"每日对账标记"确保数据持久性并优化恢复效率。系统采用LRU算法智能管理缓存空间，将新数据置于中间位置（默认3/8处）区分临时与持久热点。这些设计共同实现三大目标：快速响应（减少磁盘I/O）、稳定运行（崩溃恢复保障）和空间优化（压缩页/并发缓冲池），本质是通过内存缓
2025-09-09 19:00:32
747
原创 Mysql-InnoDB 后台线程：数据库的 “职能部门团队”
InnoDB后台线程类比为一家公司的职能部门：MasterThread（总经办）负责统筹调度脏页刷新等核心任务；IOThread（技术支持部）处理异步IO回调，提升读写效率；PurgeThread（后勤部）回收无用UNDO日志；PageCleanerThread（清洁部）专职刷新脏页。通过多线程分工协作，InnoDB既确保数据安全（不丢失、一致），又提升处理性能（减少阻塞）。版本迭代中，各线程职责不断细化，从单线程兼职到多线程专职，实现更高效的数据处理。
2025-09-09 17:04:04
997
原创 秒杀系统设计（学习）：从 “稳准快” 到落地的全流程方案
秒杀系统设计的核心在于应对瞬时高并发请求，保证"稳、准、快"三大目标。通过分层优化策略：1）前端静态资源CDN缓存+动态数据本地暂存；2）接入层限流+应用层本地缓存；3）Redis预扣库存+消息队列削峰；4）数据库最终一致性校验。关键要解决超卖问题（Redis预扣+MySQL双重校验）和热点隔离（业务/系统/数据三层隔离）。兜底方案包括限流、熔断、降级和事后核对，确保系统高可用。整体设计遵循"层层过滤、抓大放小"原则，用简单方案解决核心问题。
2025-09-09 09:13:09
1097
原创 Redis 事务：餐厅后厨的 “批量订单处理” 流程
Redis事务机制通过餐厅后厨的类比形象展现：MULTI开启事务（批量点餐），命令入队记录到事务队列（订单小本本），EXEC统一执行（批量做菜）。WATCH实现乐观锁（监控菜品价格变动），事务具有原子性（全做或全不做），但不支持回滚。该设计复用Redis核心数据结构，兼顾效率与简洁性，适用于批量命令执行的场景。整个过程如同餐厅后厨处理整桌订单，确保命令执行的隔离性和一致性。
2025-09-05 17:31:31
715
原创 Redis 发布订阅：社区的 “通知栏与分类订阅” 系统
频道订阅是 “精准关注单个通知栏”，用字典快速定位订阅者；模式订阅是 “模糊关注一类通知栏”，用链表遍历匹配订阅者；发布消息是 “贴通知 + 自动推送”，先精准推给频道订阅者，再模糊推给模式订阅者。这种设计不用订阅者主动轮询消息，实现 “消息实时推送”，同时复用 Redis 的核心数据结构（SDS、dict、list、redisClient），保证效率和灵活性 —— 就像社区通知系统既精准又智能，满足不同居民的订阅需求。
2025-09-05 16:48:42
590
原创 Redis 集群：连锁银行的 “多网点智能协作系统”
Redis集群通过多节点协作实现数据分片与高可用，类比连锁银行体系：1）节点通过握手协议组建集群；2）16384个槽位划分数据存储区域；3）客户端自动重定向至正确节点；4）支持动态扩缩容时槽位迁移；5）主从切换保障故障时业务连续性。集群融合了主从复制和故障转移机制，突破单节点限制，通过分布式架构实现数据分片、负载均衡和高可用性，满足大规模业务需求。
2025-09-05 16:11:30
870
原创 Redis 哨兵：银行的 “智能安保团队”
Redis哨兵机制如同银行的智能安保系统，通过"定期查岗+内部广播"监控主从服务器状态。当主服务器故障时，哨兵会先判定主观/客观下线，再选举"总指挥哨兵"执行故障转移：筛选最优从服务器升级为新主节点，并协调其他从节点同步新主数据。整个过程依赖Redis主从复制能力，哨兵仅负责决策不存储数据，实现服务高可用。该机制通过多级判断和选举算法确保故障切换的准确性与一致性，使业务在主机宕机时无感知切换。
2025-09-05 14:33:30
1046
原创 Redis 主从复制：银行 “总公司与分公司” 的业务同步逻辑
Redis主从复制机制通过"银行总分行"类比阐明其工作原理：主服务器（总部）与从服务器（分行）通过"全量同步+增量同步"实现数据一致性。核心流程包含7个标准化步骤，从建立连接到实时同步，借助PSYNC命令智能选择全量/部分同步。关键机制包括复制偏移量（进度跟踪）、积压缓冲区（断线补漏）和服务器ID（身份验证），底层依赖RDB持久化与内存数据库特性。该设计在保证数据强一致性的同时，兼顾故障恢复效率，为Redis高可用架构奠定基础，后续哨兵和集群功能均构建于此机制之上。
2025-09-05 14:07:19
773
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人