100万级连接，石墨文档WebSocket网关如何架构？

文章很长，且持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录博客园版 为您奉上珍贵的学习资源：

免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ，帮你实现技术自由，完成职业升级，薪酬猛涨！加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷1）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷2）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷3）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领

免费赠送资源宝库： Java 必备百度网盘资源大合集价值>10000元加尼恩领取

100万级连接，石墨文档WebSocket网关如何架构？

说在前面

在40岁老架构师尼恩的读者交流群(50+)中，很多小伙伴拿到一线互联网企业如阿里、网易、有赞、希音、百度、滴滴的面试资格。

最近，尼恩指导一个小伙伴简历，写了一个《高并发网关项目》，此项目帮这个小伙拿到 字节/阿里/微博/汽车之家 面邀，所以说，这是一个牛逼的项目。

为了帮助大家拿到更多面试机会，拿到更多大厂offer，

尼恩决定：9月份给大家出一章视频介绍这个项目的架构和实操，《33章：10Wqps 高并发 Netty网关架构与实操》，预计月底发布。然后，提供一对一的简历指导，让你简历金光闪闪、脱胎换骨。

《33章：10Wqps 高并发 Netty网关架构与实操》海报如下：

配合《33章：10Wqps 高并发 Netty网关架构与实操》，尼恩会梳理几个工业级、生产级网关案例，作为架构素材、设计的素材。

前面梳理了

除了以上的6个案例，这里，尼恩又找到一个漂亮的生产级案例：

《100万级连接，石墨文档WebSocket网关如何架构？》，

注意，这又一个非常牛逼的工业级、生产级网关案例。

这些案例，并不是尼恩的原创。这些案例，仅仅是尼恩在《33章：10Wqps 高并发 Netty网关架构与实操》备课的过程中，在互联网查找资料的时候，收集起来的，供大家学习和交流使用。

《尼恩架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到公号【技术自由圈】获取

本文目录

100万级连接，石墨文档WebSocket网关如何架构？

100万级连接，石墨文档WebSocket网关如何架构？

作者：石墨文档技术团队

在石墨文档的部分业务中，例如文档分享、评论、幻灯片演示和文档表格跟随等场景，涉及到多客户端数据实时同步和服务端批量数据在线推送的需求，一般的 HTTP 协议无法满足服务端主动 Push 数据的场景，因此选择采用 WebSocket 方案进行业务开发。

随着石墨文档业务发展，目前日连接峰值已达百万量级，日益增长的用户连接数和不符合目前量级的架构设计导致了内存和 CPU 使用量急剧增长，因此我们考虑对长连接网关进行重构。

本文分享了石墨文档长连接网关从1.0架构演进到2.0的过程，并总结了整个性能优化的实践过程。

1、v1.0架构面临的问题

这套长连接网关系统的v1.0版是使用 Node.js 基于 Socket.IO 进行修改开发的版本，很好的满足了当时用户量级下的业务场景需求。

1.1 架构介绍

1.0版架构设计图：

1.0版客户端连接流程：

1）用户通过 NGINX 连接网关，该操作被业务服务感知；
2）业务服务感知到用户连接后，会进行相关用户数据查询，再将消息 Pub 到 Redis；
3）网关服务通过 Redis Sub 收到消息；
4）查询网关集群中的用户会话数据，向客户端进行消息推送。

1.2 面临的问题

虽然 1.0 版本的长连接网关在线上运行良好，但是不能很好的支持后续业务的扩展。

并且有以下几个问题需要解决：

1）资源消耗：Nginx 仅使用 TLS 解密，请求透传，产生了大量的资源浪费，同时之前的 Node 网关性能不好，消耗大量的 CPU、内存；
2）维护与观测：未接入石墨的监控体系，无法和现有监控告警联通，维护上存在一定的困难；
3）业务耦合问题：业务服务与网关功能被集成到了同一个服务中，无法针对业务部分性能损耗进行针对性水平扩容，为了解决性能问题，以及后续的模块扩展能力，都需要进行服务解耦。

2、v2.0架构演进实践

2.1 概述

长连接网关系统的v2.0版需要解决很多问题。

比如，石墨文档内部有很多组件（文档、表格、幻灯片和表单等等），在 1.0 版本中组件对网关的业务调用可以通过Redis、Kafka 和 HTTP 接口，来源不可查，管控困难。

