NoRipple https://nowave.cloud// 如是我闻，姑妄听之 Tue, 26 May 2026 11:10:51 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, 宗海 <![CDATA[Java Serializable]]> https://nowave.cloud//article/1f7beb96-1d72-80d7-829f-cf6b867f98d5 https://nowave.cloud//article/1f7beb96-1d72-80d7-829f-cf6b867f98d5 Sun, 18 May 2025 00:00:00 GMT
序列化：将数据结构或对象转换成可以存储或传输的形式，通常是二进制字节流，也可以是 json、xml 等文本格式。
反序列化：将在序列化过程中所生成的数据转化为原始数据结构或者对象的过程。
序列化（serialization）在计算机科学的数据处理中，是指将数据结构或对象状态转换成可取用格式（例如存成文件，存于缓冲，或经由网络中发送），以留待后续在相同或另一台计算机环境中，能恢复原先状态的过程。依照序列化格式重新获取字节的结果时，可以利用它来产生与原始对象相同语义的副本。对于许多对象，像是使用大量引用的复杂对象，这种序列化重建的过程并不容易。面向对象中的对象序列化，并不概括之前原始对象所关系的函数。这种过程也称为对象编组（marshalling）。从一系列字节提取数据结构的反向操作，是反序列化（也称为解编组、deserialization、unmarshalling）。
常见序列化协议：

1. JDK

实现 JDK 自带的序列化，只需要实现 java.io.Serializable 接口即可。
Serializable 是标记接口，实现标记接口类仅仅是标记类为可序列化，并没有增加任何方法，该接口告诉 JVM 该类的对象已经准备好写入持久性存储或者通过网络读取。
静态变量不会被序列化，因为其不是对象本身的一部分。
默认情况，JVM 负责编写和读取可序列化对象的过程。序列化或者反序列化的功能通过对象流类的以下两种方法公开：
  • ObjectOutputStream writeObject(Object): 将可序列化的对象写入输出流。
  • ObjectInputStream readObject(): 从输入流读取（寻找到序列化类之后）构造并返回一个对象。
对于可序列化类需要注意两个成员变量：
  • serialVersionUID：常数，用于唯一标识可序列化类的版本。从输入流构造对象时，JVM 检查此常数。serialVersionUID是可选的，这意味着即使不显示声明，编译器会基于类的元素自动生成（如果元素变化，serialVersionUID 也会随之变化），这也是显示指明的优点，即类的修改不会导致序列化失败。
A serializable class can declare its own serialVersionUID explicitly by declaring a field named "serialVersionUID" that must be static, final, and of type long;
  • transient：标记瞬时变量，JVM 不会序列化并存储此变量值，在反序列化后变量值被设置为类型默认值。
不推荐使用
很少或者说几乎不会直接使用 JDK 自带的序列化方式，主要原因有下面这些原因：
不支持跨语言调用 : 如果调用的是其他语言开发的服务的时候就不支持了。
性能差：相比于其他序列化框架性能更低，主要原因是序列化之后的字节数组体积较大，导致传输成本加大。
存在安全问题：序列化和反序列化本身并不存在问题。但当输入的反序列化的数据可被用户控制，那么攻击者即可通过构造恶意输入，让反序列化产生非预期的对象，在此过程中执行构造的任意代码。

2. Kryo

3. Protobuf / ProtoStuff

4. Hessian

]]> <![CDATA[CDN]]> https://nowave.cloud//article/1f7beb96-1d72-804b-988c-ca0550d4f4fc https://nowave.cloud//article/1f7beb96-1d72-804b-988c-ca0550d4f4fc Sun, 18 May 2025 00:00:00 GMT
Control Delivery Network，即内容分发网络。
所谓内容指的是静态资源，比如图片、视频、文档、js、css、html。
所谓分发网络指的是讲这些静态资源分发到位于多个不同地理位置的机房中的服务器上，以实现静态资源的就近访问。
CDN 就是将静态资源分发到不同的地方以实现对应地区的就近访问，进而加快静态资源的访问速度，减轻服务器以及带宽的负担。
也可以将其视作服务上一层特殊缓存，主要用来处理静态资源。
  • ECDN / DCDN
    • 同时加速动态资源和静态资源。动态加速是指对于那些不能缓存在边缘节点的资源，动态资源基于智能选路技术，从多条回源线路中择优选择一条线路进行传输。
    • 支持边缘计算。
  • CDN
    • 加速静态资源。
    • 支持边缘计算。
其实实现资源的就近访问还可以直接将服务部署在不同地区，但这样做会出现两个问题。一是成本太高，这不言自明；二是性能影响，静态资源的访问对系统资源的大到足以影响到系统中的其他服务。这种行为主要是实现系统的高可用而非高性能。
  1. 静态资源缓存 CDN 节点。
      • 回源当 CDN 节点上没有用户请求的资源或该资源的缓存已经过期时，CDN 节点需要从原始服务器获取最新的资源内容，这个过程就是回源。当用户请求发生回源的话，会导致该请求的响应速度比未使用 CDN 还慢，因为相比于未使用 CDN 还多了一层 CDN 的调用流程。
      • 预热指在 CDN 上提前将内容缓存到 CDN 节点上。这样当用户在请求这些资源时，能够快速地从最近的 CDN 节点获取到而不需要回源，进而减少了对源站的访问压力，提高了访问速度。
      • 刷新如果资源有更新的话，你也可以对其刷新 ，删除 CDN 节点上缓存的旧资源，并强制 CDN 节点回源站获取最新资源。
      命中率和回源率是衡量 CDN 服务质量的重要指标。
  1. 服务定位 CDN 节点。
      2. Global Server Load Balance，全局负载均衡。
      负责多个 CDN 节点之间相互协作，最常用的是基于 DNS 的 GSLB。
      CDN 会通过 GSLB 找到最合适的 CDN 节点
    1. 防止静态资源盗用。
    2. Referer 防盗链，具体来说就是根据 HTTP 请求的头信息里面的 Referer 字段对请求进行限制。我们可以通过 Referer 字段获取到当前请求页面的来源页面的网站地址，这样我们就能确定请求是否来自合法的网站。
    3. 时间戳防盗链的 URL 通常会有两个参数一个是签名字符串，一个是过期时间。签名字符串一般是通过对用户设定的加密字符串、请求路径、过期时间通过 MD5 哈希算法取哈希的方式获得。
 
]]> <![CDATA[JVM]]> https://nowave.cloud//article/1f7beb96-1d72-806f-8261-e3e1c6f44968 https://nowave.cloud//article/1f7beb96-1d72-806f-8261-e3e1c6f44968 Sun, 18 May 2025 00:00:00 GMT

基础知识

