Table of Contents
API Rate Limiting vs. Throttling
Rate Limiting 和 Throttling 最容易混淆的地方，在于它们都限制 API 请求，但关注的问题并不相同。Rate Limiting 的核心是定义客户端在一定时间内最多可以发送多少请求，强调公平使用和防止资源滥用；Throttling 则是在系统压力过大或客户端超过限制时，主动减缓甚至暂停请求处理，以保护服务稳定性。文章强调，两者不是同义词，而是流量治理中的两种不同手段。
文章主要通过两者的目标、实现方式和适用场景进行对比，说明 Rate Limiting 更偏向事前约束，例如按用户、API Key 或套餐设置请求配额；而 Throttling 更偏向运行时控制，可以通过延迟响应、请求排队、限制并发或临时封禁等方式应对突发流量。作者进一步说明，它们共同服务于系统稳定、防止恶意攻击和保障公平访问，但解决的是不同层面的流量管理问题。
真正需要记住的是，Rate Limiting 定义的是“允许请求多少”，Throttling 决定的是“系统如何处理超出的请求”。前者是访问策略，后者是流量控制机制。在实际系统中，两者通常配合使用：先通过限流建立访问边界，再通过节流平滑流量、保护后端服务，而不是在二者之间二选一。
API 限流真正要解决的问题，不是简单限制请求次数，而是 在保证系统稳定的前提下，公平地分配有限资源。如果没有限流，少数客户端的异常流量或恶意请求就可能耗尽系统资源，影响所有用户。文章强调，限流的目标不是阻止访问，而是控制流量，让系统始终运行在可承受范围内。
文章重点说明，限流不仅涉及算法（如 Fixed Window、Sliding Window、Token Bucket、Leaky Bucket），更重要的是如何制定策略。作者围绕限流对象（IP、用户、API Key、租户）、限流粒度（全局、API、接口）、不同算法的取舍以及返回 HTTP 429 Too Many Requests 后的处理方式展开，说明限流应结合业务特点设计。例如，公共接口更关注防止滥用，付费 API 更关注不同套餐的配额，而高价值接口则需要更严格的限制。最佳实践还包括分层限流、暴露限流信息（如剩余额度和重置时间）、客户端采用指数退避（Exponential Backoff）重试，以及持续监控和调整阈值。
真正需要记住的是，限流的核心不是选择某一种算法，而是建立一套流量治理机制。算法决定“如何限制”，策略决定“限制谁、限制多少、什么时候放行”。一个好的限流方案既能保护系统免受流量冲击，又不会无谓地影响正常用户体验，它本质上是在系统容量、业务公平性和用户体验之间寻找平衡。
API Gateway 与 Load Balancer 最容易混淆的地方，在于它们都会接收客户端请求，但解决的问题完全不同。负载均衡关注的是 请求应该交给哪台服务器处理，属于基础设施层的流量调度；API Gateway 关注的是 请求应该如何进入系统，负责统一入口、协议转换、认证授权、限流等面向 API 的管理能力。文章强调，两者并非互相替代，而是位于请求链路中的不同位置，各自承担不同职责。
文章通过职责对比说明二者的边界：Load Balancer 根据服务器健康状态、负载和调度算法，将流量分发到多个实例，提高系统的可用性和扩展性；API Gateway 则作为客户端与后端服务之间的统一入口，对外隐藏内部服务结构，并集中处理认证、授权、请求路由、协议转换、缓存、限流、日志等横切能力，使微服务能够专注于业务逻辑。两者通常协同工作：请求先经过 Gateway 完成 API 层面的处理，再由 Load Balancer 将流量分配给具体服务实例。
真正需要记住的是，Load Balancer 管理的是 服务器，解决的是系统可用性和流量分发；API Gateway 管理的是 API，解决的是接口治理和统一入口。两者关注点不同、职责互补，在现代微服务架构中往往同时存在，而不是二选一。
负载均衡算法真正要解决的问题，不是“如何把请求分出去”，而是“依据什么规则把请求分给最合适的服务器”。服务器性能、当前负载、请求耗时都可能不断变化，因此请求分配策略直接影响系统的吞吐量、响应时间和资源利用率。文章围绕不同算法的设计思路，说明负载均衡本质上是一个动态调度问题，而不是简单的流量平均分配。
文章重点将算法分为两类：静态算法和动态算法。静态算法（如 Round Robin、Weighted Round Robin、IP Hash）根据预设规则分配请求，实现简单、开销低，适用于服务器性能相近且负载稳定的场景；动态算法（如 Least Connections、Weighted Least Connections、Weighted Response Time、Resource-Based）则会结合连接数、响应时间、CPU、内存等实时状态做决策，更适合请求耗时不均或服务器性能存在差异的环境。作者借此说明，算法越智能，通常需要更多运行时信息，也意味着更高的实现和维护成本。
真正需要记住的是，没有“最好的”负载均衡算法，只有适合业务特点的算法。静态算法追求简单和稳定，动态算法追求资源利用率和响应性能；选择哪一种，取决于流量模式、服务器异构程度以及系统对实时调度能力的需求，而不是算法本身是否更高级。
负载均衡真正要解决的问题，不是把请求平均分给多台服务器，而是在流量不断变化、服务器状态不断变化的情况下，持续保证系统的 性能、可用性和可靠性。如果所有请求都集中到一台服务器，再强的机器也会成为瓶颈；而负载均衡的价值就在于根据实际情况合理分配请求，并在服务器故障时自动切换，避免整个服务不可用。
文章重点说明，负载均衡不仅是一个流量转发器，而是一套动态调度机制。作者通过静态算法与动态算法的对比，解释为什么有些场景只需按固定规则分配流量，而有些场景必须结合服务器健康检查、当前负载和故障转移（Failover）实时调整请求去向，并进一步介绍负载均衡在 Web 应用、云计算和全球服务中的作用。
真正需要记住的是，负载均衡的目标从来不是“平均”，而是“让系统始终保持最佳运行状态”。请求是否平均分配只是实现手段，最终关注的是降低延迟、提高吞吐量、避免单点故障，并在服务器异常时让用户几乎感知不到服务中断。
API 缓存真正要解决的问题，不是单纯让接口更快，而是在 性能、成本和数据一致性之间取得平衡。很多系统性能瓶颈并非来自业务逻辑，而是大量重复请求不断访问数据库或后端服务。文章讨论不同缓存策略如何减少重复计算、降低服务器负载，同时保证用户不会长期读取过期数据。
文章重点说明，缓存并不是只有一种实现方式，而是需要根据数据特点选择策略。作者围绕客户端缓存、服务器缓存、数据库缓存以及 CDN 等不同层级，解释哪些数据适合缓存、缓存应该保存多久（TTL）、何时失效以及如何更新。核心思想是：变化频率低的数据可以采用较长缓存时间，而实时性要求高的数据则需要结合缓存失效（Cache Invalidation）、更新（Refresh）或重新验证（Validation）机制，在响应速度和数据准确性之间取得平衡。
真正需要记住的是，缓存不是为了替代数据库，而是减少对数据库的重复访问。缓存策略设计的重点也不是“缓存什么”，而是“什么时候更新、什么时候失效”。性能问题往往可以通过增加缓存解决，而缓存带来的最大挑战始终是数据一致性，因此一个好的缓存方案本质上是在速度和正确性之间做权衡。