前言

单体应用时代，@Transactional 一行注解就能搞定事务。但拆成微服务后，一个业务可能横跨多个数据库、多个服务，分布式事务就成了绕不过去的坎。

网上讲分布式事务的文章铺天盖地，但大多数只讲理论。本文将结合担保业务系统的实际场景，深度对比 Saga、TCC、AT 三种主流分布式事务模式，给出选型决策树和落地方案。

一、为什么分布式事务这么难？

1.1 单机事务的局限性

在单体应用中，事务管理依赖数据库的 ACID 特性：

@Service
public class CreditService {
    @Autowired
    private CustomerMapper customerMapper;
    @Autowired
    private ContractMapper contractMapper;

    @Transactional
    public void applyCredit(CreditApplyRequest request) {
        customerMapper.insert(request.getCustomer());
        contractMapper.insert(request.getContract());
        // 要么都成功，要么都失败
    }
}

前言

在互联网高并发系统中，缓存已成为必不可少的基础设施。从单机Redis到分布式缓存集群，从简单的Key-Value存储到复杂的缓存一致性保障，每一步升级都关乎系统能否扛住业务增长的流量冲击。

本文从缓存分布策略、一致性哈希、三大缓存问题（穿透/击穿/雪崩）的原理与防护方案出发，结合生产实践经验，帮助架构师设计高可用、高性能的分布式缓存方案。

一、缓存分布策略：从单机到集群

1.1 单机Redis的瓶颈

前言

负载均衡是系统架构中最常用的组件。无论是Nginx、HAProxy、还是云原生的Service Mesh，都需要回答同一个问题：

"这个请求该发给哪个后端服务器？"

看似简单，但要在高并发、动态扩容、多地域等复杂场景下做出最优决策，需要深入理解各种算法的原理与权衡。

一、负载均衡的层次

1.1 四层 vs 七层

ISO/OSI 模型：

第7层 (应用层): HTTP/HTTPS
  └─ 可以看到请求内容 (URL、Header、Body)
  └─ 路由粒度细 (基于URL/Host/Cookie)
  └─ 性能: 中等 (需要解析HTTP)
  └─ 例: Nginx、HAProxy、Envoy

第4层 (传输层): TCP/UDP
  └─ 只能看到IP+Port
  └─ 路由粒度粗 (仅基于IP+Port)
  └─ 性能: 高 (无需解析应用层)
  └─ 例: LVS、F5、云Load Balancer

┌─────────────────────────┐
│  Client                 │
│ 127.0.0.1:12345        │
└────────────┬────────────┘
             │ TCP/IP
    ┌────────▼────────┐
    │ Layer 4 LB      │  ← 只看IP:Port，极快
    │ 10.0.0.1:80    │
    └────────┬────────┘
             │
    ┌────────▼────────┐
    │ Layer 7 LB      │  ← 解析HTTP，精细控制
    │ Nginx/Envoy     │
    └────────┬────────┘
             │
    ┌────────┴────────┐
    ▼                 ▼
 Backend1          Backend2

前言

互联网中，距离和延迟是性能的大敌。用户在北京访问托管在深圳的服务器，需要跨越千公里网络，延迟至少50ms。

CDN（Content Delivery Network） 的核心理念是：

远端服务器 ← 离用户最近的边缘节点
↓
通过全球分布的节点，将内容"推送"到用户身边

前言

分布式系统中，最难的问题是：如何在网络不可靠、节点可能宕机的环境下，让多个节点对某个值达成一致？

这就是 共识问题（Consensus Problem）。解决好这个问题，就能构建：

• 高可用数据库（MySQL复制、PostgreSQL）
• 分布式协调服务（Zookeeper、etcd）
• 一致性存储（Google Bigtable、HDFS）

本文从 CAP定理 出发，深入讲解 Paxos 和 Raft 两大共识算法的原理、差异与应用。

前言

在微服务架构中，服务通信是核心问题。传统做法是在应用层处理：

应用代码负责：
├─ 服务发现
├─ 负载均衡
├─ 重试、超时、熔断
├─ 监控、追踪、日志
└─ 安全认证

前言

传统单体应用中，数据库事务通过 ACID 保证一致性。但在微服务架构下，一个业务操作涉及多个服务、多个数据库，本地事务已无能为力。

以电商订单为例：

用户下单 → 订单服务（创建订单）
        → 库存服务（扣减库存）
        → 支付服务（扣款）
        → 积分服务（加积分）

任何一个环节失败，都需要回滚整个流程，但这四个服务各自管理数据库！

前言

Redis 几乎成了所有后端项目的标配组件，从简单的 KV 存储到分布式缓存，从消息队列到流处理，它的角色越来越多样。但当单机 Redis 无法满足需求时，分布式缓存就登场了。

本文将系统性地梳理分布式缓存的核心问题：Redis Cluster 的架构原理、一致性哈希算法、以及实战中最头疼的缓存穿透、击穿、雪崩三大问题及其解决方案。这些不是面试题，而是我在实际项目中真金白银踩过的坑。

一、单机 Redis 的瓶颈

1.1 为什么需要分布式？

单机 Redis 的瓶颈通常在三个方面：

站内信消息功能解决方案

在中大型网站开发中，站内信、系统通知、用户私信是核心基础功能，既要保证实时性、稳定性，也要兼顾架构的可扩展性和运维便捷性。结合之前的高频疑问（技术选型、端口使用、内外网区分等），梳理一套企业级落地解决方案，覆盖从需求到部署的全流程，重点补充大数据量、高并发场景下MQ的应用细节，新手也能直接参考落地。

一、核心需求明确（避免过度设计）

先明确功能边界，避免技术选型冗余，中大型网站消息功能核心需求通常分为3类，其中大数据量高并发场景需额外关注消息峰值处理：

• 系统推送：订单状态、审核结果、系统公告、活动提醒等（单向推送，无需用户回复）；高并发场景下可能出现批量推送（如活动通知、全员公告，峰值可达万级/秒）；

• 用户私信：用户之间的双向聊天、留言（需要实时双向通信）；高并发场景下需处理消息瞬时峰值（如热门活动互动、用户集中聊天）；

• 基础交互：未读红点提示、消息列表分页、已读/全部已读、消息删除、历史消息查询；高并发下需保证查询性能，避免卡顿。

概述

在高并发系统中，限流是一种重要的保护机制，用于控制请求流量，防止系统被过多请求冲击导致服务不可用。本文将基于提供的代码实现，详细介绍如何使用Spring AOP和Redis实现一个灵活的分布式限流组件。
该例子利用mysql进行黑名单的自动登记。

限流组件架构

1. 自定义限流注解 - RateLimiter

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RateLimiter {
    String key() default "rate_limit:";
    int time() default 60;
    int count() default 5;
    LimitType limitType() default LimitType.DEFAULT;
    boolean joinBlackList() default false;
}