JVM 本质上是一个运行在计算机上的程序，主要职责是解释运行、内存管理和即时编译。
JVM 遵循 JVM 虚拟机规范，各大厂家研发不同版本。本文章讨论的是 hotspot(oracle jdk
notion image

字节码文件

基本信息
  1. 文件头 文件无法通过文件扩展名来确定文件类型，软件使用文件的头几个字节校验文件类型，这一部分也被成为 Magic Value。
  1. 主副版本号 编译字节码文件的 jdk 版本号，主要用来判断当前字节码版本和运行环境 jdk 是否兼容。
  1. 访问标志
  1. 类、父类、接口索引
  1. 常量池
  1. 字段
  1. 方法

类加载器

类的生命周期
  1. Loading类加载器根据类的全限定名通过不同渠道以二进制流的方式获取字节码信息。程序员可以通过 JAVA 代码扩展不同渠道（动态代理）。JVM 会将字节码的信息保存在内存方法区（InstanceKlass），同时生成类似数据保存在堆区（ java.lang.Class ），作用是在 java 代码中去获取类的信息以及存储静态字段的数据，也就是反射。方法区中的对象是由 c++编写，java 代码不能直接操作，所以在堆区创建一个 java 编写的对象以便获取。而且堆区中的类对象包含数据更少，这是基于开发者需要和安全性考虑，只让开发者访问一部分数据。
  1. Linking不需要程序员参与。
  1. 验证内容是否合规。
  1. 为静态变量分配内存并赋初始值。
  1. 将常量池中的符号引用替换成指向内存的直接引用。
  1. Initialiazation执行静态代码块中的代码，并为静态变量赋值。类的初始化并不会在加载到堆区后马上进行，需要满足触发条件：
  1. 访问类的静态变量或者静态方法，访问父类的静态变量，不会触发子类的初始化。
  1. 调用 Class.forName(className)
  1. new Instance，数组创建不会导致数组中元素类初始化。
  1. 执行 Main 方法的当前类
  1. Using
  1. Unloading
类加载器负责把字节码文件加载到内存。

类加载器分类

除了顶层启动类加载器，所有的其他加载器都有自己的父类加载器。
  1. 启动类加载器 Bootstrap ClassLoader（c++）或者 BootClassLoader（java） 加载 Java 最核心的类，是由虚拟机提供的类加载器。默认加载/jre/lib 下的类文件。 开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
  1. 扩展类加载器 Extension ClassLoader（jdk 1.8） 或者 Platform ClassLoader（jdk 9） 负责将Java_Home /lib/ext或者由系统变量 java.ext.dir指定位置中的类库加载到内存中。 开发者可以直接使用标准扩展类加载器。
  1. 应用程序类加载器 / 系统加载器 负责将系统类路径（CLASSPATH）中指定的类库加载到内存中。 由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，因此一般称为系统（System）加载器。 开发者可以直接使用系统类加载器。
  1. 自定义类加载器

双亲委派机制

类加载器与类唯一性
类加载器虽然只用于实现类的加载动作，但是对于任意一个类，都需要由加载它的类加载器和这个类本身共同确立其在Java虚拟机中的唯一性。通俗的说，JVM中两个类是否“相等”，首先就必须是同一个类加载器加载的，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要类加载器不同，那么这两个类必定是不相等的（同时在堆区也会有两份 class 文件）
这里的“相等”，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。
双亲委派机制的核心是解决类由谁加载。
双亲委派模型的工作过程为：如果一个类收到类加载请求，首先检查自己是否加载过，若是则直接返回，否则把这个请求委派给父类加载器完成而不是尝试自己加载，因此所有的类加载请求都会传到顶层的启动类加载器，只有当父类加载器反馈自己无法完成该加载请求，才会自上而下尝试加载。
这显然避免了重复加载的问题，同时自然的类随着类加载器带有优先级。
例如类java.lang.Object，它存在在rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的Bootstrap ClassLoader进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。
相反，如果没有双亲委派模型而是由各个类加载器自行加载的话，如果用户编写了一个java.lang.Object的同名类并放在ClassPath中，那系统中将会出现多个不同的Object类，程序将混乱。因此，如果开发者尝试编写一个与rt.jar类库中重名的Java类，可以正常编译，但是永远无法被加载运行。

破坏双亲委派机制

双亲委派模型是Java设计者推荐给开发者的类加载器的实现方式，并不是强制规定的。
大多数的类加载器都遵循这个模型，但是JDK中也有较大规模破坏双亲模型的情况。
  1. 自定类加载器 自定义类继承 ClassLoader 类，重写 loadClass 方法（首先尝试自己加载而不是寻找父类加载器）和 findClass（从特定路径寻找类） 方法。 Tomcat 通过这种方式实现应用之间的类隔离。 ___。 __根据类的唯一性，这需要确保二者的类加载器不同，所以 Tomcat 使用自定义类加载器来实现应用之间类的隔离，每一个应用会有一个独立的类加载器加载对应类。 _自定义类仍然可以用于类加密、热部署和热更新以及模块化和插件化。
      2. 一个 Tomcat 程序可以运行多个 Web 应用，如果两个应用中出现了限定名相同的类，Tomcat 需要保证他们都能被加载并且明确是两个不同的类
  1. 线程上下文加载器线程上下文类加载器允许开发者在特定的线程中指定一个类加载器，这样在该线程内的一些操作（如资源查找等）就会使用这个指定的类加载器，而不是默认的类加载器。 每个类都会使用加载自己的类加载器去加载其他类，但是对于SPI来说，有些接口是Java核心库所提供的,而Java核心库是由启动类加载器来加载的，而这些接口的实现却来自于不同的jar包(厂商提供)， Java的启动类加载器是不会加载其他来源的jar包，这样传统的双亲委托模型就无法满足SPI的要求。而通过给当前线程设置上下文类加载器，就可以由设置的上下文类加载器来实现对于接口实现类的加载。
  1. OSGi 实现一整套类加载机制，允许同级类加载器之间互相调用。

运行时数据区

线程私有

  1. Program Counter Register 程序计数器，每个线程会通过程序计数器记录当前要执行的字节码指令地址。 可以控制程序指令的进行和线程切换恢复执行。
  1. Java Virtual Machine Stack 每个 Java 方法被执行的时候，Java虚拟机都会同步创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每一个方法被调用直至执行完毕的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
  1. Native Method Stacks 本地方法栈存储本地方法栈帧，在 HotSpot 虚拟机中，Java 虚拟机栈和本地方法栈实现上使用了同一个栈空间。

线程共享

  1. Java Heap 分配内存空间以创建并存储对象。
    1. Heap 对于堆空间来说，有三个需要关注的值，_used、total、max__。_ used 指当前已使用的堆内存，total 指 JVM 已经分配的可用堆内存，max 指 JVM 可以分配的最大堆内存。 max 默认是系统内存 1/4，total 默认是系统内存 1/64。在实际应用中一般需要设置 max 和 total 的值。（-Xmx -Xms）
    2. Object
      1. 创建过程
        1. 类加载检查
        2. 划分可用空间 同步锁定：对分配内存空间的动作进行同步处理，实际上虚拟机是采用CAS配上失败重试的方式保证更新操作的原子性。 分配缓冲：另外一种是把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB），哪个线程要分配内存，就在哪个线程的本地缓冲区中分配，只有本地缓冲区用完了，分配新的缓存区时才需要同步锁定。
        3. 初始化零值 内存分配完成之后，虚拟机必须将分配到的内存空间（但不包括对象头）都初始化为零值（如果使用了TLAB的话，这一项工作也可以提前至TLAB分配时顺便进行）。 这步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值。
        4. 设置对象头
        5. 执行 init 方法
      2. 内存布局
        1. Header存储对象自身的运行时数据。 如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部分数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32个比特和64个比特，官方称它 为“Mark Word”。指向它的类型元数据的指针。
        2. Instance Data 对象真正存储的有效信息。
        3. Padding占位符。HotSpot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍，如果对象实例数据部分没有对齐的话，就需要通过占位符对齐填充来补全。
      3. 访问定位
        1. 句柄访问 句柄来访问的最大好处就是reference中存储的是稳定句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而reference本身不需要被修改。
            2. notion image
        2. 直接指针 使用直接指针来访问最大的好处就是速度更快，它节省了一次指针定位的时间开销，由于对象访问在Java中非常频繁，因此这类开销积少成多也是一项极为可观的执行成本，_就虚拟机HotSpot而言，它主要直接指针进行对象访问。__ _
            3. notion image
  1. Method Area JDK 7 将 Method Area 存放在在 Java Heap: Permanent Generation （-XX:MaxPermSize=Value 控制） JDK 8 将 Method Area 存放在操作系统维护的直接内存（元空间） （默认情况下只要不超过操作系统承受上限，可以无限分配。也可以使用 -XX：MaxMataSpaceSize=Value 控制）
    1. 类的元信息主要是类的定义。
    2. 运行时常量池 字节码文件中通过编号查表的方法找到常量，这种常量池成为静态常量池。当静态常量池加载到内存中，可以通过内存地址快速定位到常量池中内容，这种常量池称为运行时常量池。
    3. 字符串常量池存储代码中定义的常量字符串内容。

自动垃圾回收

Java 为了简化对象释放，引入自动垃圾回收机制。
Java 通过垃圾回收器对不再使用的对象完成自动回收。

标记可回收

常见对象引用

  1. Strongly Re-ference 指在程序代码中普遍存在的引用赋值。 无论任何情况，只要强引用关系存在，GC 永远不会回收被引用的对象。
  1. Soft Reference 描述非必须对象。 JDK 提供 SoftReference Class 实现，主要应用于缓存。 只被软引用关联的对象，在系统将要发生内存溢出异常前，会被列入回收范围进行二次回收，回收后若仍没有足够内存，才会抛出 OOM。
  1. Weak Reference 描述非必须对象。 JDK 提供 WeakReference Class 实现，弱引用主要在 ThreadLocal 应用。 GC 工作时无论当前内存是否足够都会回收掉只被弱引用关联的对象。
  1. Phantom Reference 最弱引用关系。 一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。常规开发不会使用。
  1. 终结器引用 指在对象需要被回收时，终结器引用会关联对象并放置在 Finalizer 类中的引用队列中，在稍后由 FinalizerThread 线程从队列中获取对象，然后执行对象的 fianlize 方法，在对象第二次被回收时，该对象才真正被回收。 这个过程中可以在 finalize 方法中再将自身对象使用强引用关联。 在最终清除资源之前，给予一定缓冲区来进行必要的处理和恢复操作。常规开发不会使用。

判断对象存活

  1. 引用计数法 引用计数法会为每个对象维护一个引用计数器，当对象被引用时加1，取消引用时减1. 但每次引用和取消引用都需要维护计数器，影响系统性能。同时存在循环引用，出现对象无法回收的问题。
  1. 可达性分析算法 可达性分析算法将对象分为两类：垃圾回收的根对象和普通对象，对象与对象之间存在引用关系。 可达性分析算法指的就是如果某个对象到 GC Root 是可达的，该对象就不会被回收。 JVM 采用此方法判断对象是否可回收。 GC Root 大致有：
    1. 线程 Thread 对象，引用线程栈帧中的方法参数、局部变量。
    2. 系统类加载器加载的 java.lang.Class 独享，引用类中的静态变量。
    3. 监视器对象，用来保存同步锁 synchronized 关键字持有对象。
    4. 本地方法调用时使用的对象。

方法区回收

主要回收废弃常量和不再使用的类。
  1. 手动触发回收 System.gc()，但是这并不会立即回收垃圾，仅仅是向 JVM 发送垃圾回收请求，是否需要执行由 JVM 判断。
  1. 自动判定回收
    1. 此类所有实例对象都已经被回收，Java Heap 中不存在任何派生子类实例。
    2. 加载该类的类加载器已经被回收，也就是说自定义类只要被加载就永远不会被回收，因为它们的加载器是应用加载器。
    3. 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类方法。
JVM 被允许对满足上述条件的类进行回收。
HotSpot 提供参数 -Xnoclassgc 参数控制是否回收。
在大量使用反射、动态代理等字节码框架，动态生成 JSP 这类频繁自定义类加载器的场景中，通常需要 JVM 具备类型卸载能力，以保证不会对方法区造成过大的内存压力。

堆回收

垃圾回收算法

  1. Mark-Sweep 标记所有需要回收对象，标记完成后，统一回收所有被标记对象。 这种方法有以下缺点：
    1. 执行效率不稳定，标记和清除的效率随对象数量增长而降低。
    2. 内存空间碎片化，标记清除后产生大量不连续内存碎片，可能导致无法为大对象分配空间而不得不提前触发另一次垃圾回收。
  1. Marker-Compact 标记过程和 Marker-Sweep 相同，但是后续步骤不是直接对回收对象进行清理，而是让所有对象都向内存空间的一端移动，然后直接清理掉边界以外的内存。 这问题，但是移动存活对象并更新所有引用是一种相当负重的操作，而且这种移动对象，像这样长时间的停顿被表述 （Stop The World）。 另外 Mark-Sweep 算法也是需要停顿用户线程来标记、清理可回收对象的，只是时间相对较短。
      2. 解决了 Marke-Sweep 算法带来的内存空间碎片化
      操作必须全程暂停用户应用程序才能进行
      STW
  1. Semispace Copying 将 Java Heap 按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用尽，就将仍然存活的对象复制到另外一块内存，并把已经使用的内存空间一次性清理。对于大多数对象可回收的情况，算法需要复制的就是极少数的对象。而且每次都是针对整个半区进行内存回收，分配内存的时候也不用考虑空间碎片。 但是如果内存中大多数对象存活，将会产生大量内存间复制的开销；
  1. Generational Collection 开发者观察到这样一些事实：
    1. 绝大多数对象都是朝生夕灭。
    2. 经过垃圾回收次数越多的对象就越难以消亡。
    3. 跨代引用相对于同代引用来说仅占极少数。
于是收集器进一步划分 Java Heap 为更多区域，然后将回收对象根据其年龄（经过垃圾收集的次数）分配到不同区域存储，不同区域可以采用适应环境的回收算法。
notion image
具体的说，内存区域被划分为 Young 和 Old，前者存储存活时间较短的对象，后者存放存活时间较长的对象。其中 Young 又被进一步划分为 Eden 和 Survivor 区域。（默认 Eden 和 Survivor 大小比例 8:2）而 Survivor 又被划分为 From 和 To 区域。
新创建对象会被放入 Young:Eden 区域，随着对象增多到达上限，触发所谓 Young GC 也叫 Minor GC。
Young GC 类似于 Semispace Copying 算法，回收 Young:Elden 和 Young:Survivor:From 区域内的可回收对象，其他对象放入 Young:Survivor:To 区域并交换 From 区域和 To 区域（这里的交换是逻辑交换），倘若 Young:Survivor:To 不足以容纳所有对象触发分配担保机制即多余对象直接进入老年代。
每次 Young GC 会记录对象年龄，当对象年龄达到阈值，对象晋升至 Old 区域，如此积累，当 Old 区域空间不足时，先尝试触发 Young GC，再紧接着触发 Full GC。Full GC 会对整个 Java Heap 进行垃圾回收，倘若仍然无法腾出空间，当新对象继续放入 Old 时抛出 OOM 异常。

垃圾回收器

垃圾回收器是垃圾回收算法的具体实现。
经典搭配：
  1. Serial & Serial Old
    1. Serial：单线程串行回收年轻代（Semispace Copying），单核 CPU 表现较好。
    2. Serial Old：单线程串行回收老年代（Sweep-Compact）
  1. ParNew & CMS
    1. ParNew：多线程回收年轻代（Semispace Copying）
    2. CMS：并发回收老年代（Mark-Sweep），垃圾回收停顿时间较短。
  1. Parallel Scavenge & Parallel Old
    1. Parallel Scavenge，多线程并行回收 Young（Semispace Copying），能自动调整堆内存。
    2. Parallel Old，多线程并发回收 Old（Mark-Sweep），多核 CPU 效率高。
不同于上述垃圾回收器，G1 收集器建立了可预测的停顿时间模型（_Pause Prediction Model__，即能够实现在一个长度为 m 毫秒的时间片段内，消耗在垃圾回收的时间大概率不超过 n 毫秒_）。
G1 不再坚持固定大小以及固定数量的分代区域划分，Java Heap 被划分为多个大小相等的 Region（Region 可以根据需要扮演 Eden、Survivor 或者 Old）。
将Java堆分成多个独立Region后，Region里面存在的跨Region引用对象如何解决？记忆集。
使用记忆集避免全堆作为GC Roots扫描，但在G1收集器上记忆集的应用其实要复杂很多，它的每个Region都维护有自己的记忆集，这些记忆集会记录下别的Region指向自己的指针，并标记这些指针分别在哪些卡页的范围之内。
G1的记忆集在存储结构的本质上是一种哈希表，Key是别的Region的起始地址，Value是一个集合，里面存储的元素是卡表的索引号。
这种“双向”的卡表结构（卡表是“我指向谁”，这种结构还记录了“谁指向我”）比原来的卡表实现起来更复杂，同时由于Region数量比传统收集器的分代数量明显要多得多，因此G1收集器要比其他的传统垃圾收集器有着更高的内存占用负担。
根据经验，G1至少要耗费大约相当于Java堆容量10%至20%的额外内存来维持收集器工作。
G1 将 Region 作为单次回收的最小单元，即每次收集到的内存空间都是 Region 的整数倍，这样可以有计划的避免在整个 Java Heap 中进行全区域的垃圾收集。同时 G1 会跟踪每个 Region 的回收优先级（受回收获得空间和回收所需时间影响），每次根据用户设置允许收集停顿时间（默认 200 ms）优先处理回收优先级最高的 Region，这也是 Garbage First 名称的由来。
这种使用 Region 划分内存空间、具有优先级的区域回收方式，保证 G1 在有限的时间内获取尽可能高的收集效率。
  • Young GC当 G1 判断年轻代不足（默认 Eden / Java Heap = 60%），触发 Young GC。 回收 Eden 和 Survivor 中可回收对象，会导致 STW，G1 支持设置最大暂停时间并尽力保证。
    • 标记 Eden 区域和 Survivor 区域中存活对象。
    • 根据设定最大暂停时间复制存活对象到新的 Survivor 区域，清空标记区域。（过程中会记录每次垃圾回收时 Eden 和 Survivor 的平均耗时作为下次回收的参考依据）
    • 当某个存活对象年龄达到阈值（默认 15），移入 Old 区域。
    • 某个对象大小超过 Region / 2，直接放入 Humongous（Old），对象过大可以横跨多个 Region。
  • Mixed GC 当 G1 判断老年代过大（默认 Old / Java Heap = 45%），触发 Mixed GC。 Mixed GC 回收部分 Eden、Old 以及 Humongous，选择依据 G1 维护的优先级列表，回收采用复制算法，如果清理过程中没有足够的 Region 存放转移对象触发 Full GC，单线程执行 Mark Sweep 算法，此时会导致不受控制的用户线程停顿。

参数调优

 
]]> <![CDATA[Nginx]]> https://nowave.cloud//article/1f7beb96-1d72-8019-b3ef-f040690a4a8f https://nowave.cloud//article/1f7beb96-1d72-8019-b3ef-f040690a4a8f Sun, 18 May 2025 00:00:00 GMT

