CDN+Nginx百亿级流量架构搭建与Java微服务落地指南

作者：淘书创始人

摘要

CDN+Nginx百亿级流量架构搭建与Java微服务落地指南

CDN+Nginx百亿级流量架构搭建与Java微服务落地指南

核心定位：百亿级流量（日均请求量100亿+，峰值QPS千万级）的架构核心，是“CDN边缘分流卸压+Nginx多层负载扛并发+Java微服务弹性扩缩”的深度协同。整体遵循“边缘承接-接入转发-核心处理-数据支撑”四层逻辑，CDN承接90%+静态流量，Nginx作为动态流量入口实现百亿级转发与精细化控制，Java微服务按业务域拆分承载核心逻辑，全程保障高可用（99.99%+）、低延迟（动态请求响应<200ms）、可扩展。

适用场景：电商、短视频、资讯、直播等高频访问业务，本文兼顾架构搭建逻辑、关键配置、Java微服务实例，可直接落地于百亿级流量业务场景。

一、架构整体拓扑（百亿级流量适配版）

全链路架构按“流量流向”分层设计，各层均做水平扩容与容灾，避免单节点瓶颈，拓扑如下：

用户端（全国/海外）→ 运营商骨干网 → CDN边缘节点（300+地市，全运营商）

↓（静态缓存命中/动态流量转发，静态占比≥90%）

CDN区域调度节点 → 接入层Nginx集群（多地域+多可用区，四层LVS前置）

↓（百亿级动态流量转发、限流、SSL卸载）

应用层Nginx集群（按业务域拆分）→ Java微服务集群（K8s容器化，弹性扩容）

↓（核心业务逻辑处理）

数据层（Redis Cluster+MySQL分库分表+ES集群）→ 监控告警平台

核心逻辑：CDN先过滤掉绝大多数静态流量，仅剩10%以内的动态核心流量进入Nginx层，通过多层Nginx负载均摊压力，再转发至Java微服务，数据层提供高并发存储支撑，全链路无单点故障。

二、各层架构搭建与关键配置（百亿级流量核心）

第一层：CDN层（边缘分流，降低核心压力）

CDN作为流量第一入口，核心目标是“静态全下沉、动态轻转发”，减少Nginx与微服务层的负载，搭建要点如下：

  1. 节点与调度配置

  • •

    节点选型：采用“边缘POP节点-区域调度节点-源站节点”三级组网，国内覆盖350+地市，海外覆盖20+国家，全运营商适配（电信/联通/移动/广电），单边缘节点带宽≥20Gbps，总带宽≥20Tbps。

  • •

    调度策略：开启DNS智能解析+IPAnycast+链路质量探测，按用户地域、运营商、节点健康状态（负载率、延迟、错误率）动态分配节点，95%用户实现“跨网延迟<20ms、接入跳数≤3”。

  1. 静态资源缓存配置（承接90%+流量）

按资源类型精细化配置缓存策略，确保缓存命中率≥99%，回源率≤1%，避免静态流量冲击Nginx：

资源类型

缓存TTL

关键配置

图片（封面/缩略图）

30天

内存缓存优先，热点图预加载，开启WebP自动转码（压缩率≥50%）

视频切片（.m3u8/.ts）

14天

分段缓存，用户播放第1段时预加载后3段，降低卡顿率

JS/CSS/静态网页

7天

按版本号命名（如app.v3.js），永久缓存，更新靠版本号刷新

  1. 动态流量转发配置

对无法静态化的动态请求（如接口调用、登录验证），CDN开启“动态加速”模式，不缓存数据，仅做链路优化与请求过滤：

  • •

    开启连接复用：CDN与接入层Nginx保持长连接，单节点长连接数≥10万，减少TCP建联压力。

  • •

    请求过滤：拦截恶意请求（爬虫、SQL注入、空请求），过滤无效流量，降低Nginx处理压力。

  • •

    链路优选：实时探测至各地域接入层Nginx的链路质量，动态选择最优链路转发，避免跨地域绕路。

第二层：Nginx层（百亿级动态流量承载核心）

