技术之路

OpenResty 的本质：不只是 Nginx + LuaOpenResty ≠ Nginx + Lua 解释器，而是对 Nginx 核心的 全异步化、协程化改造 与 LuaJIT 深度绑定 的平台。 核心组成：Nginx C 内核 + LuaJIT（即时编译的 Lua 虚拟机） + 大量精良的 lua-resty-* 库。它把 Nginx 请求处理的 11 个阶段（如 rewrite、access、content、log）全部通过 *_by_lua 指令暴露给 Lua 脚本。 编程模型：在 Lua 中写 同步非阻塞 代码。底层借助 Nginx 的事件驱动和 Lua 协程，网络 I/O、Sleep 等操作会自动挂起当前协程，让出 CPU 给其他请求，等到事件就绪再恢复。你写的是直观的顺序逻辑，跑的是高并发异步。 与 Java 的类比：如果 Netty 是一个可以让你用 Java 构建非阻塞网络应用的框架，那 OpenResty 就是把这种能力直接集成进了 反向代理服务器，并用更为轻量的 Lua 来编排流量。Java 线程通常占用 1 MB 内存，而一个 Lua 协程仅...

Nginx 是什么一句话定义： Nginx 是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 它的核心特点是事件驱动、异步非阻塞的架构。这和 Java 中传统的 Servlet 容器（如 Tomcat）每个请求对应一个线程的模型截然不同。Nginx 用极少的 worker 进程（通常等于 CPU 核心数），通过 epoll 等高效的 I/O 多路复用机制，轻松处理数万乃至百万级的并发连接，同时保持极低的 CPU 和内存消耗。 在分布式系统中，它就是南北向流量的总入口，是所有外部请求抵达你后台服务集群前必须经过的那扇大门。 着重介绍：Nginx 可以做什么作为流量入口，Nginx 的能力远远超出把请求转发到后台这个范畴，它是一个功能强大的流量治理平台。 反向代理与负载均衡 透明转发：客户端不知道后端真实服务器，Nginx 统一收口。 负载均衡算法：支持轮询（Round Robin）、权重轮询、IP 哈希（ip_hash）、最少连接数（least_conn）、URL 哈希（hash $request_u...

这套方案对标 Spring Cloud Alibaba + Kubernetes 生态，组件全部是新版（2024~2026 年主流）且生产验证过的。 流量入口与网关 组件 选型 作用 反向代理 / 负载均衡 Nginx / OpenResty 第一层接入，SSL 终结，流量分发 API 网关 Spring Cloud Gateway (Java 体系首选，响应式) 动态路由、身份认证、限流、跨域、日志 备用网关 APISIX / Kong 性能极高，适合非 Java 中心化网关 微服务核心框架 组件 选型 作用 注册中心 Nacos 2.x 服务发现、健康检查、元数据管理 配置中心 Nacos 或 Apollo 配置热更新、灰度推送、审计 RPC 框架 Dubbo 3 (Triple/gRPC 协议) 高性能 Java RPC，跨语言支持 HTTP 调用 OpenFeign + Spring Cloud LoadBalancer 声明式 HTTP 客户端，微服务间调用更轻量 应用基座 Sp...

服务熔断、服务限流和服务降级是构建高可用、高弹性系统的三大基石，它们的目标一致（保证系统核心功能可用），但着眼点和实现方式不同。 核心概念对比 特性 服务熔断 (Circuit Breaker) 服务限流 (Rate Limiting / Throttling) 服务降级 (Service Degradation) 核心目标 快速失败，防止连锁故障。故障隔离。 控制流量，防止系统被突发流量冲垮。过载保护。 弃车保帅，牺牲非核心功能，保证核心功能可用。体验保全。 触发条件 依赖的下游服务失败率/超时率达到阈值。 流量/并发数达到预设的阈值（如QPS、线程数）。 1. 系统资源普遍不足（如CPU、线程池满）。2. 熔断或限流发生后。 作用对象 主要是对下游依赖服务的调用进行控制。 主要是对进入本服务的请求流量进行控制。 主要是对本服务提供的功能进行调整。 实现层面 通常集成在服务调用框架中（如Feign、Dubbo）。 通常位于网关/入口层或服务内部（如Sentinel、Hystrix）。 业务逻辑层，需要根据业务预先设...

核心目标与原则在开始之前，我们必须明确高并发系统的核心目标： 高性能：低延迟、高吞吐量。 高可用性：系统能够持续提供服务，即使部分组件失败（SLA 可达 99.99%）。 可扩展性：能够通过增加资源来平滑地应对流量增长。 可维护性：系统易于理解、修改和运维。 遵循的原则包括：解耦、冗余、异步、分区、自动化。 系统设计系统设计关注宏观架构，如何将各个部件组合成一个有机整体。 整体架构：水平扩展与分层摒弃传统的单体垂直扩展（Scale-up），采用分布式的水平扩展（Scale-out）架构。典型的现代高并发架构如下所示： 123用户 -> [CDN] -> [负载均衡器] -> [API 网关] -> [微服务集群] -> [数据层] | | | | | [静态资源] [流量分发] [鉴权/限流] [服务发现] [缓存/DB/消息队列] 各层核心设计要点： 客户端与 CDN： CDN：将静态资源（图片、CSS...