此外，从性能优化的角度考虑也需要对原有服务进行解耦合，将 1.0 版本网关拆分为网关功能部分和业务处理部分。

具体是：

1）网关功能部分为 WS-Gateway：集成用户鉴权、TLS 证书验证和 WebSocket 连接管理等；
2）业务处理部分为 WS-API：组件服务直接与该服务进行 gRPC 通信。

另外还有：

1）可针对具体的模块进行针对性扩容；
2）服务重构加上 Nginx 移除，整体硬件消耗显著降低；
3）服务整合到石墨监控体系。

2.2 整体架构

2.0版本架构设计图：

2.0版本客户端连接流程：

1）客户端与 WS-Gateway 服务通过握手流程建立 WebSocket 连接；
2）连接建立成功后，WS-Gateway 服务将会话进行节点存储，将连接信息映射关系缓存到 Redis 中，并通过 Kafka 向 WS-API 推送客户端上线消息；
3）WS-API 通过 Kafka 接收客户端上线消息及客户端上行消息；
4）WS-API 服务预处理及组装消息，包括从 Redis 获取消息推送的必要数据，并进行完成消息推送的过滤逻辑，然后 Pub 消息到 Kafka；
5）WS-Gateway 通过 Sub Kafka 来获取服务端需要返回的消息，逐个推送消息至客户端。

2.3 握手流程

网络状态良好的情况下，完成如下图所示步骤 1 到步骤 6 之后，直接进入 WebSocket 流程；

网络环境较差的情况下，WebSocket 的通信模式会退化成 HTTP 方式，客户端通过 POST 方式推送消息到服务端，再通过 GET 长轮询的方式从读取服务端返回数据。

客户端初次请求服务端连接建立的握手流程：

流程说明如下：

1）Client 发送 GET 请求尝试建立连接；
2）Server 返回相关连接数据，sid 为本次连接产生的唯一 Socket ID，后续交互作为凭证：
{"sid":"xxx","upgrades":["websocket"],"pingInterval":xxx,"pingTimeout":xxx}
3）Client 携带步骤 2 中的 sid 参数再次请求；
4）Server 返回 40，表示请求接收成功；
5）Client 发送 POST 请求确认后期降级通路情况；
6）Server 返回 ok，此时第一阶段握手流程完成；
7）尝试发起 WebSocket 连接，首先进行 2probe 和 3probe 的请求响应，确认通信通道畅通后，即可进行正常的 WebSocket 通信。

2.4 TLS 内存消耗优化

客户端与服务端连接建立采用的 wss 协议，在 1.0 版本中 TLS 证书挂载在 Nginx 上，HTTPS 握手过程由 Nginx 完成。为了降低 Nginx 的机器成本，在 2.0 版本中我们将证书挂载到服务上。

通过分析服务内存，如下图所示，TLS 握手过程中消耗的内存占了总内存消耗的大概 30% 左右。

这个部分的内存消耗无法避免，我们有两个选择：

1）采用七层负载均衡，在七层负载上进行 TLS 证书挂载，将 TLS 握手过程移交给性能更好的工具完成；
2）优化 Go 对 TLS 握手过程性能，在与业内大佬曹春晖（曹大）的交流中了解到，他最近在 Go 官方库提交的 PR，以及相关的性能测试数据。

2.5 Socket ID 设计

对每次连接必须产生一个唯一码，如果出现重复会导致串号，消息混乱推送的问题。

这里，选择SnowFlake算法作为唯一码生成算法。

物理机场景中，对副本所在物理机进行固定编号，即可保证每个副本上的服务产生的 Socket ID 是唯一值。

K8S 场景中，这种方案不可行，于是采用注册下发的方式返回编号，WS-Gateway 所有副本启动后，向数据库写入服务的启动信息，获取副本编号，以此作为参数作为 SnowFlake 算法的副本编号进行 Socket ID 生产，服务重启会继承之前已有的副本编号，有新版本下发时会根据自增 ID 下发新的副本编号。

于此同时，Ws-Gateway 副本会向数据库写入心跳信息，以此作为网关服务本身的健康检查依据。

2.6 集群会话管理方案：事件广播

客户端完成握手流程后，会话数据在当前网关节点内存存储，部分可序列化数据存储到 Redis，

redis 会话存储结构说明如下图所示。