Nginx作为动态流量的核心入口，需采用“四层LVS+七层Nginx”二级架构，按“接入层-应用层”拆分，实现百亿级转发、限流、熔断，搭建与配置要点如下：

  1. 架构部署（水平扩容，无单点）

  • •

    前置四层负载（LVS/DPU）：部署在接入层Nginx集群前端，采用LVS-DR模式，单台LVS支持百万级并发，吞吐量≥10Gbps，按“源IP哈希+权重”策略，将流量均摊至接入层Nginx节点，同时做会话初步保持。

  • •

    接入层Nginx集群：跨2-4个地域、多可用区部署，单地域节点数≥50台（32核64G，SSD硬盘），总并发承载能力≥千万级，核心负责SSL卸载、全局限流、流量转发至应用层Nginx。

  • •

    应用层Nginx集群：按业务域拆分（用户域、商品域、订单域），每个业务域独立部署Nginx集群，节点数≥30台，核心负责URL路由、业务级限流、转发至对应Java微服务集群，实现业务解耦。

  1. 关键配置（百亿级流量适配优化）

（1）性能优化配置（nginx.conf核心参数）

核心进程配置，等于CPU核心数

worker_processes 32;

绑定CPU核心，避免进程切换开销

worker_cpu_affinity 00000001 00000010 … 10000000;

单进程最大连接数

worker_connections 65535;

开启epoll模型，提升高并发处理能力

use epoll;

连接复用超时时间

keepalive_timeout 60s;

长连接请求数上限

keepalive_requests 10000;

HTTP核心配置

http {
# 开启gzip/Brotli压缩，减少传输量
gzip on;
gzip_types text/plain application/json application/javascript;
brotli on;
brotli_types text/plain application/json application/javascript;

# 开启连接池，复用与微服务的连接
upstream user_service {
    server 10.0.0.1:8080 weight=1 max_fails=3 fail_timeout=10s;
    server 10.0.0.2:8080 weight=1 max_fails=3 fail_timeout=10s;
    keepalive 300; # 每个Nginx节点与微服务保持300个长连接
}

# 接入层全局限流（按IP）
limit_req_zone $binary_remote_addr zone=ip_limit:100m rate=100r/s;

server {
    listen 443 ssl http2;
    server_name api.xxx.com;

    # SSL卸载配置（转移加解密压力）
    ssl_certificate /etc/nginx/ssl/xxx.crt;
    ssl_certificate_key /etc/nginx/ssl/xxx.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_cache shared:SSL:100m;
    ssl_session_timeout 10m;

    # 全局IP限流
    limit_req zone=ip_limit burst=200 nodelay;

    # 动态请求转发（用户域）
    location /api/user/ {
        proxy_pass http://user_service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # 业务级限流（用户接口每秒50万请求）
        limit_req zone=user_limit:50m rate=500000r/s;
    }
}

}

（2）高可用配置

  • •

    故障自动剔除：通过upstream的max_fails、fail_timeout参数，对健康检查失败的微服务节点自动剔除，故障恢复后自动重新加入集群。

  • •

    限流熔断：接入层做全局IP限流（单IP每秒100请求），应用层按业务域做接口级限流，超出阈值返回429状态码，避免流量过载。

  • •

    日志优化：关闭不必要的访问日志，仅记录错误日志与核心业务日志，日志异步写入磁盘，减少IO开销。

第二层扩展：Nginx+Netty百万级长连接架构（高并发连接承载）

在百亿级流量架构中，针对即时通讯、直播互动、物联网推送等场景，需支撑百万级长连接（TCP/WebSocket），仅靠Nginx难以满足连接数上限与低延迟需求，需构建“Nginx反向代理+Netty服务集群”架构，Nginx负责负载分发、SSL卸载、连接复用，Netty负责核心长连接维护与业务处理，协同实现百万级长连接承载。

  1. 架构设计（百万级长连接适配）

整体遵循“分层承载、连接复用、弹性扩容”原则，架构拓扑融入原有链路：

