分布式

晚霞的不甘

CANN-MoE模型推理加速实战MoE（Mixture of Experts）模型是当前大模型的主流架构，但它有个问题：8 个专家只激活 2 个，怎么让昇腾跑得更快？本文手把手教你。

Java-221 RocketMQ 消息存储核心原理：CommitLog、ConsumerQueue、IndexFile 与消息过滤机制消息队列的存储介质主要分为关系型数据库和文件系统两类，不同的存储介质在性能、可靠性和适用场景上各有优劣。

或与且与或非

rabbitmq选举集群搭建在生产环境中rabbitmq常常需要搭建集群，下面我就给大家分享一下rabbitmq选举集群的搭建过程，搭建环境为两台机器，1.6和1.89,在1.89上安装了docker，这样模拟出三个机器，组成最小集群。

【分布式利器：金融级】金融级分布式架构开源框架全景解读关键词：金融级开源框架、SOFAStack、CloudWeGo、Seata、RocketMQ、OceanBase、Istio、分布式架构选型摘要：在金融级分布式系统领域，SOFAStack 无疑是耀眼的全栈方案，但放眼整个生态，还有字节 CloudWeGo、腾讯 TARS、阿里 Seata、RocketMQ、OceanBase、TiDB、Istio 等众多经过大规模生产验证的优秀框架。本文将从微服务/RPC、分布式事务、消息队列、服务网格、分布式数据库五个维度，深度剖析各框架的金融级特性、架构原理及适用

分布式能力在鸿蒙 PC 上到底怎么用？大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

【分布式利器：SOAF】蚂蚁开源的金融级微服务全家桶：SOFAStack 核心架构与实战选型对比关键词：SOFAStack、蚂蚁开源、金融级微服务、SOFARPC、分布式事务、Spring Cloud对比、高可用架构摘要：本文深入剖析蚂蚁集团开源的 SOFAStack（Scalable Open Financial Architecture）—— 一套久经“双十一”考验的金融级分布式微服务中间件栈。从定位、核心组件、关键特性到与 Spring Cloud 的全面对比，辅以 Mermaid 架构图与代码示例，帮助开发者理解 SOFA 在金融场景下的独特优势与选型决策。

深蓝电商API

分布式电商爬虫架构：Scrapy-Redis+消息队列的集群部署在电商数据采集场景中，单节点爬虫存在抓取效率低、任务无法分片、故障难以扩容、IP 资源利用率不足等痛点，面对海量商品列表、价格数据、店铺信息、营销活动等大规模采集需求，传统单机 Scrapy 爬虫早已无法适配业务量级。

阿正的梦工坊

RabbitMQ 消息队列详解：从原理到实战在现代分布式系统中,服务之间的通信至关重要。当系统规模逐渐扩大,直接的同步调用会带来诸多问题：服务耦合、性能瓶颈、可靠性下降……这时,消息队列（Message Queue）就成了系统架构中的"神器"。

高并发系统的降级预案与容错策略系列定位说明本文是“高并发与稳定性工程”系列的第 8 篇。在构建了限流（第 1 篇）、熔断（第 2 篇）、隔离（第 3 篇）、容量规划（第 4 篇）、混沌验证（第 5 篇）、秒杀架构（第 6 篇）、监控告警（第 7 篇）之后，降级预案是整个稳定性体系的最后一道主动防线。它不是自动触发的断路器，而是由架构师或自动化策略在预判系统即将崩溃时，做出有计划的牺牲决策。

稳定性监控与告警体系：SLI/SLO/SLA 实践本文是“高并发与稳定性工程”系列的第 7 篇。在前 6 篇文章中，我们由底向上，从单点的限流算法、熔断降级、服务隔离，到全链路的容量规划、混沌工程，乃至百万级秒杀架构的实战落地，逐步构建了一套强悍的防御工事。然而，这一切精密的设计，若缺乏一套敏锐的“神经系统”进行实时感知与反馈，都无异于在黑暗中航行的巨轮。监控与告警，正是稳定性体系拼图的最后一块，它将“被动防御”升级为“主动感知”，将“事后修复”进化为“数据驱动”。

故障演练与混沌工程：ChaosBlade 到 Litmus本文是“高并发与稳定性工程”系列的第 5 篇。在前 4 篇构建了限流、熔断、隔离、容量规划四道防线之后，本文进入稳定性体系的“主动验证”环节——混沌工程。混沌工程不是“搞破坏”，而是“实弹演习”：用受控的故障注入来验证防线是否真的有效，暴露被理论和配置忽视的盲区。