键	说明
ws:user:clients:$	存储用户和 WebSocket 连接的关系，采用有序集合方式存储
ws:guid:clients:$	存储文件和 WebSocket 连接的关系，采用有序结合方式存储
ws:client:$	存储当前 WebSocket连接下的全部用户和文件关系数据，采用Redis Hash 方式进行存储，对应 key 为 user和guid

由客户端触发或组件服务触发的消息推送，通过 Redis 存储的数据结构，在 WS-API 服务查询到返回消息体的目标客户端的 Socket ID，再由 WS-Gateway 服务进行集群消费。

如果 Socket ID 不在当前节点，则需要进行节点与会话关系的查询，找到客端户 Socket ID 实际对应的 WS-Gateway 节点，通常有以下两种方案（如下图所示）。

	优点	缺点
事件广播	实现简单	消息广播数量会随着节点数量上升
注册中心	会话与节点映射关系清晰	注册中心强依赖，额外运维成本

在确定使用事件广播方式进行网关节点间的消息传递后，进一步选择使用哪种具体的消息中间件，列举了三种待选的方案（如下图所示）。

特性	Redis	Kafka	RocketMQ
开发语言	C	Scala	Java
单机吞吐量	10w+	10w+	10w+
可用性	主从架构	分布式架构	分布式架构
特点	功能简单	吞吐量、可用性极高	功能丰富、定制化强，吞吐量可用性高
功能特性	数据10K 以内性能优异，功能简单，适用于简单业务场景	支持核心的 MQ 功能，不支持消息查询或消息回溯等功能	支持核心的 MQ 功能，扩展性强

于是对 Redis 和其他 MQ 中间件进行 100w 次的入队和出队操作，在测试过程中发现在数据小于 10K 时 Redis 性能表现十分优秀。

进一步结合实际情况：广播内容的数据量大小在 1K 左右，业务场景简单固定，并且要兼容历史业务逻辑，最后选择了 Redis 进行消息广播。

后续还可以将 WS-API 与 WS-Gateway 两两互联，使用 gRPC stream 双向流通信节省内网流量。

2.7 心跳机制

会话在节点内存与 Redis 中存储后，客户端需要通过心跳上报持续更新会话时间戳，客户端按照服务端下发的周期进行心跳上报，上报时间戳首先在内存进行更新，然后再通过另外的周期进行 Redis 同步，避免大量客户端同时进行心跳上报对 Redis 产生压力。

具体流程：

1）客户端建立 WebSocket 连接成功后，服务端下发心跳上报参数；
2）客户端依据以上参数进行心跳包传输，服务端收到心跳后会更新会话时间戳；
3）客户端其他上行数据都会触发对应会话时间戳更新；
4）服务端定时清理超时会话，执行主动关闭流程；
5）通过 Redis 更新的时间戳数据进行 WebSocket 连接、用户和文件之间的关系进行清理。

会话数据内存以及 Redis 缓存清理逻辑：

for {
   select {
   case <-t.C:
      var now = time.Now().Unix()
      var clients = make([]*Connection, 0)
      dispatcher.clients.Range(func(_, v interface{}) bool {
         client := v.(*Connection)
         lastTs := atomic.LoadInt64(&client.LastMessageTS)
         if now-lastTs > int64(expireTime) {
            clients = append(clients, client)
         } else {
            dispatcher.clearRedisMapping(client.Id, client.Uid, lastTs, clearTimeout)
         }
         return true
      })
      for _, cli := range clients {
         cli.WsClose()
      }
   }
}

在已有的两级缓存刷新机制上，进一步通过动态心跳上报频率的方式降低心跳上报产生的服务端性能压力，默认场景中客户端对服务端进行间隔 1s 的心跳上报，假设目前单机承载了 50w 的连接数，当前的 QPS 为：QPS1 = 500000/1。

从服务端性能优化的角度考虑，实现心跳正常情况下的动态间隔，每 x 次正常心跳上报，心跳间隔增加 a，增加上限为 y，动态 QPS 最小值为：QPS2=500000/y。

极限情况下，心跳产生的 QPS 降低 y 倍。在单次心跳超时后服务端立刻将 a 值变为 1s 进行重试。采用以上策略，在保证连接质量的同时，降低心跳对服务端产生的性能损耗。

2.8 自定义Headers

使用 Kafka 自定义 Headers 的目的是避免网关层出现对消息体解码而带来的性能损耗。

