1. WebFlux
- 定义：Spring 5引入的响应式Web框架，基于Reactor库实现非阻塞、异步编程模型。通常用途：构建实时通信、流数据处理等高并发场景。使用异步事件驱动模型，单线程可处理数千并发连接
- 用途：处理高并发网络请求（如2000+ QPS），提升数据库服务器的吞吐量，适用于IO密集型操作。
@RestControllerpublic class UserController {@GetMapping("/users")public Flux<User> getUsers() {return userRepository.findAll(); // 返回响应式数据流}}
2. 响应式架构
- 定义：基于事件驱动和非阻塞IO的架构，资源利用率高，适合高并发场景。通常用途：微服务网关、实时数据处理系统。
- 项目用途：支撑数据库服务器的网络通信模块，确保高QPS下仍能快速响应请求。
QPS（每秒查询数）测量方法：使用JMeter、Gatling等压力测试工具模拟并发请求。通过WebTestClient发送批量请求，监控响应时间和成功率。合理范围：取决于硬件和业务复杂度，2000+ QPS属于高性能水平，需结合缓存、非阻塞IO等优化实现。
4. 三级缓存体系（Caffeine + OffHeap + Redis）
- 堆内缓存（Caffeine） ：基于Java堆的高性能本地缓存，适合频繁访问的热点数据。通常用途：电商秒杀、实时排行榜等高频读场景。
- 堆外缓存（OffHeap） ：使用Direct Memory存储数据，减少GC压力，适合大对象。
- Redis集群：分布式缓存，保证数据一致性和高可用性。
层级 技术 存储内容 访问时间
L1 Caffeine 热点数据（如最近查询结果） 纳秒级
L2 Off-Heap 大对象（如全表数据） 微秒级
L3 Redis集群 持久化缓存（如元数据） 毫秒级
热点查询定义：短时间内被大量重复访问的数据查询请求。通常用途：社交平台热门帖子、实时监控数据。
6. 无锁跳表索引（ConcurrentSkipListMap）
- 定义：基于跳表（Skip List）实现的并发有序数据结构，无锁设计减少线程竞争。
- 项目用途：替代传统B+树索引，提升高并发下的范围查询效率。
- 通常用途：实时排行榜、时间序列数据库。
- 代码示例：
ConcurrentNavigableMap<Integer, String> map = new ConcurrentSkipListMap<>();map.put(1, "Data1"); // 线程安全写入
7. 范围查询
- 定义：查询某一区间内的数据（如时间范围、ID区间）。
- 项目用途：利用跳表索引快速定位数据，提升查询性能。
- 通常用途：日志分析、订单历史查询。
8. HikariCP连接池
高性能数据库连接池，提供快速的连接获取和释放。任何需要高效数据库访问的Java应用。项目用途：管理数据库连接，减少连接建立开销，提升写入吞吐量。
优化对比：
指标 原生JDBC HikariCP
连接创建时间 150ms/次 2ms/次
最大并发连接数 100 1000+
配置示例：
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost/db");
config.setMaximumPoolSize(20); // 关键参数
HikariDataSource ds = new HikariDataSource(config);
写入吞吐量：衡量系统每秒处理写入操作的能力。
- 测量方法：通过基准测试工具（如SysBench）模拟批量写入，监控TPS（每秒事务数）。 项目测试：结合HikariCP连接池优化和无锁结构，压测批量插入操作。合理范围：依赖磁盘IO和网络带宽，SSD环境下通常可达数千TPS，需通过连接池和批量提交优化。
内存锁
内存锁（如mlock()）用于将进程的虚拟内存页面锁定在物理内存（RAM）中，防止其被交换到磁盘。例如，实时应用或涉及敏感数据（如密码、密钥）的场景需要内存锁，确保数据访问的低延迟和安全性。
- 锁定内容： 以页面（通常4KB）为粒度锁定，无法单独锁定同一页面内的不同数据结构。多个进程共享同一物理页面时，只要任一进程持有锁，页面将保持驻留。
- 与互斥锁的区别： 内存锁针对物理内存管理，而互斥锁（如
pthread_mutex）用于协调多线程/进程对共享资源的访问。
连接池
连接池通过预创建并复用资源（如数据库连接、网络连接）来提升性能。其核心是通过互斥锁（如数组lock[N]）管理连接资源的分配。
- 锁定内容： 每个连接对应一个锁，线程需获取锁才能使用连接，防止多个线程同时操作同一连接导致数据混乱。
- 连接对象： 管理的是外部资源（如数据库服务），通过复用已建立的连接减少频繁创建/销毁的开销。
进程与应用程序/客户端的关系
-
进程不等同于应用程序或客户端： 一个应用程序可由多个进程组成（如Nginx多进程架构），而一个进程也可服务于多个客户端（如多线程服务器）。 客户端通常对应一个网络会话，可能由单个进程处理（如单线程服务器）或多个进程/线程协作处理（如负载均衡）。
-
微服务服务器中的端口处理机制
-
端口绑定与监听：每个进程通过
bind()系统调用绑定到特定端口，同一协议下端口同一时间仅能被一个进程占用。例如，Web服务器监听80端口。- 多进程共享端口： 如Nginx多进程通过自旋锁或文件锁避免“惊群效应”，仅一个进程实际调用
accept()处理新连接。
- 多进程共享端口： 如Nginx多进程通过自旋锁或文件锁避免“惊群效应”，仅一个进程实际调用
-
微服务的负载均衡：客户端（如Feign）通过轮询、随机等策略将请求分发到不同端口的服务实例，实现水平扩展。 反向代理（如Nginx）监听统一端口，内部转发请求至多个后端微服务端口，对外隐藏复杂度。
总结
- 内存锁锁定物理内存页，防止交换；连接池锁定池内资源，确保线程安全。 进程是资源分配单位，一个应用可包含多进程，客户端连接可能由多进程协作处理。 微服务端口通过绑定、锁机制及负载均衡策略高效处理客户端请求，支持高并发与可扩展性。
- 项目中通过 响应式架构（WebFlux） 和三级缓存支撑高QPS，利用无锁跳表索引和HikariCP提升查询与写入效率，StampedLock优化读多写少场景的并发控制。指标（QPS、吞吐量）需通过压力测试和监控工具验证，合理范围取决于硬件与代码优化程度。
GraphQL与RESTful API/SQL的关系及使用区别
SQL：用于直接操作数据库的查询语言，关注数据存储与检索 。 RESTful API：基于HTTP协议的接口风格，通过多端点（如/users、/posts）操作资源，数据格式固定 。GraphQL：一种API查询语言，客户端通过单一端点（如/graphql）自定义查询字段，实现按需获取数据 。GraphQL可替代或补充REST API，但需通过后端服务（如Spring Boot）与数据库（如SQL）交互 。 
- 查询示例对比：
场景：获取用户信息及其关联的帖子。- RESTful API：需发送两次请求（
GET /users/1和GET /posts?userId=1），返回固定字段 。 - GraphQL：单次请求返回仅包含所需字段的JSON 。，客户端指定字段（如仅需用户姓名和帖子标题）：
- RESTful API：需发送两次请求（
query { user(id: 1) { name } posts(userId: 1) { title } }
- 代码与部署区别：
- REST：需定义多个控制器（如
UserController、PostController），每个接口独立实现；客户端需处理多请求逻辑。 GraphQL：定义统一的Schema（类型系统），通过解析器（Resolver）实现字段逻辑；客户端自由组合查询 。 - 部署：REST需管理多个端点版本（如
/v1/users），GraphQL通过Schema演进避免版本号 。 - 框架兼容性： GraphQL不限于Spring Boot，支持Node.js（Apollo Server）、Python（Graphene）、Go（gqlgen）等 。
- GraphQL与RESTful的核心差异
- 核心区别：
- 数据控制权： REST由服务端决定返回数据，客户端无法过滤冗余字段 。GraphQL由客户端声明需求，减少网络传输 。
- 请求效率： REST的N+1问题（如获取用户及其帖子需多次请求） 。 GraphQL单请求嵌套查询，减少网络开销 。
- 版本管理： REST需通过URL版本化（如
/v2/users）适应需求变化 。 GraphQL通过扩展Schema字段，保持接口兼容性 。 - 缓存机制： REST利用HTTP缓存（如ETag），GraphQL需自定义缓存策略（如Apollo Client） 。
- REST与GraphQL共存可行性
- 技术兼容性：
Spring Boot项目可同时支持REST和GraphQL，两者通过不同端点（如/api和/graphql）隔离，无冲突 。
@RestController // REST端点 public class UserController { ... } @Component // GraphQL解析器 public class UserResolver { ... }