CDN动态转发 → 接入层LVS → 长连接Nginx集群 → Netty服务集群（K8s容器化） → Redis Pub/Sub（消息分发）/MySQL分库分表

  • •

    长连接Nginx集群：跨多可用区部署，单节点（32核64G）支持10万+并发长连接，集群总连接承载≥100万，核心负责长连接接入、负载分发至Netty节点、SSL卸载（WebSocket/TCP）、连接健康检测。

  • •

    Netty服务集群：按业务分片部署（如按用户ID哈希分片），单Netty节点（16核32G）维持5-8万长连接，集群节点数可弹性扩展至20+，核心负责长连接维护、心跳检测、消息收发、业务逻辑处理。

  • •

    会话存储：Redis Cluster存储长连接会话映射（用户ID→Netty节点IP+端口），支持秒级查询与更新，确保消息精准路由。

  1. 核心配置（Nginx+Netty）

（1）Nginx长连接优化配置（nginx.conf补充）

长连接专用Nginx配置

worker_processes 32;
worker_cpu_affinity 00000001 00000010 … 10000000;
worker_rlimit_nofile 1000000; # 提升单进程最大文件描述符（支撑百万连接）

events {
use epoll;
worker_connections 65535;
multi_accept on; # 批量接收连接
accept_mutex on; # 防止惊群效应
}

http {
# WebSocket长连接配置
map $http_upgrade $connection_upgrade {
default upgrade;
‘’ close;
}

# Netty服务集群 upstream
upstream netty_long_conn {
    server 10.0.3.10:8090 weight=1 max_fails=3 fail_timeout=10s;
    server 10.0.3.11:8090 weight=1 max_fails=3 fail_timeout=10s;
    ip_hash; # 按源IP哈希，维持会话粘滞
    keepalive 5000; # 与Netty保持5000个长连接复用
}

server {
    listen 443 ssl http2;
    server_name ws.xxx.com; # 长连接专用域名

    # SSL卸载（WebSocket/TCP共用）
    ssl_certificate /etc/nginx/ssl/xxx.crt;
    ssl_certificate_key /etc/nginx/ssl/xxx.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_cache shared:SSL:100m;
    ssl_session_timeout 10m;

    # WebSocket长连接转发
    location /ws {
        proxy_pass http://netty_long_conn;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 3600s; # 长连接超时时间（与Netty心跳一致）
        proxy_send_timeout 3600s;
    }

    # TCP长连接转发（stream模块配置，需单独开启）
    stream {
        upstream tcp_long_conn {
            server 10.0.3.10:8091 weight=1;
            server 10.0.3.11:8091 weight=1;
            ip_hash;
        }
        server {
            listen 8091;
            proxy_pass tcp_long_conn;
            proxy_timeout 3600s;
        }
    }
}

}

（2）Netty百万级长连接优化配置（Java代码核心片段）

public class NettyLongConnServer {
public static void main(String[] args) {
EventLoopGroup bossGroup = new NioEventLoopGroup(4); // 监听线程组（核心数/2）
EventLoopGroup workerGroup = new NioEventLoopGroup(32); // 工作线程组（等于CPU核心数）
try {
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG, 10240) // 连接队列大小
.option(ChannelOption.SO_REUSEADDR, true) // 复用端口
.childOption(ChannelOption.SO_KEEPALIVE, true) // 开启TCP心跳
.childOption(ChannelOption.TCP_NODELAY, true) // 禁用Nagle算法（低延迟）
.childOption(ChannelOption.CONNECT_TIMEOUT_MILLIS, 3000)
// 调整接收/发送缓冲区大小（适配长连接消息传输）
.childOption(ChannelOption.SO_RCVBUF, 64 * 1024)
.childOption(ChannelOption.SO_SNDBUF, 64 * 1024)
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
// WebSocket协议解码（如需支持WebSocket）
pipeline.addLast(new HttpServerCodec());
pipeline.addLast(new HttpObjectAggregator(65536));
pipeline.addLast(new WebSocketServerProtocolHandler(“/ws”, null, true, 65536 * 10));
// 心跳检测（300秒读超时，60秒写心跳，300秒读写超时）
pipeline.addLast(new IdleStateHandler(300, 60, 300, TimeUnit.SECONDS));
// 自定义业务处理器（长连接维护、消息处理）
pipeline.addLast(new LongConnBusinessHandler());
}
});