客户端 WebSocket 连接建立成功后，会进行一系列的业务操作，我们选择将 WS-Gateway 和 WS-API 之间的操作指令和必要的参数放到 Kafka 的 Headers 中，例如通过 X-XX-Operator 为广播，再读取 X-XX-Guid 文件编号，对该文件内的所有用户进行消息推送。

字段	说明	描述
X-ID	WebSocket ID	连接 ID
X-Uid	用户 ID	用户 ID
X-Guid	文件 ID	文件 ID
X-Inner	网关内部操作指令	用户加入、用户退出
X-Event	网关事件	Connect/Message/Disconnect
X-Locale	语言类型设置	语言类型设置
X-Operator	api层操作指令	单播、广播、网关内部操作
X-Auth-Type	用户鉴权类型	SDKV2、主站、微信、移动端、桌面
X-Client-Version	客户端版本	客户端版本
X-Server-Version	网关版本	服务端版本
X-Push-Client-ID	客户端 ID	客户端 ID
X-Trace-ID	链路 ID	链路 ID

在 Kafka Headers 中写入了 trace id 和时间戳，可以追中某条消息的完整消费链路以及各阶段的时间消耗。

2.9 消息接收与发送

type Packet struct {
  ...
}
 
type Connect struct {
  *websocket.Con
  send chan Packet
}
 
func NewConnect(conn net.Conn) *Connect {
  c := &Connect{
    send: make(chan Packet, N),
  }
  go c.reader()
  go c.writer()
  return c
}

客户端与服务端的消息交互第一版的写法类似以上写法。

对 Demo 进行压测，发现每个 WebSocket 连接都会占用 3 个 goroutine，每个 goroutine 都需要内存栈，单机承载连十分有限。

主要受制于大量的内存占用，而且大部分时间 c.writer() 是闲置状态，

于是考虑，是否只启用 2 个 goroutine 来完成交互。

type Packet struct {
  ...
}
 
type Connect struct {
  *websocket.Conn
  mux sync.RWMutex
}
 
func NewConnect(conn net.Conn) *Connect {
  c := &Connect{
    send: make(chan Packet, N),
  }
  go c.reader()
  return c
}
 
func (c *Connect) Write(data []byte) (err error) {
   c.mux.Lock()
   defer c.mux.Unlock()
   ...
   return nil
}

保留 c.reader() 的 goroutine，如果使用轮询方式从缓冲区读取数据，可能会产生读取延迟或者锁的问题，c.writer() 操作调整为主动调用，不采用启动 goroutine 持续监听，降低内存消耗。

调研了 gev 和 gnet 等基于事件驱动的轻量级高性能网络库，实测发现在大量连接场景下可能产生的消息延迟的问题，所以没有在生产环境下使用。

2.10 核心对象缓存

确定数据接收与发送逻辑后，网关部分的核心对象为 Connection 对象，围绕 Connection 进行了 run、read、write、close 等函数的开发。

使用 sync.pool 来缓存该对象，减轻 GC 压力，创建连接时，通过对象资源池获取 Connection 对象。

生命周期结束之后，重置 Connection 对象后 Put 回资源池。

在实际编码中，建议封装 GetConn()、PutConn() 函数，收敛数据初始化、对象重置等操作。

var ConnectionPool = sync.Pool{
   New: func() interface{} {
      return &Connection{}
   },
}
 
func GetConn() *Connection {
   cli := ConnectionPool.Get().(*Connection)
   return cli
}
 
func PutConn(cli *Connection) {
   cli.Reset()
   ConnectionPool.Put(cli) // 放回连接池
}

2.11数据传输过程优化

消息流转过程中，需要考虑消息体的传输效率优化，采用 MessagePack 对消息体进行序列化，压缩消息体大小。调整 MTU 值避免出现分包情况，定义 a 为探测包大小，通过如下指令，对目标服务 ip 进行 MTU 极限值探测。

ping -s {a} {ip}

a = 1400 时，实际传输包大小为：1428。

其中 28 由 8（ICMP 回显请求和回显应答报文格式）和 20（IP 首部）构成。

如果 a 设置过大会导致应答超时，在实际环境包大小超过该值时会出现分包的情况。

在调试合适的 MTU 值的同时通过 MessagePack 对消息体进行序列号，进一步压缩数据包的大小，并减小 CPU 的消耗。

2.12 基础设施支持

