分布式锁：跨节点的互斥控制

1. 核心作用

✅ 保证唯一性：在分布式环境中，多个节点并发操作同一资源时，确保同一时刻只有一个节点能执行关键代码（如订单扣款）。
✅ 避免脏读/覆盖：防止多节点同时修改同一份数据导致的数据不一致。
⚠️ 典型场景：全局ID生成、秒杀库存扣减、分布式任务调度。

2. 主流实现方案对比

3. 关键注意事项

• 🔒 锁超时释放：必须设置合理的TTL（Time-To-Live），避免死锁导致的永久阻塞。
• 🚨 羊群效应防范：大量客户端同时抢锁失败时，需通过随机延迟或队列化请求缓解压力。
• 🔍 可重入性：同一线程多次获取锁应允许，否则可能导致死锁（需记录持有者身份）。

二、数据库分片：横向扩展的核心手段

1. 为什么需要分片？

单机数据库面临两大瓶颈：
① 存储容量限制：单表数据量超过千万级后查询变慢；
② 并发写入压力：高吞吐场景下主从复制延迟加剧。
⚙️ 分片本质：将数据按规则分散到多个独立数据库实例，突破单点极限。

2. 分片策略选择

3. 分片带来的挑战与对策

• 🤔 跨分片事务：
  • ❌ 传统ACID事务不可行 → 采用最终一致性方案（Saga模式、TCC两阶段提交）；
  • ✔️ 局部事务+补偿机制（如支付宝的分布式事务框架DT）。
• 📱 SQL路由改造：ORM框架需支持分片键透明传递（如MyBatis ShardingSphere插件）。
• 📌 全局ID生成：雪花算法(Snowflake) + 分片标识符，确保ID全局唯一且有序。

三、微服务架构：模块化设计的利与弊

1. 微服务核心特征

2. 典型分层架构

[网关层] → [业务服务] → [领域模型服务] → [基础设施服务]
          ↓               ↓                ↓
      API Gateway     Order Service    Payment Service
                   ↓                ↓
               Inventory Service  User Service

• 🔗 服务间通信：同步调用（OpenFeign/Dubbo）用于实时交互，异步事件（Kafka/RabbitMQ）解耦非核心流程。
• 📦 服务治理：Nacos/Eureka注册中心提供服务发现，Sentinel实现熔断降级，Zipkin进行链路追踪。

3. 微服务落地难点

• 🔄 分布式事务：跨服务的数据一致性通过Saga模式或Seata框架保障；
• 🌐 网络延迟：一次请求可能涉及多个服务跳转，需优化链路（如合并批量查询）；
• 🔄 版本兼容：接口变更需严格遵循向后兼容原则，配合灰度发布策略。

四、三者协同实践：电商秒杀系统示例

1. 架构设计

• 前端流量入口：网关限流（令牌桶算法）+ 缓存预热（热门商品提前加载）；
• 库存服务：采用Redis分布式锁控制库存扣减，结合Lua脚本保证原子性；
• 订单服务：按用户ID哈希分片，避免单点过热；
• 支付服务：独立部署，通过消息队列异步处理支付结果通知。

2. 关键流程

用户请求 → 网关鉴权 → 库存预扣（Redis Lock）→ 生成订单（分库分表）→ 发送支付请求（MQ）→ 回调更新状态

• 🔒 分布式锁应用：库存扣减时使用Redlock算法，设置500ms超时防止死锁；
• 📚 数据库分片：订单表按user_id % 8分片至8个数据库，提升并发写入能力；
• 🕸 微服务协作：库存服务与订单服务通过gRPC同步调用，支付结果通过RocketMQ异步通知。

3. 监控与调优

• 📊 指标看板：Prometheus监控各服务的QPS、响应时间、锁等待时长；
• 💡 动态扩缩容：根据预售期间的流量预测，提前扩容库存服务和DB分片；
• 🔄 降级预案：当第三方支付接口超时时，切换至备用支付通道并记录异常日志。

总结：技术选型地图

通过合理组合分布式锁、数据库分片和微服务架构，可在保证系统可用性和扩展性的同时，有效应对高并发、大数据量的业务挑战。