Nginx 功能与配置

2.1 master-worker

正式提供服务的产品环境下，部署 Nginx 使用一个 master 进程管理若干 worker 进程，一般情况下，worker 进程数量等同于服务器的 CPU 核心数。
worker 进程真正提供互联网服务。
master 负责监控 worker 进程。
当然 Nginx 支持单进程提供服务（master），采用 master-workers 的好处：
  1. master 可以专注于管理，并且为程序员提供命令行服务。
  1. worker 可以充分利用常见 SMP 多核架构，从而实现围观上真正的并发处理。
为什么要把worker进程数量设置得与CPU核心数量一致呢？
这正是 Nginx与Apache服务器的不同之处。
在Apache上每个进程在一个时刻只处理一个请求，因此，如果希望Web服务器拥有并发处理的请求数更多，就要把 Apache的进程或线程数设置得更多，通常会达到一台服务器拥有几百个工作进程，这样大量的进程间切换将带来无谓的系统资源消耗。
而 Nginx则不然，一个worker进程可以同时处理的请求数只受限于内存大小，而且在架构设计上，不同的worker进程之间处理并发请求时几乎没有同步锁的限制，worker进程通常不会进入睡眠状态，因此，当Nginx上的进程数与CPU核心数相等时（最好每一个worker进程都绑定特定的CPU核心），进程间切换的代价是最小的。
 

2.2 通用语法

块配置项

块配置项名和大括号。
events、http、server、location、upstream等都是块配置项，块配置项之后是否如“location/webstatic{…}”那样在后面加上参数，取决于解析这个块配置项的模块，不能一概而论，但块配置项一定会用大括号把一系列所属的配置项全包含进来，表示大括号内的配置项同时生效。所有的事件类配置都要在events块中，http、server等配置也遵循这个规定。
块配置项可以嵌套。内层块直接继承外层块，例如，上例中，server块里的任意配置都是基于http块里的已有配置的。当内外层块中的配置发生冲突时，究竟是以内层块还是外层块的配置为准，取决于解析这个配置项的模块，第4章将会介绍http块内配置项冲突的处理方法。

配置项

配置项名+配置项值
在行首的是配置项名，这些配置项名必须是Nginx的某一个模块想要处理的，否则Nginx会认为配置文件出现了非法的配置项名。配置项名输入结束后，将以空格作为分隔符。
其次是配置项值，它可以是数字或字符串（当然也包括正则表达式）。
针对一个配置项，既可以只有一个值，也可以包含多个值，配置项值之间仍然由空格符来分隔。当然，一个配置项对应的值究竟有多少个，取决于解析这个配置项的模块。
有些模块允许在配置项中使用变量，使用它的时候前面要加上$符号。需要注意的是，这种变量只有少数模块支持，并不是通用的。
许多模块在解析请求时都会提供多个变量（如本章后面提到的http coremodule、http proxy module、http upstream module等），以使其他模块的配置可以即时使用。

2.3 基本配置

Nginx在运行时，至少必须加载几个核心模块和一个事件类模块。
这些模块运行时所支持的配置项称为基本配置（所有其他模块执行时都依赖的配置项）。
用于调试进程和定位问题的配置项
  1. daemon on|off是否以守护进程方式运行Nginx（默认 daemon on;）守护进程（daemon）是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示，这样一来，进程也不会被任何终端所产生的信息所打断。
  1. master_process on|off;是否以master/worker方式工作（默认 master_process on;）
  1. error_log/path/file level;error日志设置（默认 error_log logs/error.log error;）/path/file 可以是一个具体文件，日志保存在该文件；/path/file 也可以是/dev/null，这样不会输出日志；/path/file 也可以是stderr，这样日志会输出到标准错误文件中。level是日志的输出级别，取值范围是debug、info、notice、warn、error、crit、alert、emerg，从左至右级别依次增大。当设定为一个级别时，大于或等于该级别的日志都会被输出到/path/file文件中，小于该级别的日志则不会输出。
  1. worker_rlimit_core size限制coredump核心转储文件的大小。在 Linux 系统中，当进程发生错误或收到信号而终止时，系统会将进程执行的内存内容（核心影响）写入文件（core 文件），以作为调试之用，这就是所谓核心转储（core dumps）。当 Nginx 进程出现非法操作导致进程直接被操作系统强制结束时，就会生成核心转储文件。
  1. working_directory path;指定coredump文件生成目录。worker 进程的工作目录，确保 worker 进程有权向指定目录写入文件。
正常运行的配置项
  1. env VAR|VAR=VALUE定义环境变量
  1. include/path/file;嵌入其他配置文件到当前 nginx.conf
  1. pid path/file;（默认 pid logs/nginx.pid;）保存 master 进程 ID 的 pid 文件存放路径。
  1. user username[groupname];（默认 user nobody nobody;）user用于设置master进程启动后，fork出的worker进程运行在哪个用户和用户组下。当按照“user username;”设置时，用户组名与用户名相同。若用户在configure命令执行时使用了参数–user=username和–group=groupname，此时nginx.conf将使用参数中指定的用户和用户组。
  1. worker_rlimit_sigpending limit;设置每个用户发往Nginx的信号队列的大小。也就是说，当某个用户的信号队列满了，这个用户再发送的信号量会被丢掉。
  1. worker_rlimit_nofile limit;指定Nginx worker进程可以打开的最大句柄描述符个数
