服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

做文件上传系统的同学肯定都遇到过这个问题：多个用户同时上传同名文件，或者同一个用户在多个设备上上传同一个文件，结果文件被覆盖了，或者文件内容混乱了。这些问题听起来像是低级 bug，但背后折射出的是分片上传场景下并发控制的复杂性。 特别是在大文件分片上传场景下，一个文件被分成几十个甚至上百个分片上传，如果没有做好并发控制，后果可能是： 用户 A 的文件被用户 B 的分片覆盖，导致文件损坏 同一个上传任务被多个请求同时处理，造成资源浪费 合并时出现竞争条件，最终文件内容混乱 文件状态不一致，有的说上传成功，有的说还在上传中 今天我们就来聊聊分片上传并发冲突的架构设计，使用分布式锁和状态机来彻底杜绝并发问题。 分片上传的并发痛点 先来分析一下分片上传的并发痛点在哪里。很多团队会说："我们用了唯一ID，每个文件都有唯一的 fileKey，怎么还会有冲突？" 实际情况远比这复杂： 1. 同名文件上传冲突 多个用户同时上传同名文件： 用户 A 正在上传 file.txt 用户 B 也上传 file.txt 如果只按文件名来做 key，两个文件会互相覆盖 2. 同一个上传任务被重复触发 用户....

导语 在分布式系统中，跨服务操作是常见的场景。然而，当多个服务同时操作共享资源时，可能会出现竞态条件和死锁问题。分布式锁是解决这类问题的有效手段，但如何处理锁的超时释放和事务的回滚，是一个需要仔细考虑的问题。 一、分布式锁的原理与实现 1.1 分布式锁的概念 分布式锁是一种在分布式系统中用于协调多个服务对共享资源访问的机制。它确保在同一时间只有一个服务能够访问特定的资源，从而避免竞态条件和数据不一致的问题。 1.2 分布式锁的实现方式 1. 基于 Redis 的分布式锁 使用 Redis 的 SETNX 命令 支持过期时间设置 实现简单，性能高 2. 基于 ZooKeeper 的分布式锁 使用 ZooKeeper 的临时节点 支持顺序锁和公平锁 可靠性高，但性能相对较低 3. 基于数据库的分布式锁 使用数据库的唯一约束 实现简单，但性能较低 1.3 分布式锁的特性 特性描述 互斥性同一时间只有一个服务能够获取锁 可重入性同一服务可以多次获取同一把锁 超时释放锁在一定时间后自动释放，防止死锁 高可用性锁服务高可用，避免单点故障 公平性按照请求顺序获取锁 二、事务超....

一、跨服务操作的那些坑，你踩过几个？ 你是否有遇到过：用户在APP上兑换了一个价值1000积分的优惠券，系统扣了积分，但是优惠券没有发放成功。用户投诉到客服，客服查了半天，发现是中间某个服务调用失败了，导致整个流程中断。 更麻烦的是，因为是跨服务操作，数据不一致的问题很难定位和修复，最后只能手动给用户补发优惠券。 这样的场景，作为后端开发的你，是不是似曾相识？ 二、为什么跨服务操作这么难？ 在微服务架构下，一个业务流程往往需要多个服务协同完成： 订单服务创建订单 库存服务扣减库存 支付服务处理支付 物流服务安排发货 每个服务都是独立部署的，都有自己的数据库。当一个业务流程需要跨越多个服务时，原子性就成了一个大问题。 什么是原子性？简单来说，就是"要么全做，要么全不做"。 在单体应用中，我们可以使用数据库事务来保证原子性。但在微服务架构下，分布式事务的实现变得非常复杂。 三、分布式事务的困境 提到分布式事务，很多人会想到： 2PC（两阶段提交）：性能差，容易阻塞 TCC（Try-Confirm-Cancel）：实现复杂，需要业务侵入 Saga：长事务，状态管理复杂 本地消息表：依赖....

相信很多小伙伴都遇到过这样的场景：系统部署在多台服务器上，每个服务器都配置了相同的定时任务，到了执行时间，所有服务器上的任务一起触发，不仅浪费系统资源，还可能导致数据不一致等问题。这可怎么办呢？今天我们来聊聊一个在分布式系统中非常常见的问题：如何避免集群环境下定时任务的重复执行？ 问题的根源：集群环境下的定时任务困境 在单体应用时代，定时任务的执行很简单，就是到了指定时间点就执行。但在微服务或集群环境下，情况就变得复杂了。 想象一下，你有一个清理过期数据的定时任务，设定每天凌晨2点执行。如果你的系统部署在5台服务器上，那么就会有5个清理任务同时运行，不仅浪费资源，还可能因为并发操作导致数据混乱。 这就是分布式锁要解决的核心问题：如何在多个节点中协调，确保同一时间只有一个节点执行特定的任务。 解决方案概览 目前业界主流的分布式锁实现方案主要有三种： 基于Redis的分布式锁 基于数据库的分布式锁 基于Zookeeper的分布式锁 每种方案都有其独特的优势和适用场景，下面我们来详细对比一下。 方案一：基于Redis的分布式锁 实现原理 Redis的分布式锁实现主要依靠其原子性操作。我们....