// 绑定端口，启动服务（支持WebSocket和TCP双端口）
        ChannelFuture wsFuture = bootstrap.bind(8090).sync(); // WebSocket端口
        ChannelFuture tcpFuture = bootstrap.bind(8091).sync(); // TCP端口
        System.out.println("Netty长连接服务启动成功，WebSocket端口：8090，TCP端口：8091");

        // 等待服务关闭
        wsFuture.channel().closeFuture().sync();
        tcpFuture.channel().closeFuture().sync();
    } catch (InterruptedException e) {
        e.printStackTrace();
    } finally {
        bossGroup.shutdownGracefully();
        workerGroup.shutdownGracefully();
    }
}

}

  1. 百万级长连接核心优化要点

  • •

    系统参数调优：Linux服务器调整内核参数（/etc/sysctl.conf），提升连接承载能力：
    # 提升最大文件描述符（全局）
    echo “* soft nofile 1048576” >> /etc/security/limits.conf
    echo “* hard nofile 1048576” >> /etc/security/limits.conf

内核参数优化

sysctl -w net.core.somaxconn=10240 # 监听队列大小
sysctl -w net.ipv4.tcp_max_syn_backlog=16384 # SYN队列大小
sysctl -w net.ipv4.tcp_tw_reuse=1 # 复用TIME_WAIT连接
sysctl -w net.ipv4.tcp_tw_recycle=0 # 关闭TIME_WAIT快速回收（避免连接异常）
sysctl -w net.ipv4.tcp_keepalive_time=300 # TCP心跳间隔（秒）

  • •

    连接分片与负载均衡：Nginx按IP哈希分发长连接，确保同一用户连接固定Netty节点；Netty按用户ID分片维护连接，避免单节点连接过载，支持动态扩容。

  • •

    心跳机制：Netty开启IdleStateHandler心跳检测，客户端每60秒发送心跳包，服务端300秒无读写则关闭连接，释放资源；Nginx超时时间与Netty保持一致，避免误关连接。

  • •

    内存优化：Netty调整接收/发送缓冲区大小，避免内存溢出；采用池化技术（ByteBuf池），减少内存分配与回收开销，提升并发处理效率。

  1. 百万级长连接文本流程（全链路）

  2. 连接接入：客户端（APP/浏览器/设备）发起WebSocket/TCP长连接请求，经CDN动态转发、LVS负载分发，到达长连接Nginx集群。

  3. SSL卸载与分发：Nginx对请求进行SSL卸载（解密加密流量），按IP哈希策略将长连接转发至对应Netty节点，同时与Netty维持长连接复用池，减少建联开销。

  4. 长连接建立：Netty节点接收连接请求，完成协议握手（WebSocket HTTP握手/TCP三次握手），将连接存入本地连接管理容器，同时把“用户ID→Netty节点”映射关系写入Redis Cluster。

  5. 会话维护：客户端与Netty节点维持长连接，每60秒发送心跳包，Netty通过IdleStateHandler检测心跳，正常则保持连接，异常则关闭连接并更新Redis映射。

  6. 消息处理：客户端发送消息至Netty节点，Netty解码后处理业务逻辑（如即时通讯消息转发、直播弹幕推送），如需跨节点通信，通过Redis Pub/Sub分发消息，目标Netty节点接收后推送给对应客户端。

  7. 弹性扩容与容灾：当Netty节点连接数达阈值（如7万/节点），K8s自动扩容新节点，Nginx检测到新节点后纳入集群分发流量；若某Netty节点故障，Nginx自动剔除故障节点，Redis删除对应会话映射，客户端重连后分配至健康节点。

  8. 连接关闭：客户端主动断开连接，或Netty检测到心跳超时/异常，关闭连接，清理本地连接容器，更新Redis会话映射，释放资源。

第三层：Java微服务层（核心业务逻辑处理）

基于Spring Cloud/Spring Boot搭建微服务集群，采用K8s容器化部署，支持弹性扩容，适配百亿级流量下的业务处理需求，搭建与实例如下：

