- 博客(2159)
- 资源 (12)
- 收藏
- 关注
RSS订阅
原创 小工匠聊架构文章一览【不间断持续更新】
文章目录超高并发设计技术杂谈超高并发设计小工匠聊架构-超高并发秒杀系统设计 01_总体原则和架构演进小工匠聊架构-超高并发秒杀系统设计 02_数据的动静分离小工匠聊架构-超高并发秒杀系统设计 03_热点数据的处理小工匠聊架构-超高并发秒杀系统设计 04_流量削峰设计小工匠聊架构-超高并发秒杀系统设计 05_服务端性能优化小工匠聊架构-超高并发秒杀系统设计 06_数据一致性小工匠聊架构-超高并发秒杀系统设计 07_Plan B 的设计技术杂谈小工匠聊架构-写给研发工程师的全链路压测小
2020-11-12 00:01:55
82889
9
原创 架构思维： 数据一致性的两种场景深度解读
但是如果出现网络抖动、服务超负荷或者数据库超负荷等情况，整个处理链条有可能在步骤二失败，这时数据就会变成 a2、b1、c1，当然也有可能在步骤三失败，最终数据就会变成 a2、b2、c1，这样数据就对不上了，即数据不一致。图 3 中绿色代表成功的调用路径，如果中间出错，就会先调用相关服务的回退方法，再进行手工回退。因为一些服务出现错误，导致图 1 的步骤三失败，此时处理完请求后，数据就变成了 a2、 b2、c1，不过不要紧，我们只需保证最终数据是 a2、b2、 c2 就行。
2025-04-07 22:30:52
1121
原创 架构思维：限流技术深度解析
场景是这样的：库存中只有 100 个商品，如果我们想把 TPS 控制在每秒 100 笔，将滑动时间窗口设置为 1 秒就行，即被分成 10 个区间，每个区间 100 毫秒，此时就会出现在第 1 个 100ms 请求已经超出了 100 个的情况，也就是说商品已经被秒光。，且主要在网关层做限流操作。再结合上方在 1 秒内控制 100 个请求的例子，如果使用令牌桶算法，我们需要先把令牌的产生速率设置为 100/s，等待令牌的排队队列设为 0，这样就能够满足我们的秒杀限流的诉求了。
2025-04-06 16:00:00
1620
原创 架构思维：熔断机制深度解析
熔断机制是微服务架构的安全气囊快速失败：防止局部故障扩散优雅降级：保障核心链路可用性自适应恢复：动态探测依赖服务状态实践建议渐进式配置：先保守设置阈值，根据监控逐步调整降级兜底：所有远程调用必须定义 fallback 方法熔断分层：结合网关级熔断与服务级熔断通过深入理解 Hystrix 的设计原理与实际场景中的陷阱，开发者能够构建出真正健壮的微服务系统。尽管Hystrix已停止更新，其思想仍被等新一代框架继承，持续为分布式系统保驾护航。
2025-04-06 10:18:57
1250
原创 架构思维： 全链路日志深度解析
Overridetry {通过SkyWalking的落地，我们实现了：✅ 请求全链路可视化追踪✅ 端到端性能分析✅ 异常请求快速定位与Service Mesh集成，实现更细粒度控制结合AIOps实现异常预测构建统一的观测平台（Metrics/Logs/Traces融合）微服务可观测性建设永无止境，选择适合当前阶段的工具，同时保持架构的开放性，才能在技术迭代中立于不败之地。
2025-04-06 07:45:00
1015
原创 架构思维：高并发埋点场景下的实时数据处理架构设计
在面对海量实时数据处理挑战时，架构设计需要像搭积木一样精心选择每个组件。本方案通过本地日志+Kafka+Flink的三级架构，在数据可靠性、处理实时性和系统扩展性之间找到了最佳平衡点。随着业务发展，我们仍需持续优化窗口机制、完善监控体系，让数据真正成为驱动业务增长的核心引擎。
2025-04-06 04:45:00
1110
原创 架构思维：写缓存 - 化解数据库压力
写缓存架构通过“缓冲削峰+异步落库”的设计，巧妙化解了瞬时高并发写入的难题。其核心在于权衡一致性、性能与成本，适用于营销活动、秒杀等短时高峰场景。后续我们将探讨如何结合消息队列（如Kafka）进一步优化异步处理流程，实现更高吞吐量的写场景支持。
2025-04-05 07:00:00
1371
原创 架构思维：读缓存 - 减少数据库读操作压力
缓存层设计是提升系统性能的关键手段，Redis凭借其数据结构、持久化与集群能力成为首选。通过合理的缓存策略、更新机制与高可用设计，可显著降低数据库压力。然而，架构没有银弹，需结合业务特点权衡一致性与性能，持续优化方能应对流量洪峰。
2025-04-05 04:45:00
1264
原创 架构思维：查询分离 - 表数据量大查询缓慢的优化方案
此时解决方案为主数据每次更新时，都更新上次更新时间 last_update_time，然后每个线程更新查询数据后，检查当前订单 A 的 last_update_time 是否跟线程刚开始获得的时间一样，且 NeedUpdateQueryData 是否等于 false，如果都满足的话，我们就将 NeedUpdateQueryData 改为 true，然后再做一次搬运。我们应该使用什么技术存储查询数据呢？MQ 的消费者获取信号后，先批量查询待更新的主数据，然后批量更新查询数据，更新完后查询数据的主数据标识。
2025-04-04 17:27:52
1305
原创 架构思维：冷热分离 - 表数据量大读写缓慢的优化方案
冷库：存放不再修改的“终态数据”（如已完结的订单）。热库：存储仍需频繁操作的“活跃数据”（如待付款、待发货的订单）。通过将数据按生命周期分离，热库仅保留近期高频访问的数据，从而显著降低单库压力。
2025-04-04 15:57:53
1339
原创 MySQL - 写多读少的场景下如何优化数据存储方案
但它依然不能解决某一个业务的数据大量膨胀的问题，一旦系统中的某一个业务库的数据量剧增，比如商品系统接入了一个大客户的供应链，对于商品数据的存储需求量暴增，在这个时候，就要把数据拆分到多个数据库和数据表中，也就是对数据做水平拆分。单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是水平扩展，所以结合业务的特性，就需要在 Range 的基础上引入“分片元数据”的概念：分片的规则记录在一张表里面，每次执行查询的时候，先去表里查一下要找的数据在哪个分片中。垂直拆分是根据数据的业务相关性进行拆分。
2025-04-01 07:30:00
1662
原创 MySQL - 读多写少场景下的优化数据查询方案
如果客户端将要执行的命令发送给集群中的一台服务器，那么这台服务器就会以日志的方式记录这条命令，然后将命令发送给集群内其他的服务，并记录在其他服务器的日志文件中，注意，只要保证各个服务器上的日志是相同的，并且各服务器都能以相同的顺序执行相同的命令的话，那么集群中的每个节点的执行结果也都会是一样的。，介于两者之间，事务线程不用等待所有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端。所以这种方式不是 MySQL 特有的。
2025-04-01 05:00:00
1991
原创 MySQL - 事务隔离级别和锁的机制
假设有 A 和 B 两个事务，在并发情况下，事务 A 先开始读取商品数据表中的数据，然后再执行更新操作，如果此时事务 A 还没有提交更新操作，但恰好事务 B 开始，然后也需要读取商品数据，此时事务 B 查询得到的是刚才事务 A 更新后的数据。换句话说，事务 A 操作数据库时，事务 B 只能排队等待，因此性能也最低。循环等待：可以靠按序申请资源来预防，也就是所谓的资源有序分配原则，让资源的申请和使用有线性顺序，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样的线性化操作就自然就不存在循环了。
2025-03-31 22:17:21
1307
原创 MySQL - 索引原理与优化：深入解析B+Tree与高效查询策略
优秀的索引设计需要平衡查询效率与写入性能。优先考虑最常用查询模式单表索引不超过5个联合索引字段数不超过3个定期审查索引使用情况通过理解B+Tree的底层原理，结合执行计划分析与实际业务场景，开发者可以构建出高效的数据访问方案。记住：没有最好的索引，只有最适合业务场景的索引设计。
2025-03-31 05:15:00
1515
原创 LLM - Token、CONTEXT LENGTH、MAX OUTPUT TOKENS扫盲
Token= 字/词，是计费单位。上下文长度= 模型单次处理的“总内存”（输入+输出≤64K）。最大输出= 模型单次回复的“字数上限”（≤8K）。举个栗子🌰你输入5万字（50K tokens），模型最多只能输出1.4万字（14K tokens），因为50K + 14K = 64K（不能超）。如果让它输出2万字？不行！因为单次回复上限是8K（约8000字）。实际建议✅长文本处理：先压缩（比如摘要关键部分），再让模型分析。✅多轮对话：重要信息放最后（避免被截断）。✅生成长内容。
2025-03-30 11:48:10
1150
原创 LLM - AI四件套 : 大模型、RAG、AI AGENT 、Workflow
十年前，如果有人跟你说"电脑能像人一样写文章、解答难题，还能自己安排工作"，你肯定觉得他在吹牛。毕竟，会用ChatGPT的人已经淘汰了不用的人，而会用Agent+工作流的人，正在淘汰只会ChatGPT的人。——知识停留在训练截止日（比如GPT-4只学到2023年），问它“2024年欧冠冠军是谁”，它能给你编个皇马vs拜仁的精彩战报，但其实压根没这比赛！以前的人工智能像偏科生——训练一个只会翻译，另一个只会算数，每个AI都只会一门手艺。现在所有AI应用都在这个"学霸大脑"上做加减法，这才是真正的范式革命。
2025-03-30 10:56:31
1775
原创 RAG - 五大文档切分策略深度解析
在RAG（检索增强生成）系统中文本切分策略对检索效果和生成质量至关重要。我们来看下RAG五大核心切分策略及其特点。
2025-03-29 23:49:41
1452
原创 深入理解二叉树、B树与B+树：原理、应用与实现
二叉树、B树和B+树各有其优势和适用场景。理解它们的差异和设计思想，有助于我们在实际开发中做出合理的选择。特别是对于数据库设计和性能优化，深入理解B+树的工作原理至关重要。
2025-03-27 20:30:00
1315
原创 Redisson - 分布式锁和同步器
例如：当持有锁的客户端因进程暂停（如JVM的STW）导致锁超时释放时，其他客户端可能同时获取同一资源的锁，破坏互斥性。Martin指出，RedLock依赖的“多数派加锁成功”机制无法保证严格的互斥性，尤其在节点故障恢复或主从切换时，可能产生锁状态不一致的问题。基于Redis或Valkey的分布式可重入栅栏锁（Java实现），通过**防护令牌（Fencing Token）**避免因客户端长时间停顿（如GC暂停）导致的锁失效问题。，当持有锁的Redisson实例存活时，它会延长锁的过期时间。
2025-03-27 18:45:00
1098
原创 LLM - 白话Rerank模型
不同于初检阶段的粗粒度筛选，Reranker会综合评估语义相关度（如问题与内容的深层匹配）、时效性（优先最新资料）、权威性（区分专家论述与普通观点）以及内容完整性（覆盖关键要素的程度）等多个核心维度，通过算法加权计算出每个结果的最终排序得分。Col-BERT是一种用于高效信息检索的模型，它结合了基于表示和基于交互的检索方法的优点。在企业级应用中， 这种智能排序机制有效解决了传统检索中面临的长尾问题、语义鸿沟等挑战，大幅提升了知识库的可用性和准确性，是确保专业用户获得高价值信息的关键技术保障。
2025-03-26 22:44:14
1046
原创 架构思维：预约抢茅子架构设计
在等待抢购阶段，流量突增，因为在抢购商品之前（尤其是临近开始抢购之前的一分钟内），大部分用户会频繁刷新商品详情页，商品详情页面的读请求量剧增， 如果商品详情页面没有做好流量控制，就容易成为整个预约抢购系统中的性能瓶颈点。在商品抢购阶段，用户会点击提交订单，这时，抢购系统会先校验库存，当库存足够时，系统会先扣减库存，然后再生成订单。商品抢购：商品抢购倒计时结束，用户提交抢购订单，排队等待抢购结果，抢购成功后，扣减系统库存，生成抢购订单。订单支付：等待用户支付成功后，系统更新订单状态，通知用户购买成功。
2025-03-26 18:45:00
1862
原创 架构思维：分布式事务一致性_基于 MQ 的可靠消息投递方案
基于 MQ 的可靠消息投递的可落地性，要抓住“双向确认”的核心原则，只要能实现生产端和消费端的双向确认，这个方案就是可落地了，又因为基于 MQ 来实现，所以天生具有业务解耦合流量削峰的优势。基于 2PC 的实现方案很少有实际的场景，但还是要掌握它的实现原理和存在的问题。最后，在实际工作中，并不是所有的业务对事务一致性的要求都那么高。因为更高的要求意味着更多的成本，这也是很多架构复杂度来源之一，所以要尽可能地站在业务实际场景的立足点来回答分布式事务问题。
2025-03-25 23:15:27
1284
原创 Netty - 从Nginx 四层（TCP/UDP）流量中获取客户端真实/网络出口IP
在存在NAT或VPN的网络架构中，通过Proxy Protocol获取客户端真实IP的能力受限于网络设备的位置。若NAT/VPN位于客户端与Nginx之间（如企业VPN或家庭路由），Proxy Protocol仅能传递经过NAT转换或VPN隧道出口的IP（如公网IP或VPN分配地址），无法穿透获取终端设备的内网真实IP。若需突破此限制，可采取混合方案：客户端主动上报IP（需改造客户端代码）并配合网络设备改造（如VPN网关记录原始IP、专用隧道协议）。但需注意隐私合规风险，避免采集敏感信息。
2025-03-25 19:16:00
1484
原创 架构思维：如何设计一个支持海量数据存储的高扩展性架构_数据分片、存储、复制与一致性的原理性问题
分片选择：主用Range分片按类目划分，辅以一致性Hash处理非热点数据。热点处理：元数据服务动态路由，热点类目拆分为多个分片，结合缓存抗读压力。数据一致性：主从复制+Raft协议，确保强一致性；异地容灾采用异步复制+Gossip。元数据管理：ETCD集群存储分片信息，客户端缓存元数据减少延迟。此方案平衡了扩展性、一致性与可用性，灵活应对海量数据与业务热点，符合高并发场景需求。
2025-03-23 21:50:05
1427
原创 架构思维：从CAP到PACELC到BASE
CAP 理论指的是什么？C（Consistency）是数据一致性、A（Availability）是服务可用性、P（Partition tolerance）是分区容错性。C、A、P 只能同时满足两个目标，而由于在分布式系统中，P 是必须要保留的，所以要在 C 和 A 间进行取舍。假如要保证服务的可用性，就选择 AP 模型，而要保证一致性的话，就选择 CP 模型。
2025-03-23 21:16:03
1509
原创 LLM - 重排序（Rerank）
重排序模型虽然速度较慢，但其在精准度上的优势使其成为现代检索系统中不可或缺的一环。通过两阶段检索策略，我们可以在第一阶段快速召回候选文档，然后在第二阶段通过重排序模型进行精细排序，这种策略在处理复杂的问答任务和生成任务时尤为重要，因为它能够确保最终返回的文档不仅数量适中，而且相关性更高,从而在效率与精准度之间找到最佳平衡。
2025-03-22 22:42:42
1517
原创 LLM - CentOS上离线部署Ollama+Qwen2.5-coder模型完全指南
如果没有显卡，就不要折腾了，线上服务器16Core 32G内存， 无显存。实测部署了个qwen2.5-coder 7B的模型， 对话延时400多秒…上图就是两个文件，下面就要进行模型文件合并。返回后，ollama ps （以0.5b的为例）就可以看到了（我之前看不到，以为有问题）其他的模型，也可以按照上面的方式来安装，别浪费了你的卡子， 赶紧私有化起来吧 ‘ollama 提供了丰富的命令行工具，方便用户对模型进行管理。把原来的软连接删除，上传新的，重新软连一下 即可。，即阿里云通义千问模型的第二代架构。
2025-03-22 14:00:04
1966
原创 架构思维：通用系统设计方法论_从复杂度分析到技术实现指南
架构师思维的本质全局视角：在空间维度关注系统边界，在时间维度预见业务发展。问题驱动：技术方案必须解决主要矛盾（如案例中的高可用）。权衡思维：没有完美方案，只有最适合当前场景的决策。
2025-03-20 23:25:05
1330
原创 架构思维：从代码实现到系统思维的进阶之路
那么应该怎么做呢？针对这样的问题，我们需要对原有系统进行合理的系统边界拆分，让研发人员有能力提速，来快速响应需求变化，这就要求架构师对业务领域和团队人员有足够的了解。在 20 世纪 60 年代，《人月神话》的作者就分析，软件复杂性来源于两点：本质复杂度和偶然复杂度。开发工具、开发框架、开发模式，以及高性能和高可用这些仅是偶然复杂性，
2025-03-20 19:00:00
1742
原创 架构思维：分布式锁设计与实现_原理、方案与最佳实践
分布式锁的选择需要综合业务场景、性能需求与运维能力。理解不同方案的实现原理和限制条件，才能设计出既保证数据一致性，又具备高可用的分布式系统。
2025-03-19 06:45:00
1463
原创 服务远程调用（RPC）架构及原理（下）
这时就需要一个调度者去监控所有的客户端连接，比如当图中的客户端 A 的输入已经准备好后，就由这个调度者去通知服务端的工作线程，告诉它们由工作线程 1 去服务于客户端 A 的请求。此时，商品详情页的 QPS 已达到了 2 万次/s，在做了服务化拆分之后，此时完成一次请求需要调用 3 次 RPC 服务，计算下来，RPC 服务需要承载大概 6 万次/s 的请求。根据 RPC 协议，服务提供方将二进制数据分割出不同的请求数据，经过反序列化将二进制数据逆向还原出请求对象，找到对应的实现类，完成真正的方法调用；
2025-03-19 05:15:00
1138
原创 Kafka - 消息队列的丢失、重复与积压_从生产到消费的完整解决方案
引入 MQ 消息中间件最直接的目的是：做系统解耦合流量控制，追其根源还是为了解决互联网系统的高可用和高性能问题。系统解耦：用 MQ 消息队列，可以隔离系统上下游环境变化带来的不稳定因素，比如XX服务的系统需求无论如何变化，YY服务不用做任何改变，即使当XX服务出现故障，YY流程也可以将京豆服务降级，实现XX服务和YY服务的解耦，做到了系统的高可用。流量控制：遇到秒杀等流量突增的场景，通过 MQ 还可以实现流量的“削峰填谷”的作用，可以根据下游的处理能力自动调节流量。
2025-03-18 07:30:00
1570
原创 LLM - Docker安装Dify导致C盘爆满
通过上述方法可灵活应对Docker导致的C盘空间问题。推荐长期方案为方法1（迁移存储路径）配合定期清理，既能保证开发效率，又避免系统盘爆满 .
2025-03-18 04:45:00
1255
原创 LLM - Docker离线部署Dify：从镜像打包到无网环境部署
通过本篇博客的详细步骤，即使在没有互联网接入的隔离环境中，也能快速部署Dify服务。这种基于Docker的离线部署方案同样适用于其他容器化应用，为企业的安全部署提供了可靠的技术路径。docker logs -f <容器ID>
2025-03-17 07:15:00
3329
3
原创 LLM - Dify Docker镜像拉取失败的解决办法
通过替换国内镜像源，可显著提升Dify镜像拉取成功率。使用单独拉取失败镜像。检查防火墙或DNS设置。
2025-03-17 04:45:00
2012
1
原创 架构思维：软件建模与架构设计的关键要点
软件建模与设计文档是架构师的核心工具，通过UML图系统化表达设计意图，确保多方协作一致性。明确需求：用用例图、活动图梳理功能。规划架构：通过部署图、组件图定义技术方案。细化实现：类图、时序图指导开发。持续迭代：结合反馈优化模型与文档。
2025-03-15 18:22:13
1427
原创 LLM - 深入解析Embedding模型工作原理
例如，图像可能会缩小为 512 维向量，在不保留完整分辨率的情况下捕获其主要特征。Embedding模型是将文本数据转换为向量表示的核心工具。这些向量表示能够捕捉文本的语义信息，广泛应用于文本分类、信息检索、问答系统等任务。在自然语言处理（NLP）领域，Embedding模型扮演着将文本映射到高维向量空间的核心角色，其质量直接影响语义搜索、文本分类等任务的性能。检索增强生成（RAG）是生成式 AI 中的一类应用，支持使用自己的数据来增强 LLM 模型的知识。RAG 通常会用到三种不同的AI模型，即。
2025-03-15 07:45:00
2176
原创 LLM - Dify（1.0.1）搭建本地私有RAG知识库完整指南
由于 Dify 内置了构建 LLM 应用所需的关键技术栈，包括对数百个模型的支持、直观的 Prompt 编排界面、高质量的 RAG 引擎、稳健的 Agent 框架、灵活的流程编排，并同时提供了一套易用的界面和 API。它融合了后端即服务（Backend as Service）和 LLMOps 的理念，使开发者可以快速搭建生产级的生成式 AI 应用。需要根据测试结果，发现回答不准确或性能不佳，可以对数据进行进一步的清洗和整理，优化索引结构，调整 RAG 模型的参数等。在 Dify 的界面中，点击用户名。
2025-03-15 05:15:00
2374
原创 LLM - Ollama+Deepseek R1+Nomic-Embed-Text+AnythingLLM搭建本地私有RAG知识库
通过以上步骤，选择本地ollama部署的大模型的话，就可以部署一个完全本地的RAG系统。数据隐私：所有处理均在本地完成。灵活扩展：支持替换其他Ollama模型（如Llama 3、Mistral）。成本可控：无需支付API费用。
2025-03-14 18:30:00
1693
原创 LLM - 使用 Ollama 和 Chatbox 实现 DeepSeek R1 的本地 AI 助手
如果硬件资源有限，可以尝试调整 Ollama 的加载模型的大小，减少模型的资源占用。Ollama安装过的模型都可以使用的。输入 Ollama 服务器的地址（通常是 http://127.0.0.1:11434）。在 Model 部分，选择 Ollama。选择 DeepSeek R1 作为模型。
2025-03-14 05:00:00
1011
X86-NFS rpm包
2020-11-24
中标龙芯-MIPS- NFS rpm包
2020-11-24
mybatisSource.zip
2020-06-14
apache-tomcat-8.5.50-src.zip
2020-06-02
「Tomcat源码剖析」.pdf
2020-06-01
Jest-5.3.4.zip
2020-01-19
Spring4CachingAnnotationsExample
2017-10-04
Java反编译工具
2015-06-04
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人