使用EGO框架进行服务开发：业务日志打印，异步日志输出，动态日志级别调整等功能，方便线上问题排查提升日志打印效率；微服务监控体系，CPU、P99、内存、goroutine 等监控。

客户端 Redis 监控：

客户端 Kafka 监控：

自定义监控大盘：

3、检查成果的时刻：性能压测

3.1 压测准备

准备的测试平台有：

1）选择一台配置为 4 核 8G 的虚拟机，作为服务机，目标承载 48w 连接;
2）选择八台配置为 4 核 8G 的虚拟机，作为客户机，每台客户机开放 6w 个端口。

3.2 模拟场景一

用户上线，50w 在线用户。

服务	CPU	Memory	数量	CPU%	Mem%
WS-Gateway	16核	32G	1台	22.38%	70.59%

单个 WS-Gateway 每秒建立连接数峰值为：1.6w 个/s，每个用户占用内存：47K。

3.3 模拟场景二

测试时间 15 分钟，在线用户 50w，每 5s 推送一条所有用户，用户有回执。

推送内容为：

42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"xx@xx.xx","avatar":"ZgG5kEjCkT6mZla6.png","created_at":1623811084000,"name_pinyin":"","team_id":13,"team_role":"member","merged_into":0,"team_time":1623811084000,"mobile":"+xxxx","mobile_account":"","status":1,"has_password":true,"team":null,"membership":null,"is_seat":true,"team_role_enum":3,"register_time":1623811084000,"alias":"","type":"anoymous"}],"userCount":1,"from":"ws"}}]

测试经过 5 分钟后，服务异常重启，重启原因是内存使用量到超过限制。

分析内存超过限制的原因：

新增的广播代码用掉了 9.32% 的内存：

接收用户回执消息的部分消耗了 10.38% 的内存：

进行测试规则调整，测试时间 15 分钟，在线用户 48w，每 5s 推送一条所有用户，用户有回执。

推送内容为：

42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"xx@xx.xx","avatar":"ZgG5kEjCkT6mZla6.png","created_at":1623811084000,"name_pinyin":"","team_id":13,"team_role":"member","merged_into":0,"team_time":1623811084000,"mobile":"+xxxx","mobile_account":"","status":1,"has_password":true,"team":null,"membership":null,"is_seat":true,"team_role_enum":3,"register_time":1623811084000,"alias":"","type":"anoymous"}],"userCount":1,"from":"ws"}}]

服务	CPU	Memory	数量	CPU%	Mem%
WS-Gateway	16核	32G	1台	44%	91.75%

连接数建立峰值：1w 个/s，接收数据峰值：9.6w 条/s，发送数据峰值 9.6w 条/s。

3.4 模拟场景三

测试时间 15 分钟，在线用户 50w，每 5s 推送一条所有用户，用户无需回执。

推送内容为：

42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"xx@xx.xx","avatar":"ZgG5kEjCkT6mZla6.png","created_at":1623811084000,"name_pinyin":"","team_id":13,"team_role":"member","merged_into":0,"team_time":1623811084000,"mobile":"+xxxx","mobile_account":"","status":1,"has_password":true,"team":null,"membership":null,"is_seat":true,"team_role_enum":3,"register_time":1623811084000,"alias":"","type":"anoymous"}],"userCount":1,"from":"ws"}}]

服务	CPU	Memory	数量	CPU%	Mem%
WS-Gateway	16核	32G	1台	30%	93%

连接数建立峰值：1.1w 个/s，发送数据峰值 10w 条/s，出内存占用过高之外，其他没有异常情况。

内存消耗极高，分析火焰图，大部分消耗在定时 5s 进行广播的操作上。

3.5 模拟场景四

测试时间 15 分钟，在线用户 50w，每 5s 推送一条所有用户，用户有回执。每秒 4w 用户上下线。

推送内容为：

42["message",{"type":"xx","data":{"type":"xx","clients":[{"id":xx,"name":"xx","email":"xx@xx.xx","avatar":"ZgG5kEjCkT6mZla6.png","created_at":1623811084000,"name_pinyin":"","team_id":13,"team_role":"member","merged_into":0,"team_time":1623811084000,"mobile":"+xxxx","mobile_account":"","status":1,"has_password":true,"team":null,"membership":null,"is_seat":true,"team_role_enum":3,"register_time":1623811084000,"alias":"","type":"anoymous"}],"userCount":1,"from":"ws"}}]