优化性能的配置项
  1. worker_processes number;（默认 worker_processes 1;）在master/worker运行方式下，定义worker进程的个数。worker进程的数量会直接影响性能，这实际上与业务需求有关。每个worker进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会出现阻塞式的调用，那么，有多少CPU内核就应该配置多少个进程；反之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。多worker进程可以充分利用多核系统架构，但若worker进程的数量多于CPU内核数，那么会增大进程间切换带来的消耗（Linux是抢占式内核）。一般情况下，用户要配置与CPU内核数相等的worker进程，并且使用下面的worker_cpu_affinity配置来绑定CPU内核。
  1. worker_cpu_affinity cpumask[cpumask…]绑定Nginx worker进程到指定的CPU内核。假定每一个worker进程都是非常繁忙的，如果多个worker进程都在抢同一个CPU，那么这就会出现同步问题。反之，如果每一个worker进程都独享一个CPU，就在内核的调度策略上实现了完全的并发。（worker_cpu_affinity配置仅对Linux操作系统有效。Linux操作系统使用sched_setaffinity()系统调用实现这个功能。）
  1. ssl_engine device；如果服务器上有SSL硬件加速设备，那么就可以进行配置以加快SSL协议的处理速度。
  1. worker_priority nice;（默认 worker_priority 0;）该配置项用于设置Nginx worker进程的nice优先级。在Linux或其他类UNIX操作系统中，当许多进程都处于可执行状态时，将按照所有进程的优先级来决定本次内核选择哪一个进程执行。进程所分配的CPU时间片大小也与进程优先级相关，优先级越高，进程分配到的时间片也就越大。这样，优先级高的进程会占有更多的系统资源。优先级由静态优先级和内核根据进程执行情况所做的动态调整共同决定。nice值是进程的静态优先级，它的取值范围是–20~+19，–20是最高优先级，+19是最低优先级。因此，如果用户希望Nginx占有更多的系统资源，那么可以把nice值配置得更小一些，但不建议比内核进程的nice值（通常为–5）还要小。
事件类配置项
  1. accept_mutex[on|off]（默认 accept_mutext on;）是否打开accept锁accept_mutex 是 Nginx 的负载均衡锁，可以让多个 worker 进程轮流的、序列化的与新的客户端建立 TCP 连接。当一个 worker 进程建立的连接数量达到 worker_connections 配置的最大连接数的 7/8，会大大减小该 worker 进程试图建立新 TCP 连接的机会，以此实现所有 worker 进程处理的客户端请求数尽量接近。accept锁默认是打开的，如果关闭它，那么建立TCP连接的耗时会更短，但worker进程之间的负载会非常不均衡，因此不建议关闭它。
  1. lock_file path/file;（默认 lock_file logs/nginx.lock;）lock文件的路径accept锁可能需要这个lock文件，如果accept锁关闭，lock_file配置完全不生效。如果打开了accept锁，并且由于编译程序、操作系统架构等因素导致Nginx不支持原子锁，这时才会用文件锁实现accept锁，这样lock_file指定的lock文件才会生效。
  1. accept_mutex_delay Nms;（默认 accept_mutex_delay 500ms;）使用accept锁后到真正建立连接之间的延迟时间。在使用accept锁后，同一时间只有一个worker进程能够取到accept锁。这个accept锁不是阻塞锁，如果取不到会立刻返回。如果有一个worker进程试图取accept锁而没有取到，它至少要等accept_mutex_delay定义的时间间隔后才能再次试图取锁。
  1. multi_accept[on|off];（默认 multi_accept off;）是否批量建立新连接。当事件模型通知有新连接时，尽可能地对本次调度中客户端发起的所有TCP请求都建立连接。
  1. use[kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];（Nginx会自动使用最适合的事件模型。）选择事件模型。对于Linux操作系统来说，可供选择的事件驱动模型有poll、select、epoll三种。epoll当然是性能最高的一种，在9.6节会解释epoll为什么可以处理大并发连接。
  1. worker_connections number;每个worker的最大连接数。

2.4 ngx_http_core_module 配置静态代理服务器

静态Web服务器的主要功能由ngx_http_core_module模块（HTTP框架的主
要成员）实现。本节主要讨论如何配置一个包含基本功能的静态Web服务
器，文中会完整地说明ngx_http_core_module模块提供的配置项及变量的用
法，但不会过多说明其他HTTP模块的配置项。
虚拟主机与请求分发
存在多个主机域名对应相同 IP 地址的情况，此时可以按照 server_name 并通过 server 块来定义虚拟主机，每个 server 块就是一个虚拟主机，并且只处理阈值相对应的主机域名请求。这样一台服务器上的 Nginx 就能以不同的方式处理访问不同主机域名的 HTTP 请求。
  1. listen address:port[options]；listen 80；server；listen参数 options 决定Nginx服务如何监听端口。default：将所在 server 块设为 Web 服务默认块。倘若没有这个参数 nginx.conf 中的首个 server 块将作为默认 server 块。当一个请求无法匹配文件中的所有主机域名的时候，就会选择默认虚拟主机。backlog = num:表示 TCP 中 backlog 队列大小，默认-1，表示不予设置。在 TCP 建立三次握手过程中，进程还没有开始处理监听句柄，backlog 队列会放置这些新连接，若队列满，新的连接会建立连接失败。rcvbuf=sizesndbuf=sizeaccept_filterdeferred：设置参数后，若用户发起建立连接请求，并完成 TCP 三次握手，内核也不会为此次连接调度 worker 进程处理，只有用户发送请求数据时内核才会唤醒 worker 进程处理连接。这个参数适用于高并发的情况下，减轻 worker 进程的负担。bind：绑定当前端口/地址对。ssl:在当前监听的端口上建立的连接必须基于 SSL 协议。
  1. server_name name[···]server_name ""serverserver_name 后可以附加多个主机名称。在开始处理 HTTP 请求时，Nginx 会取出 header 头中的 Host 与 server_name 进行匹配来决定处理请求的 server 块。可能会有 Host 与多个 server_name 匹配，这时会根据匹配优先级来选择实际处理的 server 块。Nginx 正是使用此配置项针对特定域名的请求提供不同服务，以此实现虚拟主机功能。
  1. server_names_hash_bucket_size size；server_names_hash_bucket_size 32|64|128http、server、location为了提高快速寻找到相应server name的能力，Nginx使用散列表来存储server name。server_names_hash_bucket_size设置了每个散列桶占用的内存大小。
  1. server_names_hash_max_size size；server_names_hash_max_size 512;http、server、locationserver_names_hash_max_size会影响散列表的冲突率。
  1. server_name_in_redirect on|off;server_name_in_redirect on;http、server或者location重定向主机名称的处理该配置需要配合server_name使用。在使用on打开时，表示在重定向请求时会使用server_name里配置的第一个主机名代替原先请求中的Host头部，而使用off关闭时，表示在重定向请求时使用请求本身的Host头部。
  1. location[=|||^~|@]/uri/{…}serverlocation 会尝试根据用户请求中的 URL 来匹配上面的/uri 表达式，（uri 参数可以使用正则表达式）如果可以匹配，就选择 location{}块中的配置来处理用户请求。当然 location 的匹配方式多样：=表示完全匹配。表示字母大小写敏感匹配。表示忽略字母大小写匹配。^~表示前半部分相同匹配。@表示仅用于 Nginx 服务内部请求之间的重定向，带有@的location不直接处理用户请求。/表示匹配所有请求。
文件路径的定义
  1. root path(默认 root html)http、server、location、if定义资源文件相对于 HTTP 请求的根目录。
  1. alias pathlocation也是用来设置文件资源路径，它与 alias 不同点主要在于如何处理 location 后面的 uri 参数。使用 alias 时会丢弃 location 后面的 uri 参数，root 则不然，它会根据完整的 uri 请求来映射。
  1. index file···(默认 index index.html)http、server、location有时，访问站点时的 url 是 /，这时一般是返回网站的首页。可以后缀多个文件参数，Nginx 会按照顺序来访问这些文件，如果可以访问则直接返回文件内容并结束请求，否则尝试访问其他。
  1. error_page code [code···] /sth.htmlhttp server location if对于某个请求返回错误码时，如果匹配上 error_page 中设置的 code，则重定向到新的 URL 中。虽然重定向 URI，但返回的 HTTP 错误码与原来相同。用户可以使用 = 来更改返回的错误码，或者不指定确切的错误码，而是由重定向后的实际处理结果决定。error_page 404 =200 /empty.giferror_page 404 = /empty.gif如果不想修改 uri，可以想让这样的请求重定向到另一个 location 中进行处理：error_page 404 @fallback<br />location @fallback{}
  1. recursive_error_pages[on|off];
  1. try_files path1[path2]uri;尝试按照顺序访问每一个path，如果可以有效地读取，就直接向用户返回这个path对应的文件结束请求，否则继续向下访问。如果所有的path都找不到有效的文件，就重定向到最后的参数uri上。因此，最后这个参数uri必须存在，而且它应该是可以有效重定向的。
内存及磁盘资源的分配
处理请求时内存、磁盘资源的分配项。
  1. client_body_in_file_only on|clean|off;（默认 client_body_in_file_only off;）http、server、locationHTTP 包体只存储到磁盘文件中。当值为非off时，用户请求中的HTTP包体一律存储到磁盘文件中，即使只有0字节也会存储为文件。当请求结束时，如果配置为on，则这个文件不会被删除（该配置一般用于调试、定位问题），但如果配置为clean，则会删除该文件。
  1. client_body_in_single_buffer on|off;（默认 client_body_in_single_buffer off;）http、server、locationHTTP包体尽量写入到一个内存buffer中。用户请求中的HTTP包体一律存储到内存buffer中。当然，如果HTTP包体的大小超过了下面client_body_buffer_size设置的值，包体还是会写入到磁盘文件中。
  1. client_header_buffer_size size;（默认 client_header_buffer_size 1k;）http、server存储HTTP头部的内存buffer大小。定义了正常情况下Nginx接收用户请求中HTTP header部分（包括HTTP行和HTTP头部）时分配的内存buffer大小。有时，请求中的HTTP header部分可能会超过这个大小，这时large_client_header_buffers定义的buffer将会生效。
  1. large_client_header_buffers number size;（默认 large_client_header_buffers 48k; ）http、server存储超大HTTP头部的内存buffer大小。large_client_header_buffers定义了Nginx接收一个超大HTTP头部请求的buffer个数和每个buffer的大小。如果HTTP请求行（如GET/indexHTTP/1.1）的大小超过上面的单个buffer，则返回"Request URI toolarge"(414)。请求中一般会有许多header，每一个header的大小也不能超过单个buffer的大小，否则会返回"Bad request"(400)。当然，请求行和请求头部的总和也不可以超过buffer个数*buffer大小。
  1. client_body_buffer_size size;（默认 client_body_buffer_size 8k/16k;）http、server、location定义了Nginx接收HTTP包体的内存缓冲区大小。也就是说，HTTP包体会先接收到指定的这块缓存中，之后才决定是否写入磁盘。如果用户请求中含有HTTP头部Content-Length，并且其标识的长度小于定义的buffer大小，那么Nginx会自动降低本次请求所使用的内存buffer，以降低内存消耗。
  1. client_body_temp_path dir-path[level1[level2[level3]]]（默认 client_body_temp_path client_body_temp;）http、server、location定义HTTP包体存放的临时目录。在接收HTTP包体时，如果包体的大小大于client_body_buffer_size，则会以一个递增的整数命名并存放到client_body_temp_path指定的目录中。后面跟着的level1、level2、level3，是为了防止一个目录下的文件数量太多，从而导致性能下降，因此使用了level参数，这样可以按照临时文件名最多再加三层目录。
  1. connection_pool_size size;（默认 connection_pool_size 256）Nginx 对于每个建立成功的 TCP 连接会预先分配一个内存池，size 指定内存池的初始大小，用于减少内核对于小块内存的分配次数。需要谨慎设置，因为更大的 size 会使服务器消耗的内存增多，而更小的 size 会引发更多的内存分配次数。
  1. request_pool_size size;（默认 request_pool_size 4k;）http、serverNginx 开始处理 HTTP 请求时将会为每个请求都分配一个内存池，size 指定内存池的初始大小，用于减少内核对于小块内存的分配次数。TCP 连接关闭时会销毁 connection_pool_size 指定的连接内存池，HTTP 请求结束时会销毁 request_pool_size 指定的请求内存池，但它们的创建、销毁时间并不一致。（因为一个 TCP 连接可能被复用于多个 HTTP 请求）