基于Spring Cloud/Spring Boot搭建微服务集群，采用K8s容器化部署，支持弹性扩容，适配百亿级流量下的业务处理需求，搭建与实例如下：

  1. 微服务架构设计（按业务域拆分）

  • •

    核心业务域拆分：用户服务（用户登录、信息管理）、商品服务（商品查询、库存管理）、订单服务（订单创建、支付回调）、内容服务（资讯/视频分发），每个服务独立部署、独立扩容，避免业务耦合。

  • •

    基础组件选型：

    • •

      注册中心：Nacos（高可用，支持百万级服务注册）；

    • •

      配置中心：Nacos（动态配置，无需重启服务更新配置）；

    • •

      网关：Spring Cloud Gateway（替代Zuul，高性能，支持路由、限流、熔断）；

    • •

      熔断降级：Sentinel（适配Java微服务，支持秒级熔断，保护核心服务）；

    • •

      部署方式：K8s容器化，单服务Pod数支持从百级扩展至千级，按CPU使用率、QPS自动弹性扩容。

  1. Java微服务实例（用户服务，核心接口）

（1）服务依赖配置（pom.xml核心依赖）

<dependencies>
<!-- Spring Boot核心依赖 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!-- Nacos注册中心依赖 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<!-- Sentinel熔断降级依赖 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
<!-- Redis缓存依赖 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
</dependencies>

（2）服务配置（application.yml）

server:
port: 8080
spring:
application:
name: user-service # 服务名称，用于注册发现
cloud:
nacos:
discovery:
server-addr: 10.0.1.10:8848,10.0.1.11:8848 # Nacos集群地址
sentinel:
transport:
dashboard: 10.0.1.12:8088 # Sentinel控制台地址
redis:
cluster:
nodes: 10.0.2.10:6379,10.0.2.11:6379 # Redis集群地址
lettuce:
pool:
max-active: 200 # 连接池最大连接数
max-idle: 50 # 最大空闲连接数

自定义配置

user:
cache:
ttl: 3600 # 用户信息缓存时间（秒）

（3）核心接口实现（用户信息查询，高并发优化）

@RestController
@RequestMapping(“/api/user”)
@Slf4j
public class UserController {

@Autowired
private UserService userService;

@Autowired
private StringRedisTemplate redisTemplate;

// 用户信息查询接口，添加Sentinel熔断降级、缓存优化
@GetMapping("/info/{userId}")
@SentinelResource(value = "getUserInfo", 
                 fallback = "getUserInfoFallback",
                 blockHandler = "getUserInfoBlockHandler")
public ResultVO<UserVO> getUserInfo(@PathVariable Long userId) {
    // 1. 先查Redis缓存，命中直接返回
    String cacheKey = "user:info:" + userId;
    String userCache = redisTemplate.opsForValue().get(cacheKey);
    if (StrUtil.isNotBlank(userCache)) {
        UserVO userVO = JSONUtil.toBean(userCache, UserVO.class);
        return ResultVO.success(userVO);
    }
    // 2. 缓存未命中，查询数据库（服务层已做分库分表）
    UserVO userVO = userService.getUserInfoById(userId);
    // 3. 写入Redis缓存，设置过期时间
    redisTemplate.opsForValue().set(cacheKey, JSONUtil.toJsonStr(userVO), 
                                  userCacheTtl, TimeUnit.SECONDS);
    return ResultVO.success(userVO);
}

// 熔断降级兜底方法（服务异常时调用）
public ResultVO<UserVO> getUserInfoFallback(Long userId, Throwable e) {
    log.error("查询用户信息熔断降级，userId:{}", userId, e);
    // 返回默认数据或缓存中的旧数据
    return ResultVO.success(new UserVO(userId, "默认用户名", "未知"));
}

// 限流兜底方法（流量超出阈值时调用）
public ResultVO<UserVO> getUserInfoBlockHandler(Long userId, BlockException e) {
    log.error("查询用户信息被限流，userId:{}", userId, e);
    return ResultVO.fail(429, "请求过于频繁，请稍后重试");
}

}

  1. 微服务高可用优化

  • •

    缓存优化：核心接口添加Redis多级缓存（CDN边缘缓存→Redis集群→本地缓存），缓存命中率≥99%，减少数据库压力。

  • •

    熔断降级：通过Sentinel对每个接口设置阈值（QPS、响应时间、错误率），异常时触发降级，返回兜底数据，避免服务雪崩。

  • •

    弹性扩容：基于K8s HPA配置，当CPU使用率≥70%或QPS≥10万时，自动扩容Pod数量；负载降低后自动缩容，节约资源。

  • •

    数据库适配：采用MySQL分库分表（Sharding-JDBC），按用户ID哈希分片，读写分离，主库写、从库读，支撑百亿级数据存储与访问。