服务	CPU	Memory	数量	CPU%	Mem%
WS-Gateway	16核	32G	1台	46.96%	65.6%

连接数建立峰值：18570 个/s，接收数据峰值：329949 条/s，发送数据峰值：393542 条/s，未出现异常情况。

3.6 压测总结

在16核32G内存的硬件条件下：单机 50w 连接数，进行以上包括用户上下线、消息回执等四个场景的压测，内存和 CPU 消耗都符合预期，并且在较长时间的压测下，服务也很稳定。

测试的结果基本上是能满足目前量级下的资源节约要求的，我们认为完全可以在此基础上继续完善功能开发。

4、总结

面临日益增加的用户量，网关服务的重构是势在必行。

本次重构主要是：

1）对网关服务与业务服务的解耦，移除对 Nginx 的依赖，让整体架构更加清晰；
2）从用户建立连接到底层业务推送消息的整体流程分析，对其中这些流程进行了具体的优化。

2.0 版本的长连接网关有了更少的资源消耗，更低的单位用户内存损耗、更加完善的监控报警体系，让网关服务本身更加可靠。

以上优化内容主要是以下各个方面：

1）可降级的握手流程；
2）Socket ID 生产；
3）客户端心跳处理过程的优化；
4）自定义 Headers 避免了消息解码，强化了链路追踪与监控；
5）消息的接收与发送代码结构设计上的优化；
6）对象资源池的使用，使用缓存降低 GC 频率；
7）消息体的序列化压缩；
8）接入服务观测基础设施，保证服务稳定性。

在保证网关服务性能过关的同时，更进一步的是收敛底层组件服务对网关业务调用的方式，从以前的 HTTP、Redis、Kafka 等方式，统一为 gRPC 调用，保证了来源可查可控，为后续业务接入打下了更好的基础。

说在最后：有问题可以找老架构取经

架构之路，充满了坎坷

架构和高级开发不一样，架构问题是open/开放式的，架构问题是没有标准答案的

正由于这样，很多小伙伴，尽管耗费很多精力，耗费很多金钱，但是，遗憾的是，一生都没有完成架构升级。

所以，在架构升级/转型过程中，确实找不到有效的方案，可以来找40岁老架构尼恩求助.

前段时间一个小伙伴，他是跨专业来做Java，现在面临转架构的难题，但是经过尼恩几轮指导，顺利拿到了Java架构师+大数据架构师offer 。所以，如果遇到职业不顺，找老架构师帮忙一下，就顺利多了。

技术自由的实现路径：

实现你的架构自由：

《吃透8图1模板，人人可以做架构》

《10Wqps评论中台，如何架构？B站是这么做的！！！》

《阿里二面：千万级、亿级数据，如何性能优化？教科书级答案来了》

《峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？》

《100亿级订单怎么调度，来一个大厂的极品方案》

《2个大厂 100亿级超大流量红包架构方案》

… 更多架构文章，正在添加中

实现你的响应式自由：

《响应式圣经：10W字，实现Spring响应式编程自由》

这是老版本《Flux、Mono、Reactor 实战（史上最全）》

实现你的 spring cloud 自由：

《Spring cloud Alibaba 学习圣经》 PDF

《分库分表 Sharding-JDBC 底层原理、核心实战（史上最全）》

《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系（史上最全）》

实现你的 linux 自由：

《Linux命令大全：2W多字，一次实现Linux自由》

实现你的网络自由：

《TCP协议详解 (史上最全)》

《网络三张表：ARP表, MAC表, 路由表，实现你的网络自由！！》

实现你的分布式锁自由：

《Redis分布式锁（图解 - 秒懂 - 史上最全）》

《Zookeeper 分布式锁 - 图解 - 秒懂》

实现你的王者组件自由：

《队列之王： Disruptor 原理、架构、源码一文穿透》

《缓存之王：Caffeine 源码、架构、原理（史上最全，10W字超级长文）》

《缓存之王：Caffeine 的使用（史上最全）》

《Java Agent 探针、字节码增强 ByteBuddy（史上最全）》

实现你的面试题自由：

4800页《尼恩Java面试宝典》 40个专题

免费获取11个技术圣经PDF：

posted @ 2023-09-24 18:53 疯狂创客圈阅读(404) 评论(0) 编辑收藏举报

刷新页面返回顶部