网络连接的设置
  1. client_header_timeout time（client_header_timeout 60;）http、server、location读取HTTP头部的超时时间。客户端与服务器建立连接后将开始接收HTTP头部，在这个过程中，如果在一个时间间隔（超时时间）内没有读取到客户端发来的字节，则认为超时，并向客户端返回408("Request timed out")响应。
  1. client_body_timeout time（ client_body_timeout 60;）http、server、location读取HTTP包体的超时时间。此配置项与client_header_timeout相似，只是这个超时时间只在读取HTTP包体时才有效。
  1. send_timeout time（send_timeout 60;）http、server、location发送响应的超时时间。这个超时时间是发送响应的超时时间，即Nginx服务器向客户端发送了数据包，但客户端一直没有去接收这个数据包。如果某个连接超过send_timeout定义的超时时间，那么Nginx将会关闭这个连接。
  1. reset_timeout_connection on|off;（reset_timeout_connection off;）连接超时后将通过向客户端发送RST包来直接重置连接。这个选项打开后，Nginx会在某个连接超时后，不是使用正常情形下的四次握手关闭TCP连接，而是直接向用户发送RST重置包，不再等待用户的应答，直接释放Nginx服务器上关于这个套接字使用的所有缓存（如TCP滑动窗口）。相比正常的关闭方式，它使得服务器避免产生许多处于FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT状态的TCP连接。注意，使用RST重置包关闭连接会带来一些问题，默认情况下不会开启。
  1. lingering_close off|on|always;（lingering_close on;）http、server、location该配置控制Nginx关闭用户连接的方式。always表示关闭用户连接前必须无条件地处理连接上所有用户发送的数据。off表示关闭连接时完全不管连接上是否已经有准备就绪的来自用户的数据。on是中间值，一般情况下在关闭连接前都会处理连接上的用户发送的数据，除了有些情况下在业务上认定这之后的数据是不必要的。
  1. lingering_time（lingering_time 30s;）http、server、locationlingering_close启用后，这个配置项对于上传大文件很有用。上文讲过，当用户请求的Content-Length大于max_client_body_size配置时，Nginx服务会立刻向用户发送413（Request entity too large）响应。但是，很多客户端可能不管413返回值，仍然持续不断地上传HTTP body，这时，经过了lingering_time设置的时间后，Nginx将不管用户是否仍在上传，都会把连接关闭掉。
  1. lingering_timeout（ lingering_timeout 5s;）http、server、locationlingering_close生效后，在关闭连接前，会检测是否有用户发送的数据到达服务器，如果超过lingering_timeout时间后还没有数据可读，就直接关闭连接；否则，必须在读取完连接缓冲区上的数据并丢弃掉后才会关闭连接。
  1. keepalive_timeout time（keepalive_timeout 75;）http、server、location一个keepalive连接在闲置超过一定时间后（默认的是75秒），服务器和浏览器都会去关闭这个连接。当然，keepalive_timeout配置项是用来约束Nginx服务器的，Nginx也会按照规范把这个时间传给浏览器，但每个浏览器对待keepalive的策略有可能是不同的。
  1. keepalive_requests n;（keepalive_requests 100;）一个keepalive连接上默认最多只能发送100个请求。
    MIME类型的设置
    1. type{…};http、server、location定义MIME type到文件扩展名的映射。多个扩展名可以映射到同一个MIME type。
    1. default_type MIME-type;（default_type text/plain;）http、server、location当找不到相应的MIME type与文件扩展名之间的映射时，使用默认的MIME type作为HTTP header中的Content-Type。
    1. types_hash_bucket_size
    1. types_hash_max_size
    对客户端请求的限制
    1. limit_except method…{…}locationNginx通过limit_except后面指定的方法名来限制用户请求。方法名可取值包括：GET、HEAD、POST、PUT、DELETE、MKCOL、COPY、MOVE、OPTIONS、PROPFIND、PROPPATCH、LOCK、UNLOCK或者PATCH。
    1. client_max_body_size size;（client_max_body_size 1m;）http、server、location浏览器在发送含有较大HTTP包体的请求时，其头部会有一个Content-Length字段，client_max_body_size是用来限制Content-Length所示值的大小的。因此，这个限制包体的配置非常有用处，因为不用等Nginx接收完所有的HTTP包体——这有可能消耗很长时间——就可以告诉用户请求过大不被接受。例如，用户试图上传一个10GB的文件，Nginx在收完包头后，发现Content-Length超过client_max_body_size定义的值，就直接发送413("RequestEntity Too Large")响应给客户端。
    1. limit_rate speed;（limit_rate 0;）http、server、location、if此配置是对客户端请求限制每秒传输的字节数。speed可以使用2.2.4节中提到的多种单位，默认参数为0，表示不限速。针对不同的客户端，可以用$limit_rate参数执行不同的限速策略。
    1. limit_rate_after time;（limit_rate_after 1m;）http、server、location、if此配置表示Nginx向客户端发送的响应长度超过limit_rate_after后才开始限速。
    文件操作的优化
    1. sendfile on|off;（sendfile off;）http、server、location可以启用Linux上的sendfile系统调用来发送文件，它减少了内核态与用户态之间的两次内存复制，这样就会从磁盘中读取文件后直接在内核态发送到网卡设备，提高了发送文件的效率。
    1. aio on|off;（aio off;）http、server、location此配置项表示是否在FreeBSD或Linux系统上启用内核级别的异步文件I/O功能。注意，它与sendfile功能是互斥的。
    1. directio size|off;
    1. directio_alignment
    1. open_file_cache max=N[inactive=time]|off;（off）http、server、location打开文件缓存
    1. open_file_cache_errors on|off;（off）此配置项表示是否在文件缓存中缓存打开文件时出现的找不到路径、没有权限等错误信息。
    对客户端请求的特殊处理
    1. ignore_invalid_headers on|off;（on）忽略不合法的HTTP头部如果将其设置为off，那么当出现不合法的HTTP头部时，Nginx会拒绝服务，并直接向用户发送400（Bad Request）错误。如果将其设置为on，则会忽略此HTTP头部。
    1. underscores_in_headers on|off;（off）HTTP头部是否允许下划线。默认为off，表示HTTP头部的名称中不允许带“_”（下划线）。
    1. if_modified_since[off|exact|before];（exact）http、server、location出于性能考虑，Web 浏览器一般会在客户端本地缓存一些文件，并存储获取时间。这样，下次向 Web 服务器获取缓存过的资源时，就可以使用 If-Modified-Since 头部把上次获取的时间捎带上，而 if_modified_since 将根据参数决定如何处理该头部：off：表示忽略用户请求中的If-Modified-Since头部。这时，如果获取一个文件，那么会正常地返回文件内容。HTTP响应码通常是200。exact：将If-Modified-Since头部包含的时间与将要返回的文件上次修改的时间做精确比较，如果没有匹配上，则返回200和文件的实际内容，如果匹配上，则表示浏览器缓存的文件内容已经是最新的了，没有必要再返回文件从而浪费时间与带宽了，这时会返回304 Not Modified，浏览器收到后会直接读取自己的本地缓存。before：是比exact更宽松的比较。只要文件的上次修改时间等于或者早于用户请求中的If-Modified-Since头部的时间，就会向客户端返回304 NotModified。
    1. log_not_found on|off;（on）文件未找到时是否记录到error日志。
    1. resolver address…;设置DNS名字解析服务器的地址。
    1. resolver_timeout time;（30）表示DNS解析的超时时间。
    1. server_tokens on|off;（on）返回错误页面时是否在Server中注明Nginx版本。

    2.5 HTTP proxy module 配置反向代理服务器

    反向代理方式（reverse proxy）是指用代理服务器接受 Internet 的连接请求，然后将请求转发给内部网络中的上游服务器（upstream），并将从上游服务器上取得的结果返回给请求连接的客户端，反向代理服务器必须能够处理大量并发请求。
    Nginx 具有高并发高负载能力，一方面可以作为前端的服务器直接向客户端提供静态文件服务，另一方面在面对复杂多变的业务时可以转发动态请求到 Apache、Tomcat 等服务器来处理。于是 Nginx 通常会被配置为既是静态 Web 服务器，也是反向代理服务器，不适合 Nginx 处理的请求就会被直接转发到上游服务器进行处理。
    与其他反向代理服务器相比，Nginx 有自己的特点：
    当客户端发来 HTTP 请求时，Nginx 并不会立刻转发到上游服务器，而是先把用户请求完整接受到 Nginx 所在服务器的硬盘或者内存，然后再向上游服务器发起连接，把缓存的客户端请求转发到上游服务器。而 Squid 等 dialing 服务器则采用一边接受客户端请求，一边转发到上游服务器的方式。
    Squid 等反向代理服务器在与客户端建立连接且还没有开始接受 HTTP 包体时就已经向上游服务器建立连接。上游服务器在接受完整 HTTP 包体的漫长过程中要始终维持这个链接，这直接对上游服务器的并发能力提出挑战。
    Nginx 则不然，它在接收到完整请求，才会与上游服务器建立连接并转发请求，由于是内网，这个转发过程会执行得很快。这样一个客户端请求占用上游服务器的连接时间就会非常短，也就是说，Nginx 的这种反向代理方案主要是为了降低上游服务器的并发压力。
    优点是降低上游服务器负载，缺点是延长请求处理时间并增加开销（用于缓存请求内容的内存和磁盘空间）
    负载均衡基本配置
    作为代理服务器，一般都需要向上游服务器的集群转发请求。这里的负载均衡是指选择一种策略，尽量把请求平均地分布到每一台上游服务器上。
    1. upstream name{…}httpupstream块定义了一个上游服务器的集群，便于反向代理中的proxy_pass使用。
    1. server name[parameters];upstreamserver配置项指定了一台上游服务器的名字，这个名字可以是域名、IP地址端口、UNIX句柄等，在其后还可以跟下列参数。weight=number：设置向这台上游服务器转发的权重，默认为1。max_fails=number：该选项与fail_timeout配合使用，指在fail_timeout时间段内，如果向当前的上游服务器转发失败次数超过number，则认为在当前的fail_timeout时间段内这台上游服务器不可用。max_fails默认为1，如果设置为0，则表示不检查失败次数。fail_timeout=time：fail_timeout表示该时间段内转发失败多少次后就认为上游服务器暂时不可用，用于优化反向代理功能。它与向上游服务器建立连接的超时时间、读取上游服务器的响应超时时间等完全无关。fail_timeout默认为10秒。down：表示所在的上游服务器永久下线，只在使用ip_hash配置项时才有用。backup：在使用ip_hash配置项时它是无效的。它表示所在的上游服务器只是备份服务器，只有在所有的非备份上游服务器都失效后，才会向所在的上游服务器转发请求。
    1. ip_hashupstream在有些场景下，我们可能会希望来自某一个用户的请求始终落到固定的一台上游服务器中。ip_hash就是用以解决上述问题的，它首先根据客户端的IP地址计算出一个key，将key按照upstream集群里的上游服务器数量进行取模，然后以取模后的结果把请求转发到相应的上游服务器中。这样就确保了同一个客户端的请求只会转发到指定的上游服务器中。ip_hash与weight（权重）配置不可同时使用。如果 upstream 集群中有一台上游服务器暂时不可用，不能直接删除该配置，而是要 down 参数标识，确保转发策略的一贯性。
    反向代理基本配置
    1. proxy_pass URL;location、if此配置项将当前请求反向代理到URL参数指定的服务器上，URL可以是主机名或IP地址加端口的形式，也可以是 UNIX 句柄，还可以直接使用 upstream 块。
    1. proxy_method method;http、server、location此配置项表示转发时的协议方法名。例如设置为：proxy_method POST;那么客户端发来的GET请求在转发时方法名也会改为POST。
    1. proxy_hide_header the_header & proxy_pass_headerhttp、server、locationNginx会将上游服务器的响应转发给客户端，但默认不会转发以下HTTP头部字段：Date、Server、X-Pad和X-Accel-*。使用proxy_hide_header后可以任意地指定哪些HTTP头部字段不能被转发。与proxy_hide_header功能相反，proxy_pass_header会将原来禁止转发的header设置为允许转发。
    1. proxy_pass_request_body on|off;（on）http、server、location作用为确定是否向上游服务器发送HTTP包体部分。
    1. proxy_pass_request_headers on|off;（on）http、server、location作用为确定是否转发HTTP头部。
    1. proxy_redirect[default|off|redirect replacement];（default）http、server、location当上游服务器返回的响应是重定向或刷新请求（如HTTP响应码是301或者302）时，proxy_redirect可以重设HTTP头部的location或refresh字段。例如，如果上游服务器发出的响应是302重定向请求，location字段的URI是http://localhost:8000/two/some/uri/ ，那么在下面的配置情况下，实际转发给客户端的location是http://frontend/one/some/uri/ 。
    1. proxy_next_upstream[error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off];（proxy_next_upstream error timeout;）http、server、location此配置项表示当向一台上游服务器转发请求出现错误时，继续换一台上游服务器处理这个请求。前面已经说过，上游服务器一旦开始发送应答，Nginx反向代理服务器会立刻把应答包转发给客户端。因此，一旦Nginx开始向客户端发送响应包，之后的过程中若出现错误也是不允许换下一台上游服务器继续处理的。这很好理解，这样才可以更好地保证客户端只收到来自一个上游服务器的应答。proxy_next_upstream的参数用来说明在哪些情况下会继续选择下一台上游服务器转发请求。

    Nginx 模块

    wait

    Nginx 原理

    Nginx 基础架构

    Web 服务器设计中的关键约束

    Nginx作为Web服务器受制于Web传输协议自身的约束，另外，下面将说明的7个关注点也是Nginx架构设计中的关键约束。
    1. 性能
      1. 网络性能
      2. 单次请求延迟
      3. 网络效率
    1. 可伸缩性
    1. 简单性
    1. 可修改性
    1. 可见性
    1. 可移植性
    1. 可靠性

    Nginx 架构设计

    模块化设计

    事件驱动架构

    _事件驱动__：一些事件发生源产生事件，由一个或者多个事件收集器来收集、分发事件，许多时间处理器会注册自己感兴趣的时间，同时消费这些事件。_
    _对于__传统 Web 服务器__而言，采用的事件驱动局限在 TCP 连接建立、关闭事件上，一个连接建立以后，在其关闭之前的所有操作都不是事件驱动，此时退化成按序执行每个操作的批处理模式，这样每个请求在连接建立后都将始终占用系统资源，直到连接关闭才会释放，这造成服务器资源的浪费。
    对于 Nginx __而言，它不会使用进程或者线程作为事件消费者，事件消费者只能是某个模块。只有事件收集、分发器才有资格占用进程资源，它们会在分发某个事件时调用事件消费模块使用当前占用资源。_
    前者是每个事件消费者独占一个进程资源，后者的事件消费者只是被事件分发者进程短期调用。
    这样的设计使得网络性能、用户感知的请求时延都得到提升，整个服务器的网络吞吐量都会由于事件的基石响应而增大。但也带来一个问题：每个事件消费者都不能有阻塞行为，否则将会由于长时间占用事件分发者进程而导致其他事件得不到及时响应。
    对于 Nginx 而言，一般由网卡、磁盘产生事件。事件模块负责事件的手机、分发操作。其他所有模块都可能是时间消费者，它们需要先向事件模块注册感兴趣的事件类型。

    多阶段异步处理请求

    多阶段异步处理请求给予事件驱动架构实现。
    所谓多阶段，即一个请求的处理过程按照事件的触发方式划分为多个阶段，每个阶段可以由事件收集、分发器来触发。
    至于异步则表现为当一个事件被分发到事件消费者中进行处理，事件消费者处理完这个事件相当于处理完请求的某个阶段，然后等待下次事件出现的时候，epoll 等事件分发器获取通知，继续调用事件消费者处理请求，这样每个阶段中的事件消费者都只能异步被动的等待通知。
    这种设计配合配合事件驱动架构，将会提升网络性能，同时使得每个进程全力运转（尽量少地出现进程休眠）。
    基于请求处理流程中的阻塞方法划分阶段。
    • _将阻塞进程的方法按照相关的触发事件分解成两个阶段。 __阻塞方法改为非阻塞方法调用，这个调用非阻塞方法并将进程归还给事件分发器的阶段就是第一阶段。 __增加新的处理阶段用于处理非阻塞方法最终返回的结果，这里的结果返回事件就是第二阶段的触发事件。_
    • 将阻塞方法调用按照时间分解为多个阶段的方法调用。
    • 进程空转时，使用定时器划分阶段。
    • 如果阻塞方法完全无法继续划分，则必须使用独立的进程执行这个阻塞方法。

    管理进程、多工作进程设计

    2.1 master-worker
    事件和进程的关系
    事件循环：每个工作进程都有自己的事件循环（event loop）。事件循环是事件驱动架构的核心，它不断检查是否有新的事件发生，并根据事件类型调用相应的处理函数。
    事件循环通常使用高效的 I/O 多路复用技术（如 epoll、kqueue、select 等）来管理多个文件描述符的 I/O 事件。进程间协作：虽然每个工作进程都有自己的事件循环，但它们共享同一个监听套接字（listening socket）。这意味着所有的工作进程都可以接收新的连接请求。当一个新的连接请求到达时，Nginx 会使用某种策略（如轮询、最少连接数等）将请求分配给某个工作进程。一旦某个工作进程接受了连接请求，该连接的所有后续 I/O 操作都由这个工作进程处理，直到连接关闭。
    负载均衡：通过多个工作进程，Nginx 可以在多核 CPU 上并行处理请求，从而实现负载均衡。每个工作进程独立运行，减少了进程间的同步开销，提高了系统的整体性能。

    平台无关的代码实现

    在使用C语言实现Nginx时，尽量减少使用与操作系统平台相关的代码，如某个操作系统上的第三方库。Nginx重新封装了日志、各种基本数据结构（如第7章中介绍的容器）、常用算法等工具软件，在核心代码都使用了与操作系统无关的代码实现，在与操作系统相关的系统调用上则分别针对各个操作系统都有独立的实现，这最终造就了Nginx的可移植性，实现了对主流操作系统的支持。

    内存池设计

    Nginx 设计简单的内存池。
    它通常不负责回收内存池中已经分配出的内存，它的优点在于把多次向系统申请内存的操作整合成一次，减少 CPU 资源消耗和内存碎片。
    因此，通常每一个请求都有一个独立的线程池，在请求结束的时候销毁整个内存池，把曾经分配的内存一次性归还给操作系统。
    这种设计他提高了模块开发的简单性，分配内存次数的减少使得请求时延降低，同时，通过减少内存碎片，提高了内存的有效利用率和系统可处理的并发连接数。

    核心结构体 ngx_cycle_t

    Nginx 启动时框架处理流程

    1. 根据命令行得到配置文件路径。
    1. 如果处于升级，则监听环境变量中传递的监听句柄。
    1. 调用所有核心模块的 create.conf 方法生成存放配置项的结构体。
    1. 调用配置模块解析的配置项方法。 遍历所有配置项，对于任一个配置项，将会检查所有核心模块以找出对他感兴趣的模块，并调用该模块在 ngx_command_t 结构体中定义的配置项处理方法。
    1. 调用所有核心模块的 init_conf 方法。 这一步骤的目的在于让所有核心模块在解析完配置项后可以做综合性处理。
    1. 创建目录、打开文件、初始化共享内存等进程间通信方式。
    1. 打开各个模块从配置文件中读取到的监听端口并监听端口。
    1. 调用所有模块的 init_module 方法。
    1. 如果配置为 single 工作模式。
      1. 则调用 ngx_single_process_cycle 方法进入单进程工作模式。
      2. 调用所有模块的 init_process 方法，单进程工作模式启动完成。
    1. 如果配置为 master、worker 工作模式。
      1. 在启动worker子进程、cache manage子进程、cache loader子进程后，master进程启动流程执行完毕。
      2. 由 master 进程按照配置文件中 worker 进程的数目，启动子进程。调用所有模块的 init_process 方法，worker 进程的启动工作完成，进入正常的循环处理事件流程。
      3. 由 master 进程根据之前各模块的初始化情况决定是否启动 cache manager 子进程或者 cache loader 子进程。

    事件模块

    事件处理框架概述
    事件处理框架要解决的问题是如何收集、管理、分发事件。
    事件主要以网络事件和定时器事件为主，而网络事件又以 TCP 网络事件为主。
    由于网络事件与网卡中断处理程序、内核提供的系统调用密切相关，所以网络事件驱动取决于不同的操作系统平台以及操作系统内核版本。（通常事件驱动机制也被叫做 I/O 多路复用），所以事件框架需要在不同的操作系统内核中选择一种事件驱动机制支持网络事件的处理。（Nginx 定义了一系列运行在不同操作系统、不同内核版本上的事件驱动模块，在 ngx_event_core_module 模块初始的过程选择）

    epoll 事件驱动模块

    epoll 原理

    采用红黑树管理事件，并通过回调实现事件通知，以达到事件触发后被收集到特定数据结构（rdlist），epoll 只需要遍历 rdlist 就可以实现同时监控并处理大量 fd。
    epoll_create： 创建 epoll 对象，每一个 epoll 对象都有一个独立的 eventepoll 结构体（主要是红黑树和双向列表）。
    结构体会在内核空间中创建独立内存，用于存储 epoll_ctl 向 epoll 对象添加的事件，这些事件都会被挂到 rbr 红黑树。_
    在 epoll 中每一个事件都会建立 epitem 结构体，这里包含每个事件的信息，红黑树中每个节点都是基于 epitem 结构中的 rbn 成员。
    所有添加到 epoll 对象的事件都会与设备驱动程序建立回调关系，事件发生时会调用回调方法（epoll_callback），然后事件会添加到 rdlist 中。
    epoll_ctl 向 epoll 对象中添加、修改、删除事件时，从 rbr 红黑树中查找事件非常快。
    epoll_wait 检查是否有发生事件的连接时，只是检查 eventpoll 对象中 rdlist 是否存在 epitem 元素，存在则复制事件到用户态内存，同时返回事件数量给用户。

    epoll 使用

    epoll 有 LT 模式（水平触发）和 ET 模式（边缘触发）两种工作模式。
    默认情况下，epoll 使用水平触发模式，这时可以处理阻塞和非阻塞套接字。边缘触发模式的效率要更高，但是只支持非阻塞套接字。
    二者区别在：
    ET 模式下 epoll_wait 只在文件描述符状态发生变化时返回，比如从不可读变为可读。这意味着如果应用程序这次没有处理完所有数据，即使文件描述符仍然处于可读状态， epoll_wait 不会再返回该文件描述符，直至下次状态改变。
    LT模式则相反，只要一个事件对应的套接字缓冲区还有数据，就总能从 epoll_wait中获取这个事件。
    实际意义：
    在 LT 模式下如果一个文件描述符长时间保持可读状态，那可能会导致频繁的 epoll_wait 唤醒，从而增加 CPU 开销，而在 ET 模式下，只有当状态真正改变时才会被唤醒，有助于减少 CPU 负载。

    ngx_epoll_module 模块实现

    定时器事件

    在网络事件中，网络事件的触发是由内核完成的，内核如果支持epoll就可以使用ngx_epoll_module模块驱动事件，内核如果仅支持select那就得使用ngx_select_module模块驱动事件；定时器事件则完全是由Nginx自身实现的，它与内核完全无关。
    ]]>         <![CDATA[Tomcat]]> https://nowave.cloud//article/1f7beb96-1d72-8044-addc-f85c299ae670 https://nowave.cloud//article/1f7beb96-1d72-8044-addc-f85c299ae670 Sun, 18 May 2025 00:00:00 GMT
    Tomcat 可以视作 HTTP解析器 + Servlet容器。
    主要作用是屏蔽应用层协议和网络通信细节，将网络数据流转换为 Servlet Request 和 Servlet Response 对象。
    notion image
    简单描述 Tomcat 的结构。
    Tomcat Server 对应 Service，Service 中包含 Connector 和 Container。
    对于不同类型的网络连接，Tomcat 使用不同的 Connector 处理并输出到唯一的 Container。

    Connector：HTTP 解析器

    notion image
    主要职责是网络通信、应用层协议解析、对象转换。

    ProtocolHandler

    Endpoint
    Endpoint 负责网络通信，其本身是接口。
    AbstractEndpoint 实现 Endpoint 并规范行为，NioEndpoint 具体实现逻辑。
    notion image
    NioEndpoint 中涉及的组件有 LimitLatch、Acceptor、Poller 和 Executor。
    1. LimitLatch 控制最大连接数。
    1. Acceptor 监听 Socket 连接请求，独立线程。 死循环调用 accept() 接收新连接。
    1. Poller
    1. Executor
    Processor

    Adapter

     
    ]]>         <![CDATA[Kakfa]]> https://nowave.cloud//article/1f7beb96-1d72-801c-a0f7-fbc800be34fc https://nowave.cloud//article/1f7beb96-1d72-801c-a0f7-fbc800be34fc Sun, 18 May 2025 00:00:00 GMT

    Intro

    distributed event streaming platform
    as meaaage queue or as stream processing system
    Kafka 擅长提供高性能、可扩展性和耐用性。他旨在实时处理大量数据，不会丢失任何信息，并且尽可能快速地处理每条数据。

    Basic Terminology and Architecture

    1. Broker
    A Kafka cluster is made up of multiple brokers.These are just individual servers (physical or virtual)
    1. Partition
    Each Broker has a number of partitions.
    Each partition is an ordered, immutable sequence of messages that is continually appended to.
    Partitions are the way Kafka scales as they allow for sth. for meaagaed to be consumed in parallel.
    Each partition in Kafka functions essentially as an append-only log file. Messages are sequentially added to the end of this log, which is why Kafka is commonly described as a distributed commit log. This append-only design is central to Kafka’s architecture, providing several important benefits:
    1. Immutability: Once written, messages in a partition cannot be altered or deleted. This immutability is crucial for Kafka’s performance and reliability. It simplifies replication, speeds up recovery processes, and avoids consistency issues common in systems where data can be changed.
    1. Efficiency: By restricting operations to appending data at the end of the log, Kafka minimizes disk seek times, which are a major bottleneck in many storage systems.
    1. Scalability: The simplicity of the append-only log mechanism facilitates horizontal scaling. More partitions can be added and distributed across a cluster of brokers to handle increasing loads, and each partition can be replicated across multiple brokers to enhance fault tolerance.
    Each message in a Kafka partition is assigned a unique offset, which is a sequential identifier indicating the message’s position in the partition.
    This offset is used by consumers to track their progress in reading messages from the topic. As consumers read messages, they maintain their current offset and periodically commit this offset back to Kafka. This way, they can resume reading from where they left off in case of failure or restart.
    1. Topic
    A logical grouping of partitions.
    Topics are the way you publish and subscrible to data in Kafka.
    Topics are always multi-producer; that is, a topic can have zero, one, or many producers that write data to it.
    The difference between a topic and a partition
    A topic is a logical grouping of messages.
    A partition is a physical grouping of messages.
    A topic can have multiple partitions, and each partition can be on a different broker.
    Topics are just a way to organize your data, while partitions are a way to scale your data.
    1. Producers and Consumers
    Producers are the ones who write data to topics, and consumers are the ones who read data from topics. While Kafka exposes a simple API for both producers and consumers, the creation and processing of messages is on you, the developer. Kafka doesn't care what the data is, it just stores and serves it.
    Importantly, you can use Kafka as either a message queue or a stream. Frankly, the distinction here is minor. The only meaningful difference is with how consumers interact with the data. In a message queue, consumers read messages from the queue and then acknowledge that they have processed the message. In a stream, consumers read messages from the stream and then process them, but they don't acknowledge that they have processed the message. This allows for more complex processing of the data.

    How Kafka Works

    1. When an event occurs, the producer formats a message, also referred to as a record, and sends it to a Kafka topic. A message consists of one required field, the value, and three optional fields: a key, a timestamp, and headers. The key is used to determine which partition the message is sent to, and the timestamp is used to order messages within a partition. Headers, like HTTP headers, are key-value pairs that can be used to store metadata about the message.
    1. When a message is published to a Kafka topic, Kafka first determines the appropriate partition for the message. This partition selection is critical because it influences the distribution of data across the cluster. This is a two-step process:
    1. Partition DeterminationKafka uses a partitioning algorithm that hashes the message key to assign the message to a specific partition. If the message does not have a key, Kafka can either round-robin the message to partitions or follow another partitioning logic defined in the producer configuration. This ensures that messages with the same key always go to the same partition, preserving order at the partition level.
    1. Broker AssignmentOnce the partition is determined, Kafka then identifies which broker holds that particular partition. The mapping of partitions to specific brokers is managed by the Kafka cluster metadata, which is maintained by the Kafka controller (a role within the broker cluster). The producer uses this metadata to send the message directly to the broker that hosts the target partition.
    1. Once a message is published to the designated partition, Kafka ensures its durability and availability through a robust replication mechanism. Kafka employs a leader-follower model for replication, which works as follows:Replic 是 Kafka 为了确保数据的可靠性和可用性为每个分区创建的副本，这些副本分布在不同的 broker 上，以防止单点故障。
    1. Leader Replica AssignmentEach partition has a designated leader replica, which resides on a broker. This leader replica is responsible for handling all read and write requests for the partition. The assignment of the leader replica is managed centrally by the cluster controller, which ensures that each partition’s leader replica is effectively distributed across the cluster to balance the load.
    1. Follower Replication:Alongside the leader replica, several follower replicas exist for each partition, residing on different brokers. These followers do not handle direct client requests; instead, they passively replicate the data from the leader replica. By replicating the messages received by the leader replica, these followers act as backups, ready to take over should the leader replica fail.
    1. Synchronization and ConsistencyFollowers continuously sync with the leader replica to ensure they have the latest set of messages appended to the partition log. This synchronization is crucial for maintaining consistency across the cluster. If the leader replica fails, one of the follower replicas that has been fully synced can be quickly promoted to be the new leader, minimizing downtime and data loss.
    1. Controller's Role in ReplicationThe controller within the Kafka cluster manages this replication process. It monitors the health of all brokers and manages the leadership and replication dynamics. When a broker fails, the controller reassigns the leader role to one of the in-sync follower replicas to ensure continued availability of the partition.
    1. Last up, consumers read messages from Kafka topics. They can read messages in two ways: either by subscribing to a topic and receiving messages as they arrive (this is called a push model), or by polling Kafka for new messages at regular intervals (this is called a pull model).

    When to use Kafka

    Kafka can be use as either a message queue or a stream.
    The key difference between the two lies in how consumers interact with the data. In a message queue, consumers typically pull messages from the queue when they are ready to process them. In a stream, consumers continuously consume and process messages as they arrive in real-time, similar to drinking from a flowing river.
    Consider adding a message queue to your system when:
    • You have processing that can be done asynchronously.YouTube is a good example of this. When user upload a video we can make the standard definition video available immediately and then put the video a Kafka topic to be transcoded when the system has time.
    • You need to ensure that messages are processed in order.
    • You want to decouple the producer and consumer so that they can scale independently. Usually this means that the producer is producing messages faster than the consumer can consume them. This is a common pattern in microservices where you want to ensure that one service can't take down another.
    Streams are useful when:
    • You require continuous and immediate processing of incoming data, treating it as a real-time flow. See Design an Ad Click Aggregator for an example where we aggregate click data in real-time.
    • Messages need to be processed by multiple consumers simultaneously. In Design FB Live Comments we can use Kafka as a pub/sub system to send comments to multiple consumers.

    Kafka For System Design

    Scalability

    Let's start by understanding the constraints of a single Kafka broker. It's important in your interview to estimate the throughput and number of messages you'll be storing in order to determine whether we need to worry about scaling in the first place.
    First, there is no hard limit on the size of a Kafka message as this can be configured via message.max.bytes. However, it is recommended to keep messages under 1MB to ensure optimal performance via reduced memory pressure and better network utilization.
    On good hardware, a single broker can store around 1TB of data and handle around 10,000 messages per second (this is very hand wavy as it depends on message size and hardware specs, but is a useful estimate). If your design does not require more than this, than scaling is likely not a relevant conversation.
    It's a common anti-pattern in system design interviews to store large blobs of data in Kafka. Kafka is not a database, and it's not meant to store large files. It's meant to store small messages that can be processed quickly.
    For example, when designing YouTube, we need to perform post-processing on videos after uploading to chunk and transcode them. Naively, you might place the videos in Kafka so that the chunk/transcoding worker can pull them off the queue asynchronously and process them. This is not a good idea. Instead, you should store the videos in a distributed file system like S3 and place a message in Kafka with the location of the video in S3. This way, the Kafka message is small and serves as a pointer to the full video in S3.
    In the case that you do need to scale, you have a couple strategies at your disposal:
    • Horizontal Scaling With More BrokersThe simplest way to scale Kafka is by adding more brokers to the cluster. This helps distribute the load and offers greater fault tolerance. Each broker can handle a portion of the traffic, increasing the overall capacity of the system. It's really important that when adding brokers you ensure that your topics have sufficient partitions to take advantage of the additional brokers. More partitions allow more parallelism and better load distribution. If you are under partitioned, you won't be able to take advantage of these newly added brokers.
    • Partitioning StrategyThis should be the main focus of your scaling strategy in an interview and is the main decision you make when dealing with Kafka clusters (since much of the scaling happens dynamically in managed services nowadays). You need to decide how to partition your data across the brokers. This is done by choosing a key for your messages since the partition is determined by a consistent hashing algorithm on the key. If you choose a bad key, you can end up with hot partitions that are overwhelmed with traffic. Good keys are ones that are evenly distributed across the partition space.
    When working with Kafka, you're usually thinking about scaling topics rather than the entire cluster. This is because different topics can have different requirements. For example, you may have a topic that is very high throughput and needs to be partitioned across many brokers, while another topic is low throughput and can be handled by a single broker. To scale a topic, you can increase the number of partitions, which will allow you to take advantage of more brokers.
    How can we handle hot partitions?
    Consider an Ad Click Aggregator where Kafka stores a stream of click events from when users click on ads. Naturally, you would start by partitioning by ad id. But when Nike launches their new Lebron James ad, you better believe that partition is going to be overwhelmed with traffic and you'll have a hot partition on your hands.
    There are a few strategies to handle hot partitions:
    • Random partitioning with no keyIf you don't provide a key, Kafka will randomly assign a partition to the message, guaranteeing even distribution. The downside is that you lose the ability to guarantee order of messages. If this is not important to your design, then this is a good option.
    • Random saltingWe can add a random number or timestamp to the ad ID when generating the partition key. This can help in distributing the load more evenly across multiple partitions, though it may complicate aggregation logic later on the consumer side. This is often referred to as "salting" the key.
    • Use a compound keyInstead of using just the ad ID, use a combination of ad ID and another attribute, such as geographical region or user ID segments, to form a compound key. This approach helps in distributing traffic more evenly and is particularly useful if you can identify attributes that vary independently of the ad ID.
    • Back pressureDepending on your requirements, one easy solution is to just slow down the producer. If you're using a managed Kafka service, they may have built-in mechanisms to handle this. If you're running your own Kafka cluster, you can implement back pressure by having the producer check the lag on the partition and slow down if it's too high.

    Fault Tolerance and Durability

    Kafka ensures data durability through its replication mechanism. Each partition is replicated across multiple brokers, with one broker acting as the leader and others as followers. When a producer sends a message, it is written to the leader and then replicated to the followers. This ensures that even if a broker fails, the data remains available. Producer acknowledgments (acks setting) play a crucial role here. Setting acks=all ensures that the message is acknowledged only when all replicas have received it, guaranteeing maximum durability.
    Producer acknowledgments (acks setting)
    • No Acknowledgment (acks=0)在这种模式下，生产者发送消息后不会等待任何确认。这意味着消息一旦发送出去，生产者就认为它已经被成功提交。这种方法效率最高，但也最不安全，因为如果Broker在消息被持久化之前发生故障，消息可能会丢失。
    • All Brokers Acknowledgment (acks=1)在这种模式下，生产者发送的消息只需要被Leader接收并写入其本地日志即可认为成功。Leader不会等待Follower的确认。这种方法比acks=0更可靠，但仍存在一定的风险，因为在Follower完成同步之前，Leader可能已经崩溃。
    • Full Acknowledgment (acks=all 或 acks=-1)在这种模式下，生产者发送的消息必须被Leader以及所有Follower接收并持久化后，生产者才会收到确认。这是最安全的方式，因为只有当整个Replica集都保存了消息后，才认为消息已成功提交。不过，这也意味着生产者的性能会受到最慢Follower的影响。
    Depending on how much durability you need, you can configure the replication factor of your topics. The replication factor is the number of replicas that are maintained for each partition. A replication factor of 3 is common, meaning that each partition has 2 replicas. So if one broker fails, the data is still available on the other two and we can promote a follower to be the new leader.
    But what happens when a consumer goes down?
    What is far more relevant and likely is that a consumer goes down. When a consumer fails, Kafka's fault tolerance mechanisms help ensure continuity:
    • Offset ManagementRemember that partitions are just append-only logs where each message is assigned a unique offset. Consumers commit their offsets to Kafka after they process a message. This is the consumers way of saying, "I've processed this message." When a consumer restarts, it reads its last committed offset from Kafka and resumes processing from there, ensuring no messages are missed or duplicated.
    • RebalancingWhen part of a consumer group, if one consumer goes down, Kafka will redistribute the partitions among the remaining consumers so that all partitions are still being processed.

    Handling Retries and Errors

    While Kafka itself handles most of the reliability (as we saw above), our system may fail getting messages into and out of Kafka. We need to handle these scenarios gracefully.

    Producer Retries

    First up, we may fail to get a message to Kafka in the first place. Errors can occur due to network issues, broker unavailability, or transient failures. To handle these scenarios gracefully, Kafka producers support automatic retries.

    Consumer Retries

    On the consumer side, we may fail to process a message for any number of reasons. Kafka does not actually support retries for consumers out of the box (but AWS SQS does!) so we need to implement our own retry logic. One common pattern is to set up a custom topic that we can move failed messages to and then have a separate consumer that processes these messages. This way, we can retry messages as many times as we want without affecting the main consumer. If a given message is retried too many times, we can move it to a dead letter queue (DLQ). DLQs are just a place to store failed messages so that we can investigate them later.

    Performance Optimizations

    Especially when using Kafka as an event stream, we need to be mindful of performance so that we can process messages as quickly as possible.
    This first thing we can do is batch messages in the producer before sending them to Kafka.
    Another common way to improve throughput is by compressing the messages on the producer. This can be done by setting the compression option in the producer configuration. Kafka supports several compression algorithms, including GZIP, Snappy, and LZ4. Essentially, we're just making the messages smaller so that they can be sent faster.
    Arguably the biggest impact you can have to performance comes back to your choice of partition key. The goal is to maximize parallelism by ensuring that messages are evenly distributed across partitions. In your interview, discussing the partition strategy, as we go into above, should just about always be where you start.

    Retention Policies

    Kafka topics have a retention policy that determines how long messages are retained in the log. This is configured via the retention.ms and retention.bytes settings. The default retention policy is to keep messages for 7 days or until the log reaches 1GB, whichever comes first.

    Summary

    通过阅读 Kafka Deep Dive for System Design Interviews (hellointerview.com) 我对 Kafka 有了一个非实战的理论的基础了解。
    下一步需要阅读 Kafka 中文文档 - ApacheCN 中设计、实现和操作部分来加深对 Kafka 的了解。
    同样也可以试着在开发环境中使用 Kafka。
    如何在Java中使用Kafka-阿里云开发者社区 (aliyun.com)
    超详细的Kafka教程-从部署到开发到原理都有讲解-腾讯云开发者社区-腾讯云 (tencent.com)
    学习 Kafka 入门知识看这一篇就够了！（万字长文）-腾讯云开发者社区-腾讯云 (tencent.com)
    ]]>