第四层：数据层（高并发数据支撑）

数据层是微服务的核心支撑，需适配百亿级流量下的高并发读写，搭建要点如下：

  • •

    Redis集群：采用Redis Cluster（16384个哈希槽），主从复制+哨兵模式，跨可用区部署，单集群节点数≥30台，支撑每秒千万级读写，缓存核心业务数据（用户信息、商品库存、订单状态）。

  • •

    MySQL集群：分库分表部署（按业务域分库，按用户ID/订单ID分表），每个分库主从架构（1主2从），开启MGR集群，支撑每秒百万级读写，存储核心业务数据。

  • •

    ES集群：用于日志存储、全文检索（如商品搜索、资讯检索），单集群节点数≥50台，分片+副本配置，支撑每秒千万级检索请求。

三、百亿级流量架构关键注意事项

  1. 避免大Key与慢请求：CDN、Nginx、Redis均禁止存储大Key（单Key≤10KB），Java微服务接口响应时间≤200ms，慢请求会导致全链路阻塞。

  2. 全链路容灾：CDN主备双厂商（主8备2），Nginx与微服务跨可用区部署，数据层多副本存储，单节点/单地域故障时，流量自动漂移，无感知切换。

  3. 监控告警：搭建Prometheus+Grafana+SkyWalking全链路监控，监控CDN命中率、Nginx并发、微服务QPS/响应时间、数据层负载，指标异常时短信/钉钉三重告警。

  4. 成本控制：CDN开启防盗链（Referer白名单+URL鉴权），避免流量被盗刷；Nginx与微服务按需扩容，避免资源浪费；静态资源压缩与转码，降低带宽成本。

  5. 突发流量应对：提前预热热点资源至CDN，Nginx与微服务开启弹性带宽/弹性扩容，Java微服务非核心接口提前做好降级预案，应对秒杀/热点事件峰值。

四、架构总结

百亿级流量架构的核心的是“分层卸压、协同配合”：CDN扛住静态流量，Nginx扛住动态转发压力，Java微服务聚焦核心业务，数据层提供高可用存储。搭建时需优先保障“稳定与容灾”，再优化性能与成本，同时通过容器化、弹性扩容，让架构具备从百亿级平滑扩展至千亿级的能力。

对于Java微服务而言，核心是“业务拆分、缓存优化、熔断降级”，避免单服务故障扩散，同时通过高并发编程技巧（连接池复用、异步处理），提升单服务的处理能力，适配Nginx转发的海量请求。

原文链接： https://1024bat.cn/article/68

来源： 淘书1024bat

# java # 架构 # nginx # 微服务 # 开发语言
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

一个 API 入口调用多个大模型：AiiOnly客户端 + CC Switch 打通 Codex AI编程流程

avatar AI编程社区

压缩完上下文后，Agent 怎么还记得你的开发习惯

本文介绍了Claude代码项目中Memory机制的实现，用于跨任务保存关键信息。Memory分为用户偏好、反馈意见、项目背景和参考线索四类，存储在.memory/目录下的独立Markdown文件中，并通过MEMORY.md目录索引。Agent通过轻量模型调用选择相关记忆加载，每次最多读取5条。记忆提取发生在消息压缩前，以保留原始完整信息。当记忆文件达到10条时会触发合并整理，但存在信息失真的风险。

avatar AI编程社区
cover

VSCode Claude Code + MiMo 中转免登录完整配置教程（解决原生登录弹窗 + 模型报错）

avatar AI编程社区