全链路压测与容量规划方法论本文是“高并发与稳定性工程”系列的第 4 篇。前三篇在入口、出口与舱内分别构筑了限流、熔断、隔离三道防线，但每一道防线的参数——限流阈值设多少？熔断慢调用阈值定为多少？隔离线程池开多大？——都依赖一个前置答案：系统真实容量是多少？本文正是回答这个前置问题：通过全链路压测安全地测量生产级容量，并将测量结果反哺为三道防线的精确参数，形成“测量→建模→决策→配置→验证”的容量规划闭环。

限流算法深度与 Guava/Sentinel 源码：从单机令牌桶到分布式滑动窗口的流量防护体系本文是高并发与稳定性工程系列的第 1 篇。在总纲系列（《分布式系统架构认知与设计》）确立了“故障是常态”与“优雅降级”的核心原则，并深入拆解了超时公式、退避算法与跨层故障阻断策略之后，本文正式进入稳定性工程的第一道防线——限流。限流是整个高并发防御体系的基石，后续的熔断、降级、隔离、压测等机制，均建立在“先限住流量，再谈如何更优雅地处理被限流量”这一前提之上。

山屿落星辰

hixl - 让分布式训练“零拷贝“通信模式A（费曼科普）+ 架构原理剖析类型想象一下，你和朋友一起做PPT，但是每次改一页，都要把整个PPT文件发过来发过去。效率低吧？要是能只传"改动的那一页"，甚至"改动的那个文本框"，效率不就上去了？

SpringBoot自带TaskScheduler 接口使用详解:（02）微服务多实例模式下，爆发任务重复执行问题在集群模式下，由于 TaskScheduler 是单机本地调度器，每个服务实例都会独立运行并触发定时任务，从而导致任务重复执行。要解决这个问题，核心思路是引入分布式锁（Distributed Lock）机制，确保同一时刻只有一个节点能成功获取到执行权限。

基于 Outbox 事务表 + Canal 监听+kafka+多级缓存：高并发社交关注系统全链路架构设计在社交类业务系统中，用户关注与取关是访问量极高、并发压力大且对数据一致性要求严苛的核心场景，不仅需要应对用户高频点击、恶意刷接口等流量问题，还要解决消息丢失、重复消费、缓存与数据库数据偏差、粉丝关注计数不准等一系列线上常见难题。传统直接发送消息队列的开发模式，极易出现业务入库成功但消息投递失败，最终引发业务数据不一致的隐患。为此我基于实际业务场景，设计并落地了一套限流防护 + 多级缓存 + 本地事务事件表 + Canal 异步转发的完整高并发社交关系架构，通过前置流量拦截、事务保障事件可靠落地、分层缓存提

Redis集群：分布式高可用存储方案随着互联网业务的快速迭代与用户规模的持续增长，数据量级与并发访问量呈现爆发式攀升，单机Redis部署逐渐暴露出明显短板，难以突破内存上限、性能瓶颈与单点故障的三重限制，无法满足企业级业务对高可用、高并发、海量数据存储的核心需求。Redis集群（Cluster）作为Redis官方推出的分布式解决方案，通过数据分片技术实现存储容量的水平扩展，依托多主多从架构构建高可用保障体系，凭借其高效、可靠的特性，成为企业级高并发、海量数据场景下的核心存储支撑，广泛应用于电商、金融、社交等各类主流业务领域。

大数据之安装zookeeper官方下载地址：https://archive.apache.org/dist/zookeeper/日志目录和数据目录

Kafka重平衡机制深度解析消费者组重平衡（Rebalance）是Kafka中确保分区分配公平和容错的核心机制。当消费者加入或离开组、订阅主题变化、分区数量变更时，触发重平衡以重新分配分区所有权。

云原生持续交付：GitOps 与渐进式发布系列定位：本文是“微服务与云原生架构”系列的第 15 篇，在全景图中对应板块（10）——“持续交付与部署”。在完成从拆分、通信、治理、安全、配置、可观测到测试的全部架构与质量保障工作后，本文解决微服务的“最后一公里”问题：如何将变更安全、自动、可信地交付到生产环境。GitOps 是云原生时代持续交付的范式革命，渐进式发布则是避免生产事故的最后一道防线。