这个系列写到第七篇前面六篇分别拆了分布式理论基础、存储选型、计算引擎、通信机制、一致性协议和任务调度后台催更的朋友一直在问同一个问题这些技术点单独看都能看懂到底怎么拼出一套真正能跑业务的分布式AI系统第七篇我换个写法不再讲孤立的技术点而是用一套实际搭建并运行过一段时间的中小规模AI训练平台做例子把分布式锁、分布式事务、分布式缓存、HDFS、分布式定时任务这些工程组件从头到尾串一遍。这篇内容适合两类人。一类是前六篇都看过、正打算从零搭系统的新人照着里面的思路能少走不少弯路另一类是只听说过Redis分布式锁和HDFS、但没机会在真实项目里把它们组合起来的开发者。我会把原理压缩到够用的程度把重心放在落地细节和故障排查上。文章里所有场景和故障都来自真实项目只是数据做了脱敏处理。如果你连Spring Cloud和Redis的基本概念还不熟建议先把前六篇或者对应的入门资料过一遍再来这篇默认你已经知道微服务大概是怎么一回事。1. 写在第七篇之前为什么这套系统值得拆开看1.1 前六篇讲了什么第七篇补什么先把系列脉络摆在这里方便没看全的朋友定位篇目核心主题主要内容一分布式基础CAP、BASE、RPC与通信模型二分布式存储数据分片、副本、文件存储选型三分布式计算MapReduce、流批一体、任务模型四分布式通信消息队列、事件驱动、异步编排五分布式一致性与协议共识、锁、分布式事务六分布式调度资源调度、任务编排、弹性伸缩七本篇工程落地与故障排查锁、事务、缓存、文件、定时任务串起来单独看每一篇都觉得有道理但真正动手写代码时会发现难的不是某个组件的API而是组件与组件之间的边界和取舍。Redis既能做分布式锁又能做缓存但这两件事对过期时间的要求完全不一样HDFS能存训练数据但小文件一多系统直接卡死分布式事务能解决一致性问题但滥用之后性能被拖垮。这些跨组件的经验就是第七篇想补的部分。1.2 一个足够真实的业务场景NLP训练平台我给这套系统设定的背景是一家做中文NLP服务的团队。平台每天从各个渠道采集约2TB原始语料经过文本清洗、样本切分、特征提取后进入模型训练训练好的模型经过评估和版本管理后上线到在线推理服务。整个链路涉及六个核心模块数据接入、预处理、任务调度中心、训练节点、模型仓库、在线推理。这六个模块没有哪个模块是特别复杂的但组合起来之后分布式系统的经典问题基本都出现了多节点同时跑任务需要防重跨服务修改数据需要一致性训练文件需要统一存储推理接口需要扛住突发流量定时任务需要在集群里分配。为了把问题讲清楚整套系统的技术栈我按当时团队的真实情况设定为Spring Cloud做微服务骨架Nacos做注册配置Gateway做入口OpenFeign做服务调用Redis承担分布式锁和缓存Kafka做异步消息RocketMQ在部分场景做事务消息HDFS负责训练数据和模型的存储xxl-job负责分布式定时任务MySQL保存业务元数据。1.3 技术选型背后的取舍逻辑这套选型在当时经历过好几轮讨论我把决策逻辑写出来不是为了证明哪个方案最好而是让大家看到权衡过程。Spring Cloud而不是Dubbo原因是团队对Spring生态更熟悉Gateway、OpenFeign、Nacos这些组件集成起来成本低。而且AI训练平台的并发量没有电商大促那么夸张服务治理的完整性和开发效率优先级更高。Redis一鱼多吃是刻意的锁、缓存、计数器、限流都交给它避免为了每件事单独引入一套中间件。但这里有个重要原则——同一套Redis实例可以复用key空间必须按业务严格隔离锁的key和缓存的key前缀要分得清清楚楚否则排查问题时根本分不清一段数据到底是缓存还是锁状态。HDFS的选择比较有争议因为现在云对象存储已经很成熟。当时团队已经有现成的Hadoop集群训练数据以GB到TB级的大文件为主读取模式是顺序读HDFS的高吞吐和副本机制非常匹配。它的代价是运维重、小文件管理困难这些代价在第4章会详细讲。分布式定时任务当时对比了Quartz集群方案和xxl-job最后选了后者因为它的控制台、失败告警和分片广播都是开箱即用省掉了自研调度监控的功夫。整套选型的原则就一条中间件种类能少则少把每个中间件的职责边界划清楚比追逐新技术更重要。2. 分布式并发控制分布式锁在AI任务调度里的真实作用2.1 竞态从哪来训练任务的重复执行先看一个我踩过的真实场景。调度中心在凌晨3点触发数据集A的清洗任务这个任务同时被投递到节点1和节点2。节点1在清洗过程中发生了短暂网络抖动调度中心判断它响应超时于是把任务重新投递到了节点2。结果同一份语料被两个节点同时清洗生成的特征文件数量翻倍下游模型训练直接报错。这种问题的本质是多个节点同时操作同一个共享资源单机锁完全管不住跨进程的行为。很多人第一反应是“给任务表加个唯一索引不就行了”但在这个例子里清洗任务不是往一张表插一行数据而是写文件系统、写缓存、更新任务状态、发消息多个动作分散在不同服务里。数据库唯一索引只能约束其中一条记录管不住整个执行过程的竞态。共享单车是一个更容易理解的类比明明一个座位两个用户同时扫码系统必须保证只有一个人能解锁骑走不能靠“自行车座位天然只有一个”这种物理条件来兜底要靠分布式锁在逻辑上做互斥。2.2 用Redisson实现一把靠得住的锁分布式锁最简单的实现是Redis的set nx ex命令但我不推荐手写。推荐的做法是直接用Redisson的RLock它在底层把锁的获取、释放、续期都封装好了。引入依赖后在配置类里指定Redis连接信息业务代码里用tryLock加finally释放核心就是几行代码Resource private RedissonClient redissonClient; public void cleanDataset(Long datasetId) { String lockKey train:lock:dataset: datasetId; RLock lock redissonClient.getLock(lockKey); boolean locked false; try { // 第一个参数是等待获取锁的时间第二个参数是锁的leaseTime locked lock.tryLock(3, 2, TimeUnit.HOURS); if (!locked) { throw new BusinessException(任务已被其他节点执行本次跳过); } doClean(datasetId); } finally { if (locked) { lock.unlock(); } } }这里有两个参数需要认真想。tryLock的第一个参数是等待时间第二个是leaseTime也就是锁的最长持有时间。Redisson有看门狗机制默认每30秒自动续期一次只要业务方法没结束锁就不会因为写死的时间过期。但leaseTime一旦显式指定看门狗就不会续期了所以上面对清洗任务给的2小时是拍脑袋估的一个上限。更稳的做法是配合任务执行时长监控把P95执行时间乘2作为leaseTime同时保证finally里一定能释放锁否则锁会一直占着。锁的key设计也很关键。这里用train:lock:dataset:{datasetId}既包含业务域又包含资源维度。value在Redisson内部是一个UUID释放锁时会校验value防止误删别人持有的锁。2.3 分布式锁的四个高频坑第一个坑是误删他人的锁。A任务还没执行完B任务等待超时后拿到了锁A任务的finally代码块执行del把B的锁删了B和C就能同时进入临界区。解决方法是删除前校验value并且这两步要放在同一个Lua脚本里保证原子性。Redisson的unlock内部就是这么做的这也是我推荐直接用组件而不是手写Redis锁的原因。第二个坑是锁过期但业务没跑完。AI数据清洗任务的时间波动非常大一条语料可能几分钟跑完另一条涉及复杂规范化处理的语料可能跑一小时。如果锁的续期逻辑没有做好业务执行一半锁就过期了另一个节点进来重复执行。解决思路有三条用看门狗自动续期、按P95执行时间设置leaseTime、以及最重要的——业务侧做幂等兜底。第三个坑是主从切换导致锁丢失。Redis主节点宕机锁的数据还没同步到从节点新主节点上根本没有这把锁另一个客户端就能加锁成功。严格场景下应该用RedLock或者ZooKeeper但RedLock本身也有争议而且会引入额外的运维复杂度。我个人的判断是在内部AI训练平台这种场景锁的丢失概率很低而且有幂等兜底可以接受用普通Redis锁。如果是金融支付场景这个结论完全不能套用。第四个坑是可重入。同一线程的嵌套方法如果都要拿同一把锁普通setnx会死锁自己。Redisson底层用hash结构记录了持有线程和重入次数天然支持可重入不需要额外处理。我在设计API时习惯把“锁的key归属哪个模块、哪些方法会重入”在代码注释里写清楚因为重入边界一旦混乱后续维护的人很容易改出锁不生效的问题。提示分布式锁解决的是“尽量不并发执行”真正不重复依赖的是幂等设计。锁 幂等表双重保护是线上推荐组合。2.4 分布式锁面试题与使用场景分布式锁是面试高频题网上相关的帖子也经常被翻出来。最常被问到的是Redis锁和ZooKeeper锁怎么选我的回答思路是这样的Redis的锁胜在性能好、实现简单适合高并发场景但极端情况下会有主从切换丢锁的风险ZooKeeper锁靠临时顺序节点存在性和分布式一致性都更强但加锁和释放的延迟高一些服务端模型也更重。实际选型要看业务对“锁一定不能失效”的容忍度。使用场景则围绕三类防止定时任务重复执行、防止跨节点资源竞争、防止类似超卖这种共享资源的超额分配。AI训练场景尤其要记住一句话分布式锁只是第一道防线任务执行记录的唯一索引、数据文件的版本号、消费者的幂等判断这些设计都要同步跟上否则再好的锁也救不了没有兜底的系统。3. 分布式数据一致性从订单库存到AI资源扣减3.1 AI系统里的“订单与库存”聊分布式事务网上的例子永远都是“订单与库存”。这个场景确实经典但它离很多开发者的日常工作太远了我有一个更贴近分布式AI系统的类比。用户在控制台发起一个模型训练任务前端服务要做三件事在配额服务里扣减GPU资源相当于扣库存在任务服务里创建训练任务记录相当于下单在版本服务里锁定当前数据集版本相当于写一个资源占用的状态。这三个操作分布在三个服务、三个数据库里。如果扣减GPU成功但任务创建失败用户的配额就凭空消失了如果任务创建成功但扣减失败集群资源就会被超额分配多个任务挤到同一块GPU上。这就是分布式系统里最典型的数据一致性问题。和订单库存的区别只在于资源形态库存扣的是商品数量这里扣的是GPU配额和版本占用。解决思路完全相同。3.2 强一致还是最终一致先看业务容忍度拿到一个分布式事务需求第一件事不是选框架而是判断业务能不能接受短暂的中间状态。我给当时的团队定了这样一张对比表方案一致性适用场景性能影响复杂度Seata AT2PC强一致链路短、响应要求快、改动量少中低TCC最终一致偏强资源预留、跨团队接口中高高本地消息表/事务消息最终一致异步链路、长事务低中Saga最终一致长流程、跨系统低高判断流程很简单如果几个操作都发生在一个请求的调用链路里用户同步等结果那就用Seata AT如果能容忍一定延迟用户可以稍后看到状态更新优先考虑事务消息或本地消息表如果涉及多个团队维护的服务且接口不能保证同时提交那就用TCC或Saga。AI训练平台里绝大多数链路都可以做成最终一致因为训练任务本身就是异步的用户不会死等一个同步结果。3.3 Seata AT模式快速上手AT模式的理解成本最低它在第一阶段拦截SQL把业务数据操作和undo_log一起提交到本地库第二阶段如果全部成功异步删除undo_log如果某个分支失败则根据undo_log生成反向SQL进行补偿。接入Seata的关键步骤是三件套引入依赖、配置注册中心、在需要开启分布式事务的方法上加上GlobalTransactional注解。dependency groupIdio.seata/groupId artifactIdseata-spring-boot-starter/artifactId version1.7.1/version /dependency配置上比较核心的几项包括事务组名称、注册中心和配置中心地址。数据源必须交给Seata的代理数据源管理否则全局事务不生效。业务代码里在入口方法加注解GlobalTransactional(name create-training-task, rollbackFor Exception.class) public void createTrainingTask(CreateTaskRequest request) { quotaService.deductGpuQuota(request.getGpuCount()); taskService.createTaskRecord(request); versionService.lockDatasetVersion(request.getDatasetVersion()); }如果上面三个方法中任何一个抛出异常Seata会在全局事务范围内把已提交的本地事务回滚。这个方案的性能开销主要在全局锁和undo_log写盘所以热点行的并发更新场景不适合。AI平台的资源扣减属于低频高敏感的写入正好适合。3.4 最终一致方案本地消息表与事务消息训练任务创建成功后还需要通知下游特征服务去拉取数据。如果通知发送失败上游已经提交下游没有感知任务数据就会出现缺口。这种异步链路的解法是本地消息表加消息投递。流程是这样的业务主表操作和消息表写入放在同一个本地事务里保证“业务成功消息记录一定存在”定时任务扫描消息表里status为0的记录投递到消息队列消费者收到消息后执行业务并把处理结果写回消息表原始投递方收到确认后把消息状态改为已发送。Transactional(rollbackFor Exception.class) public void createTrainingTaskWithMessage(CreateTaskRequest request) { taskService.createTaskRecord(request); messageMapper.insert(MessageRecord.ready(request.getTaskId())); }为了防止消息重复投递消费者必须做幂等通常用一张去重表记录业务唯一键重复消息直接跳过。轮询调度建议5秒一次批处理一次50条失败消息重试次数上限放到5次超过上限就进入人工补偿队列。这个方案的优点是性能好把一致性从同步变成了异步缺点是处理链路变长排查问题时需要同时看业务库、消息表、消费端日志三处。当时我们把训练任务通知做成这种模式之后消息漏发的情况基本归零。4. 分布式存储与文件系统HDFS在AI数据与模型中的定位4.1 训练数据要的存储不是普通硬盘AI场景对存储的需求和传统业务系统很不一样。训练数据是几十GB到几TB的大文件读取是顺序的流式读取同时会有多台训练节点并发读写不同文件。业务元数据可以放MySQL但训练语料和模型文件放数据库里肯定行不通它们需要一个能横向扩容的分布式文件系统。HDFS的设计正好契合这个场景文件被切分成数据块默认副本数3分布在多个DataNode上客户端通过NameNode获取元数据后直接流式读写数据块吞吐量能到很高的水平。另一个关键是模型文件的发布模式。很多团队把模型文件放在本地磁盘模型升级时直接覆盖正在加载的推理进程就会读到半个文件轻则加载失败重则内存数据损坏。我们的做法是把每个模型版本当成一个不可变对象写到HDFS的独立目录比如/models/ner/20250101_v3/推理服务启动时只从指定版本目录读取。要升级就切换目录路径不覆盖旧版本既方便回滚也避免了并发读写冲突。4.2 本地开发环境Hadoop伪分布式搭建开发环境不可能直接连生产集群本地联调最常用的就是Hadoop伪分布式模式。所谓伪分布式就是NameNode、DataNode、SecondaryNameNode都跑在同一台机器上用一套进程模拟完整集群。它的作用是让开发人员可以在本地验证HDFS读写逻辑。搭建步骤给大家列一下基于Hadoop 3.x版本下载解压Hadoop安装包并配置JAVA_HOME执行ssh localhost免密登录设置因为Hadoop启动脚本会通过ssh连接本机修改core-site.xml指定NameNode地址修改hdfs-site.xml设置副本数为1注意伪分布式副本数不能配置成3否则启动后会出现DataNode上报副本不足的告警。!-- core-site.xml -- configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property /configuration!-- hdfs-site.xml -- configuration property namedfs.replication/name value1/value /property /configuration然后执行格式化NameNode并启动hdfs namenode -format start-dfs.sh start-yarn.sh jpsjps输出里能看到NameNode、DataNode、ResourceManager、NodeManager等进程说明伪分布式已经跑起来了。网上关于这个流程的教程很多头歌平台也有配套的HDFS练习照着敲一遍基本能通。提示伪分布式只是开发联调的临时工具绝对不能拿到生产环境用。生产环境至少三台物理机起步NameNode要做成主备高可用元数据编辑日志要放到共享存储或JournalNode上。4.3 Java API读写HDFS的关键代码在Spring Boot项目里封装一个HDFS工具类很常见。先用Configuration指定fs.defaultFS然后通过FileSystem.get拿到文件系统实例。这里最容易被忽略的问题是FileSystem实例的复用如果每次操作都new一个FileSystem连接数会失控最终把DataNode的RPC端口打爆。Configuration public class HdfsConfig { Value(${hdfs.defaultFS}) private String defaultFS; Bean public FileSystem fileSystem() throws IOException { Configuration conf new Configuration(); conf.set(fs.defaultFS, defaultFS); conf.setBoolean(fs.hdfs.impl.disable.cache, false); return FileSystem.get(conf); } }上传训练文件的代码相当直接public void uploadLocalFile(String srcPath, String dstPath) throws IOException { Path src new Path(srcPath); Path dst new Path(dstPath); fileSystem.copyFromLocalFile(false, true, src, dst); log.info(uploaded {} to {}, srcPath, dstPath); }读取超大训练文件时用FileSystem.open拿到FSDataInputStream后按批次读取不要一次性把整个文件load到内存。生产环境如果开启了Kerberos认证代码内容会复杂很多需要在UserGroupInformation中做认证登录内网环境则可以关闭Kerberos用简化配置。具体内部网络如何配置参考你们公司的安全规范就好。4.4 小文件问题AI预处理最容易踩的坑HDFS有个著名的短板小文件太多会让NameNode内存爆掉。NameNode把每个文件、目录和块信息都放在内存里默认情况下一个文件大概占用150字节左右的元数据听起来不多但文件数量到了千万级内存压力就非常明显。AI预处理阶段特别容易制造这种灾难因为很多同事习惯“每条样本写一个文件”一个数据集几百万条语料就是几百万个文件NameNode不卡才怪。我们的解决方法是让样本数据按批次合并。清洗程序把一小时的语料写入同一个大文件文件内部用JSONL格式逐行存储每条样本一行同时写一个小的索引文件记录每个批次在文件里的起始偏移量。训练框架读取时按偏移量定位到批次再顺序读取这样既保住了顺序读的高吞吐又把文件数量降了几个数量级。中间过程产生的临时小文件则交给一个合并任务定期处理默认保留三天后清理。模型文件也遵循同样的思路一个版本只产出固定的几个大文件不会让推理服务在HDFS上做大量随机小文件读取。5. 分布式缓存与定时任务撑起AI推理与调度的骨架5.1 推理服务为什么要分布式缓存在线推理接口每次请求都要拿模型元数据、特征配置、限流白名单、AB实验开关这些数据读多写少全量打到MySQL上迟早出事。我们在推理服务前面加了一层Redis缓存缓存键按场景设计例如model:meta:{modelId}:{version}、feature:config:{modelId}。缓存策略用的是最普通的Cache Aside先更新数据库再删除缓存下次读请求触发回源。模型元数据版本化发布时直接删除旧版本缓存让新版本自然重新加载。这种策略简单但要小心缓存和数据库操作之间的时序问题。如果先删缓存再更新数据库读请求刚好夹在中间就会把旧数据写回缓存。所以正确顺序一定是先更新数据库再删缓存。另外热点模型的缓存key一定要带版本号。曾经因为发布新版本后没有改缓存key推理服务一直在喂旧模型给用户排查了很久才发现是key设计的问题。5.2 穿透、击穿、雪崩AI接口的保命手段缓存三大经典问题在AI推理场景里全都会出现。先说穿透很多人会拿不存在的模型ID反复调用接口Redis查不到、MySQL也查不到每次都穿透到数据库。处理办法是空值缓存加布隆过滤器。空值缓存就是查不到也往缓存里写一个标记过期时间设短一些布隆过滤器则是在请求进入时先判断ID是否可能存在不存在的直接返回连Redis都不查。击穿是某个爆款模型的元数据缓存恰好过期瞬间大量请求发现缓存没数据全量回源数据库数据库直接被压垮。重建缓存的方法需要加互斥逻辑public ModelMeta getModelMetaFromCache(String modelId) { String key model:meta: modelId; ModelMeta meta cache.get(key); if (meta ! null) { return meta; } String lockKey model:meta:lock: modelId; RLock lock redissonClient.getLock(lockKey); if (lock.tryLock()) { try { meta cache.get(key); if (meta null) { meta loadFromDb(modelId); cache.set(key, meta, randomExpireTime()); } return meta; } finally { lock.unlock(); } } else { return retryReadCache(modelId); } }雪崩则是大量缓存同一时间过期导致数据库压力集中解决办法是给过期时间加随机偏移让过期时刻分散。AI平台里不同模型的缓存过期时间本来就不一样所以雪崩风险相对低一些但统一管理时还是要把随机偏移加上。配合监控Redis命中率和数据库连接数这些问题就能在早期被发现。注意缓存设计必须把“正常数据过期”和“异常数据穿透”两个场景分开考虑只解决其中一个仍然会出事。5.3 分布式定时任务为什么不能只用Scheduled单体系统用Spring的Scheduled是最简单的选择但在微服务多实例部署时每个节点都会执行一次同样的定时逻辑数据库里会多出几份重复任务。这时需要分布式定时任务框架。我们评估过几种方案各自的定位很清楚方案特点适合场景Quartz集群基于数据库锁部署简单但控制台和告警弱小规模、无运维成本xxl-job自带调度中心、执行器、日志、故障转移、分片路由中大规模推荐SchedulerX等云服务托管、免运维、功能强有云资源且团队人力少自研灵活但成本高特殊调度需求最终选了xxl-job原因很直接调度中心独立部署不占用业务节点资源执行器和任务可以带标签失败重试、超时熔断、动态控制台都很成熟。更重要的是它支持分片广播这对AI训练任务来说太关键了下一节具体说。5.4 xxl-job接入与AI批次调度xxl-job的接入思路是调度中心负责触发任务业务服务作为执行器注册上来任务处理逻辑写在加了XxlJob注解的方法里。引入依赖后在配置类里注册XxlJobSpringExecutor然后实现一个清洗任务的HandlerComponent public class DataCleanJob { XxlJob(dataCleanJob) public void execute() { int shardIndex XxlJobHelper.getShardIndex(); int shardTotal XxlJobHelper.getShardTotal(); ListLong datasetIds datasetService.findByShard(shardIndex, shardTotal); datasetIds.forEach(datasetId - { // 内部再用分布式锁保证同一数据集不被同时清洗 cleanService.cleanWithLock(datasetId); }); } }调度中心的任务配置里把路由策略选成“分片广播”触发器发起一次调度集群里每个节点都会执行这个方法但每个节点拿到的分片参数不同。拿100个数据集、10个节点来说每个节点分到10个数据集任务整体从串行变成了并行。清洗内部还要再套一层分布式锁目的是防止某个数据集在分片边界出问题被两个节点同时处理。这种“框架分片 业务锁 幂等表”三层防护是我们在线上跑出来的可靠组合。6. 生产环境故障排查实录与避坑清单6.1 故障一定时任务三天两头跑重第一次出这个问题时xxl-job配置的故障转移策略是默认的某个执行器节点因为网络分区失联调度中心把任务分给了另一个节点。但原节点其实还在运行没有真正死掉网络恢复后两个节点都在执行同一个清洗任务数据洗了两遍。当时最气愤的是监控里看不到任何报错因为两个任务都成功结束只是结果多了一份。排查过程先确认没有数据库锁、没有任务执行记录表也就是任务本身没有任何幂等保护。随后只能靠HDFS目录里相同时间戳的文件名对比才定位到重复执行。修复动作分了三步任务入口加Redisson分布式锁锁key带数据集ID和日期新增task_run_log表记录每次执行的唯一键对(datasetId, execDate)建唯一索引最后把xxl-job的路由策略改成了“一致性哈希”让同一个数据集尽量固定到同一节点。这套组合上线后同类问题再没出现过。6.2 故障二一个热门模型打垮数据库现象是某天下午推理接口的P999延迟从200毫秒涨到5秒MySQL CPU一路飘红应用连接池不断报获取连接超时。日志一看某个热门模型在14:00整缓存过期紧接着爆发了一波请求Redis没数据全部回源MySQL。单个回源并不可怕可怕的是同一时间成千上万个请求一起回源数据库瞬间被打崩。修复方法就是第5章的互斥锁重建加空值缓存。另外还发现了一个容易被忽略的问题异常调用会用不存在的模型ID循环请求而空值缓存只缓存了正常模型的空结果没有覆盖“查询不存在资源”的情况。我们在网关层加了对模型ID格式和存在性的前置校验再配合布隆过滤器挡住明显不合法的请求穿透流量降了90%以上。这次故障给我的教训是缓存设计必须把“正常数据过期”和“恶意/异常数据穿透”两个场景分开考虑只解决其中一个仍然会出事。6.3 故障三NameNode频繁GCHDFS越来越卡第三次故障不是业务接口出事而是底层存储慢慢恶化。集群扩容之后HDFS反而越来越慢NameNode老年代GC越来越频繁active节点每隔几小时就主动切换一次。检查fsimage发现文件数量已经超过8000万而集群明明只有几十TB数据说明绝大多数都是小文件。追溯来源清洗服务某次版本改动把每一条新闻正文都写成了独立文件跑了一周就多出几千万个文件。处理方案分两步。存量小文件在业务低峰期通过distcp辅助合并合并完成后清理原文件存量清理后把清洗服务改回按小时批次合并大文件的模式同时加了一个监控指标NameNode文件总数超过阈值就告警。现在回想如果早把第4章的小文件治理做到位这次故障完全可以避免。NameNode的内存水位和文件总量这两个指标应该纳入每个HDFS集群的常规巡检。6.4 避坑清单把在生产环境积累的教训整理成一份可以直接当工作手册用的清单问题场景建议做法核心原因生产用伪分布式HDFS至少3节点NameNode做HA伪分布式是单点性能完全不行手写Redis锁用Redisson或封装Lua脚本原生setnx无法处理续期和误删业务出问题时依赖锁兜底锁幂等表双重保护锁只能降低冲突概率不能保证不重复分布式事务无脑Seata能异步尽量异步能最终一致不要强一致AT模式有全局锁热点场景不友好缓存key不带版本号模型发布时带上版本或变更key避免发布后读到旧缓存异常请求穿透缓存网关校验布隆过滤器空值缓存穿透流量比正常流量更难防护HDFS小文件不治理按批次合并大文件监控文件总数NameNode元数据内存会被耗尽定时任务没有执行记录写task_run_log并建唯一索引没有审计和幂等依据7. 大模型时代这套骨架还够用吗7.1 大模型训练要的分布式不止这些现在聊分布式AI大家更多想到的是大模型训练。大模型的参数规模在百亿甚至千亿级别单卡根本放不下所以出现了张量并行、流水线并行、数据并行还有AllReduce通信原语和参数服务器架构。这些是训练框架层面的分布式和这篇讨论的“业务平台中间件”是两个维度前者的性能瓶颈在网络带宽和显存后者的瓶颈在服务治理和一致性。但大模型业务同样离不开业务侧的分布式平台。训练之前的语料清洗、数据版本管理、模型发布回滚、推理服务的流量治理这些环节仍然要依赖Redis、HDFS、消息队列、分布式锁这些底座。不要把两者对立起来做AI应用的公司通常同时拥有两条线一条是训练框架团队优化计算效率另一条是平台工程团队提供稳定可靠的存储和调度。7.2 AI Agent与分布式任务编排最近AI Agent的热度非常高各类智能体应用开始把复杂任务拆成多个子任务调用工具、检索知识库、生成文本、做校验整个流程很可能横跨多个服务。从工程角度来看AI Agent编排和传统分布式任务编排并没有本质区别依然要面对任务幂等、失败重试、资源限流、上下文追踪这些问题。xxl-job的分片能力、分布式锁的互斥能力、缓存的降级能力在Agent场景里都能直接复用。区别在于Agent的任务图更动态不是预先写死的固定流水线可能要根据中间结果动态决定下一步调哪个工具。这意味着调度中心需要支持更灵活的DAG编排和运行时可变的流程定义这是当前开源定时任务框架普遍还比较弱的点。如果后续要做Agent平台我的建议是先沿用成熟调度框架解决周期性和并发调度再在业务层实现DAG状态机让Agent任务也能享受平台级的可观测性。7.3 我个人这几年最深的体会写到这里说点运行这套系统几年后的真实感受。分布式系统最核心的能力不是会用多少中间件而是能不能在出现问题时快速定位出“到底是哪个环节的哪一项约定被破坏了”。锁、事务、缓存、文件系统、定时任务每一个组件都有它的失效模式真正熟练的工程师不是靠经验去猜而是靠完整的日志、指标和链路追踪把失效模式暴露出来。这也是为什么我在每一章都强调幂等、监控和边界设计。下一篇我打算专门写分布式链路追踪和可观测性把trace、metric、log三块如何打通、如何从一次偶发超时顺着调用链一路追到HDFS写入缓慢完整讲一遍。如果大家在做分布式AI系统时也踩过类似的坑或者对某个组件组合有更好的方案欢迎在评论区把案例留下来我用下一篇文章来回复。
