- 博客(40)
- 收藏
- 关注
RSS订阅原创 一个热搜能打爆 Redis 吗？从《牛来》出圈聊聊京东 HotKey探测架构
单台机器看到的是局部流量，但我们真正关心的是整个集群中的全局热点。因此，它让 Client 负责采集局部流量，让 Worker 负责从全集群维度进行聚合，再通过时间窗口和阈值判断一个 Key 是否已经成为热点。发现热点以后，Worker 使用 Netty 尽快通知业务节点，同时利用 Etcd 做状态同步和兜底。Client 收到热点状态后，再将这个状态保存到本地，业务可以根据实际情况把对应的热点数据加载到 Caffeine 等本地缓存中。
2026-08-16 13:10:19
327
原创 面试被问懵系列：关于分布式锁，我们到底该掌握到什么程度？
不知道大家有没有这种感觉：简历上写着“熟悉Redis”、“了解高并发”，觉得自己准备得挺充分。可一旦面试官真的问起：“如果让你设计一个分布式锁，你会怎么做？哪怕脑子里蹦出了 setnx、Lua脚本这些词儿，可一旦被追问细节——比如“看门狗机制具体是怎么跑的？”或者“主从切换导致锁丢失怎么解决？”，立马就开始支支吾吾，半天说不清楚。明明平时都在用，真到了嘴边却像卡壳了一样，那种尴尬感真的太真实了。别慌，今天这篇文章不整虚的。咱们把那些高大上的名词拆开揉碎，从最基础的互斥性到复杂的红锁算法，带你
2026-06-23 15:16:58
658
原创 搞定 Redis 高可用！看完这篇再也不被面试官吊打
在后端开发中，Redis几乎是标配的缓存中间件。但很多人只会基础的读写操作，对高可用架构一知半解。面试时经常被问：Redis单机有什么问题？主从架构解决了什么痛点？哨兵和集群的核心作用区别是什么？生产环境该怎么选型？本文全程问题驱动，从单机痛点出发，循序渐进带你吃透 Redis 主从、哨兵、集群三套高可用架构，彻底搞懂每一层设计的意义、核心原理与落地逻辑。
2026-06-22 23:21:43
987
原创 吃透Redis持久化：从RDB、AOF到混合持久化的底层设计思维
Redis 号称内存数据库中的“速度狂魔”，但你是否想过，当服务器突然宕机或断电时，那些在内存中飞速流转的数据，难道只能眼睁睁看着它们灰飞烟灭？在追求极致性能与保障数据安全之间，Redis 究竟是如何巧妙平衡的？它又是如何通过 RDB、AOF 以及混合持久化，在“定时拍快照”与“逐条记流水账”之间，为你量身定制出一套完美的数据兜底方案？
2026-06-21 18:59:43
596
原创 深入理解 MySQL 三大日志：Undo Log、Redo Log 与 Binlog 的协同之道
在数据库的设计中，高并发与高可靠永远是一对互相对抗的指标。我们既希望数据在极端情况下一个字都不丢，又要求数据库能以极快的速度响应请求。MySQL 能在开源界长盛不衰，很大程度上归功于它那套精妙的日志体系。今天，我们将跳出枯燥的文档，从一个读者的视角，像讲故事一样，带你彻底搞懂 MySQL 的三大核心日志：Undo Log、Redo Log 和 Binlog。它们分别解决了什么问题？底层原理是什么？又是如何完美串联在一起的？
2026-06-17 14:38:03
1765
原创 数据库写轮眼：看透 MVCC 版本链、快照、隔离级别。
在数据库高并发场景下，海量事务同时读写同一份数据，单纯依赖锁机制相互制衡，只会造成无休止的阻塞等待；脏读、不可重复读与幻读，更如同忍界无解的幻术，牢牢桎梏着系统性能。正如这幅图中，宇智波鼬借 Undo Log 铺展绵延不绝的数据历史分身版本链，佐助则凭借 ReadView 写轮眼，筛选出仅对当前事务可见的数据快照。MVCC 正是数据库世界里独一份的宇智波瞳术，它摒弃锁竞争的对抗思路，依托多版本数据与视图可见性规则，为每一笔事务划分独立读写时空，从根源化解并发读写矛盾。
2026-06-15 22:22:41
1552
原创 为什么鸣人的拉面钱不能凭空消失？——事务与 ACID 详解
当鸣人掏出20两银子购买拉面时，系统需要同时完成“扣钱”和“记账”两个操作。如果其中一步执行失败，就可能出现钱没了、面没吃到的离谱事故。为了避免这种情况，数据库设计出了事务这一“S级忍术”，通过 ACID 四大特性保证数据操作的安全与一致。本文将跟随鸣人的脚步，从一碗拉面出发，深入剖析事务的诞生原因、ACID 的核心思想以及 MySQL 的底层实现机制，带你彻底掌握数据库事务这一面试与实战中的高频知识点。
2026-06-14 19:03:38
517
原创 别焦虑 AI 抢饭碗了！先看看 JVM 是如何对你代码里的垃圾对象进行“物理超度”的
在 Java 后端开发中，JVM 的自动内存管理机制让我们彻底告别了 C/C++ 时代手动释放内存的繁琐与危险。但这并不意味着我们可以对内存放任不管——当系统出现卡顿、OOM（内存溢出）等性能瓶颈时，深入理解垃圾回收（GC）机制就成了解决问题的关键。今天，让我们一步步剥丝抽茧，彻底搞懂 JVM 的垃圾回收机制。
2026-06-11 22:49:24
1045
原创 Java 线程池修仙传：从“无限收徒”到“灵力枯竭”的血泪教训
在并发修仙界，很多新手以为创建线程像呼吸一样简单？错！随意 new Thread 就像无限制招收外门弟子，早晚导致宗门（服务器）资源耗尽而崩塌。真正的强者懂得利用线程池这座“护宗大阵”——核心线程是内门长老，队列是待办任务堂。但小心！若不懂拒绝策略这道“天劫防线”，一旦任务积压如山，你的系统就会当场走火入魔，抛出 RejectedExecutionException！本文带你参透 ThreadPoolExecutor 的七层境界
2026-06-09 17:01:46
392
1
原创 Java 并发修仙传：ThreadLocal 从“闭关修炼”到“走火入魔”的救赎之路
修仙（高并发）路上，锁机制（synchronized）太内卷，大家都排队？ThreadLocal 另辟蹊径，直接开启“空间复制大法”，一人一个副本，各玩各的。可惜，此功法有个致命罩门——内存泄漏，一旦停留在线程池这片“长生禁地”，必遭 OOM 天劫。本文为你复盘这场修仙惨剧，看原生 ThreadLocal 如何翻车，以及阿里 TTL 如何用“捕获、重放、还原”三大仙术逆天改命！
2026-06-08 19:26:58
524
原创 RAG 实战：大模型的“会话记忆”到底是怎么实现的？
很多人第一次使用 ChatGPT 时，都会产生一种错觉：“AI 好像真的记得我之前说过的话。但当我真正开始做 RAG 项目后，我才发现：大模型其实根本“不记得”你。所谓的“记忆”，本质上只是：应用层在每次请求时，把历史聊天记录重新发给模型。而这也引出了 AI 应用开发里一个非常核心的问题：如何让模型“看起来有长期记忆”，同时又不让 Token 成本爆炸？
2026-05-14 22:46:00
595
1
原创 RAG落地踩坑：文档向量化后存在MySQL？揭秘向量数据库的真正优势
全称是分层可导航小世界图，它是目前最主流、效果最好的 ANN 索引算法，几乎所有向量数据库都把它作为默认或推荐的索引类型。
2026-05-13 13:58:42
700
1
原创 从关键词检索到混合检索：一文彻底搞懂 RAG 中 Embedding 的作用与底层原理
本质定义：Embedding 是将文本映射到高维稠密向量空间的技术，其核心价值在于：将“语义相似性”转化为“向量空间中的距离相似性”。语义相近的文本（如“苹果手机”与“iPhone”），向量余弦相似度趋近 1。语义无关的文本（如“咖啡”与“雨伞”），向量距离显著增大。定位：向量检索的前置条件。
2026-05-10 20:40:28
484
原创 RAG 效果差？可能是你的“分块策略”没选对！
刚接触 RAG时，很多人都会有一个疑问：“现在的大模型上下文不是已经很大了吗？为什么还要把文章切碎？其实原因很简单：大模型上下文变大，并不意味着“整篇文档直接塞进去”就是最优解。真正的问题，不是“能不能放进去”。而是：模型能不能精准找到答案。
2026-05-10 19:50:06
423
原创 理解函数调用Function Call
工具化架构模式（智能调度）：将“搜索知识库”视为一个工具，将“查询业务系统”视为另一个工具。大模型不再直接生成答案，而是先分析用户意图，判断该问题属于“静态知识查询”还是“动态业务操作”，进而自动路由至相应的工具。将“知识库检索”与“业务工具调用”统一抽象为工具，利用大模型的意图识别能力作为智能路由器，根据用户问题的性质动态选择执行路径，从而实现从“被动问答”到“主动服务”的架构升级。我们需要告诉模型有哪些“武器”可用。核心思想： 将“判断何时调用工具”的逻辑交给模型，将“具体执行工具”的逻辑留给代码。
2026-04-21 16:26:01
586
原创 后Function Call时代：为什么我们需要MCP？
任何工具只要实现了 MCP 协议，就能被任何支持 MCP 的客户端调用，无需关心对方是什么语言、什么平台。这实现了真正的解耦。效果：知识检索不再局限于特定系统，任何支持 MCP 的客户端（如 Claude Desktop、IDE 插件）都能直接调用企业的知识库。发现慢：工具藏在全是 if-else 的代码里，新人和模型都不知道系统到底有哪些能力。优势：模型自动判断何时查知识库，何时调业务 API，实现了“问答 + 操作”的闭环。场景：规范模型与用户的交互方式，例如“代码审查”或“写测试用例”的标准化提示。
2026-04-21 16:13:51
521
原创 深入理解RAG中的数据分块策略
策略类型核心逻辑优点缺点推荐场景递归分块多级分隔符迭代简单、通用、速度快无法完全保证语义完整通用文档、博客、新闻语义分块向量相似度阈值语义连贯、精度高成本高、速度慢法律、医疗、科研论文混合分块规则+模型组合效果最优、灵活开发维护复杂企业级知识库、复杂RAG系统。
2026-04-19 17:07:48
421
原创 用户密码保护体系，从传输到数据库。
在数字化时代，用户密码是保护个人隐私和数字资产的最后一道防线。作为开发者，我们经常面临这样的灵魂拷问：“用户的密码真的安全吗？很多初学者容易陷入一个误区：认为只要用了HTTPS就万事大吉了。但事实上，网络安全是一场没有终点的博弈。从用户输入密码的那一刻起，到数据在网络中传输，最后落地到数据库，每一个环节都可能存在被“中间人”窃听、被黑客撞库的风险。本文将从传输链路安全端点数据加密以及数据库存储安全三个维度，由浅入深地带你拆解一套完整的密码保护方案，帮助你构建坚不可摧的安全体系。
2026-04-10 20:17:57
308
原创 Elasticsearch从入门到精通，万字长文教你实战。
在业务初期，直接使用数据库的LIKE模糊查询往往能满足需求。数据库模糊查询通常无法命中索引，导致。在千万级甚至亿级数据面前，查询延迟会从毫秒级暴增至秒级，系统负载不堪重负。数据库仅支持死板的字符匹配，无法处理或。用户期望的是“搜我所想”，而数据库只能做到“搜我所写”。Elasticsearch（ES）正是为了解决这些痛点而生。它凭借底层的机制和，实现了海量数据下的毫秒级检索；同时，通过强大的分词器与相关性算法，提供了极佳的搜索智能化体验。
2026-04-10 20:09:16
546
原创 Feed流架构：深入解析推、拉与推拉结合模式
在设计微博、朋友圈、Twitter这类社交产品的信息流（Feed流）时，我们面临一个核心的技术挑战：如何高效地将用户发布的内容分发给海量的粉丝？，以及工业界最常用的。本文将带你由浅入深，从原理到优缺点，再到实际架构选型，彻底搞懂这三种模式。
2026-04-09 17:01:10
960
原创 MySQL的高可用解决：主从模式与MHA，MGR
在互联网应用和商业系统中，是保障业务连续性的核心能力。一旦数据库发生故障，轻则影响用户体验，重则造成数据丢失和业务中断。作为最流行的开源关系型数据库，MySQL 被广泛应用，但其高可用架构的目标是，在硬件故障、网络故障等异常情况下，确保数据库服务不中断，数据不丢失。：如何确保主从节点数据一致？：如何实时发现主节点宕机？：如何快速将服务转移至备用节点，并重建主从关系？：如何避免故障切换时的数据丢失？
2026-04-09 16:46:22
989
原创 面试官：限流是什么？如何实现？许多人答错。
在高并发架构中，限流是保障服务高可用的“安全阀”。当上游流量洪峰超出下游服务的处理极限时，限流机制通过精准的拒绝、排队或延迟策略，防止系统因资源耗尽而发生雪崩。本文将从限流的分类入手，深入剖析单机限流的核心算法逻辑，并详解分布式全局限流的两种主流架构，为你构建一套完整的限流知识体系。
2026-04-08 23:19:48
537
原创 黑马Elasticsearch 总结笔记
在关系型数据库中，我们习惯使用正向索引（Forward Index），即通过主键 ID 去查找具体的记录。文档：用来搜索的基础数据单元（如一个商品信息、一篇博客文章），在 ES 中表现为 JSON 格式。，然后在倒排索引中直接找到包含这两个词条的文档 ID 集合，最后取交集返回结果。1）创建Request对象。字段：字段，就是JSON文档中的字段，类似数据库中的列（Column）filter：必须匹配，但不计算评分，且会利用缓存（性能极高）。过程：先扫描文档 ID，再遍历文档内容，判断是否包含关键词。
2026-04-08 21:23:37
743
原创 缓存一致性终极指南：旁路缓存与延迟双删
在分布式系统中，缓存（如Redis）与数据库（如MySQL）的数据一致性是一个永恒的话题。我们常说“缓存是数据库的影子”，但在高并发场景下，这个“影子”往往会因为网络延迟、并发竞争而出现“变形”。如何解决这个问题？业界通常遵循“先更新数据库，再删除缓存”的基准原则，并在此基础上演化出了与。本文将带你深入剖析这两种方案的实现原理与适用场景。
2026-04-07 14:09:08
875
原创 RAG技术：从向量检索到分块策略的大白话解析
想象一下，你把一本厚重的技术手册直接扔给AI，然后问它：“配置参数X是多少？”如果AI没有“过目不忘”的本事，它该如何在茫茫字海中精准定位答案？这就是RAG（检索增强生成）要解决的核心问题。
2026-04-07 08:51:08
583
原创 Leetcode链表篇题解
Hash算法常常被用来判断某个东西存在与否，而这个相交链表就是来判断这个节点是否在两个链表里面共同存在的。因为链表相交后不可分叉，双指针通过‘交换跑道’消除了两个链表长度的差异，使得它们在。就实现了位置对齐，所以相遇点必然是公共区域的入口。
2026-04-03 21:59:36
220
原创 尚硅谷Git学习笔记
在git中，从仓库路径中添加新的文件，会被比对文件比较仓库路径和仓库里面文件的区别，如果被发现仓库路径有新的文件，会被检测出来。git的分支是基于提交操作，手动初始化的仓库，暂时还没有提交，所以不可以直接创建分支。这里丢失了删除的那一次提交，我们不希望丢失提交过程，重新删除文件，我们希望文件恢复，又希望提交不会丢失。修改文件导致比对文件检测文件内容不一致，进行提交操作，仓库会生成该文件新的版本，同时生成版本号。频繁修改，产生大量的版本信息，会导致仓库容量变大，在做定位和比对文件，效率会变慢。
2026-03-26 23:07:19
399
原创 基础架构设计之-用户关系服务
Following表为数据库的主表，Follower表、计数服务、Redis缓存都以Following表为标准来更新数据。对于用户量级大的应用，拥有几百万粉丝的大V数不胜数，这意味要着存储许多超长的Zset对象，对于。：若判定该用户为“大V”（关注量或访问频次达标），则自动将其数据拉取到当前服务实例的。当缓存没有命中，回源数据库的时候，会在redis创建对应的ZSET对象。：同“查询关注列表”流程（本地缓存 -> Redis -> DB）。：逻辑同粉丝列表查询。存储用户的所有关注 ID，实现的极速查询。
2026-03-25 22:18:33
972
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人