分布式系统处理高并发并非依靠单一的银弹，而是通过一套组合拳，从架构设计、技术选型到运维监控等多个层面进行系统性解决。其核心思想可以概括为：分而治之 和 冗余备份。 核心指导思想：可扩展性（Scalability）这是处理高并发的基石。可扩展性主要分为两种： 垂直扩展（Scale Up）：提升单个服务器的性能（更强的CPU、更大的内存、更快的磁盘）。这种方法简单，但会遇到物理极限和成本急剧上升的问题，且存在单点故障风险。这不是分布式系统的核心思路。 水平扩展（Scale Out）：通过增加更多的服务器来分担负载。这是分布式系统处理高并发的根本方法。它的优点是理论上可以无限扩展，成本相对线性，且通过冗余提高了系统的可用性。 关键技术与架构模式以下是分布式系统为实现水平扩展、应对高并发所采用的具体技术和模式。 负载均衡这是水平扩展的入口和关键。所有外部请求首先到达负载均衡器。 作用：将涌入的海量请求，按照预设的规则（如轮询、最小连接数、IP哈希等）分发到后端的多个服务器上。 实现：可以是硬件设备（如F5），也可以是软件（如Nginx, LVS, HAProxy），或者云服务（...

什么是分布式幂等核心定义： 在分布式系统中，一个接口或操作被多次执行所产生的影响，与仅执行一次所产生的影响是完全相同的。 简单来说： 无论客户端因为何种原因（如网络超时、服务抖动等）发起了多次重复的请求，服务器端都只处理一次真实的业务逻辑，并返回相同的结果。 为什么需要幂等在分布式环境下，网络是不可靠的。一个常见的场景是：客户端调用一个服务接口后，没有及时收到响应（可能是网络延迟、请求已经到达服务器但处理耗时较长导致客户端超时等），客户端会尝试重试。如果这个接口不是幂等的，那么这次重试就可能导致数据被错误地重复处理（例如：重复扣款、重复创建订单、重复发放优惠券等）。 一个生动的例子：支付 非幂等操作： 订单支付 接口。如果客户端连续调用两次 pay(订单ID)，并且没有幂等控制，那么用户可能会被扣款两次。 幂等操作： 查询订单状态 接口。无论你调用多少次 getOrderStatus(订单ID)，它都不会改变订单的状态，只会返回相同的结果。这个操作天生就是幂等的。 幂等的关键点： 副作用： 幂等关注的是多次执行的副作用是否一致，而不仅仅是返回值。即使第二次请求返回操作已执行...

什么是分布式锁分布式锁是在分布式系统环境下，用于控制多个节点上的进程或服务对共享资源进行互斥访问的一种同步机制。 为什么需要它在单机单进程时代，我们可以用编程语言自带的锁（如 Java 的 synchronized 或 ReentrantLock）来保证线程安全。但在分布式系统中，应用被部署在多台机器上，这些本地锁只对当前 JVM 进程有效，无法跨网络影响到其他机器上的服务。 典型场景： 避免重复处理：比如一个定时任务被部署了多个实例，在某一时刻只能有一个实例执行。 防止超卖：秒杀场景中，多个用户的请求被分发到不同的服务器节点，需要保证库存扣减的原子性。 保证数据一致性：对同一个共享数据进行读写操作时，需要防止并发导致的数据错乱。 分布式锁的核心特性一个合格的分布式锁必须具备以下特性： 互斥性：这是最基本的要求。在任意时刻，只有一个客户端能持有锁。 安全性：锁只能由持有它的客户端释放，不能被其他客户端释放（包括意外释放）。 避免死锁：即使获取锁的客户端崩溃或者发生网络分区，锁最终也一定能被释放，从而保证其他客户端后续可以获取锁。这通常通过给锁设置一个过期时间（租约）来实现...

什么是分布式事务核心定义：分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点之上。简单来说，一个业务操作需要调用多个服务，这些服务使用不同的数据库，要保证这些服务的数据操作要么全部成功，要么全部失败。 为什么它很复杂在单体应用中，我们可以依赖数据库的 ACID 事务（原子性、一致性、隔离性、持久性）来保证数据一致性。但在分布式系统中，数据分散在不同的服务、不同的数据库中，传统的单数据库事务无法跨库、跨服务生效。 理论基础：CAP 和 BASE要理解分布式事务的解决方案，必须先了解两个理论： CAP 定理：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 一致性 (C)：所有节点在同一时间看到的数据是一样的。 可用性 (A)：每个请求都能得到响应（不保证是最新数据）。 分区容错性 (P)：系统在遇到网络分区（节点之间无法通信）时仍然能继续工作。 由于网络分区无法避免，分布式系统必须选择 P。因此，实际是在 CP ...

什么是分布式ID分布式ID（Distributed ID）是指在分布式系统环境下，由多个服务节点协同或者独立生成的、能够确保全局唯一性的数据标识符。 为什么需要它？—— 传统单机ID的局限性在单机数据库时代，我们通常使用数据库的自增主键（Auto Increment Primary Key） 来为数据赋予一个唯一的ID。这种方式简单可靠。 但是，在分布式系统（如微服务架构）中，问题变得复杂： 分库分表：数据被水平拆分到多个数据库或表中。如果每个库/表都使用自己的自增ID，很快就会产生重复的ID，无法保证全局唯一。 性能瓶颈：如果所有ID都从一个中央数据库的自增序列获取，这个数据库就会成为系统的单点瓶颈和潜在故障点，无法满足高并发场景。 安全性与连续性：直接暴露的自增ID很容易被猜出业务量（例如，通过ID大小推测订单数量），存在安全隐患。同时，自增ID通常是连续的，在某些场景下不希望被猜测。 分布式ID的核心需求一个理想的分布式ID生成方案，应该尽可能满足以下要求： 全局唯一：这是最基本的要求，绝不能出现重复的ID。 高性能高可用：生成服务必须能应对高并发请求，且需...