SQL Server整体架构——实例

Posted 2023-04-05 lhdz_bj

所谓整体架构，这里是指SQL Server数据库系统正常工作和运行所必备的组件及其机制。整体上来讲，这主要包括实例（Instance）和数据库（Database）。在此基础上再进一步划分，实例由服务器上的相关内存区域和服务线程组成；数据库包括操作系统上的各种相关文件。上述相关内存区域、服务线程及文件又可再进一步细分。下面就按照这个顺序和逻辑，逐步讲解SQL Server数据库系统的整体架构。 1.  实例

实例，即数据库实例，由服务器上的一组内存结构和线程（因为SQL Server for Windows为线程模型，另外，因本书基于SQL Server 2012+ for Windows创作编写，通篇将其统称为SQL Server，不再赘述）组成，用以支撑和完成数据库的正常运行和操作，其主要包括以下组件。

窥探Tomcat整体架构，server.xml常用配置解析

首发CSDN：徐同学呀，原创不易，转载请注明源链接。我是徐同学，用心输出高质量文章，希望对你有所帮助。

文章目录

• • 一、前言
  • • server.xml配置示例
  • 二、Tomcat运行实例Server
  • • 1、生命周期监听器
    • • （1）VersionLoggerListener
      • （2）AprLifecycleListener
      • （3）JreMemoryLeakPreventionListener
      • （4）GlobalResourcesLifecycleListener
      • （5）ThreadLocalLeakPreventionListener
      • （6）NamingContextListener
    • 2、GlobalNamingResources
    • 3、监听SHUTDOWN命令
    • 4、定时触发自动部署周期性事件
  • 三、服务抽象Service
  • • 1、共享线程池Executor
    • 2、连接器Connector
    • 3、容器引擎Engine
    • 4、URI映射器Mapper
  • 四、虚拟主机Host
  • • Host部署web应用
  • 五、Web应用Context
  • • Resources配置
  • 六、Servlet包装器Wrapper
  • 七、要点总结

一、前言

server.xml 配置，是 Tomcat启动配置，从配置结构可以看出 Tomcat 的整体架构。如果能够了解其常用配置项，对 Tomcat有一个高屋建瓴的把握，然后再庖丁解牛，一步步深入源码中分析每一个核心功能的实现细节，这样会有事半功倍的效果。

server.xml配置示例

1. 如上图 server.xml 配置，最外层是一个 Server，代表 Tomcat的运行实例。Server 里有一些监听器 Listener，一个不知道干啥的 GlobalNamingResources，还有一个 Service，通过阅读源码，发现一个 Server 里可以有多个 Service。
2. Service可以理解为是对部署在Tomcat里的服务的抽象，一个Tomcat可以部署多个服务，但是我更喜欢把一个Service理解成一个服务集合或者集群。
3. Service里有一个 Executor、Connector 和 Engine。Executor是一个线程池，可以供 Contector使用；Connector 定义了协议连接（HTTP/AJP），外界就是通过Connector访问Service里的服务的；Engine是容器引擎，可以理解它为Servlet容器，真正的业务处理在Engine里。通过阅读源码，一个Service可以有多个Executor，多个Connector，一个Engine。如果把Service比作一个房子，Connector比作门，一个房子可以有多个门就好理解了。
4. Engine内部较复杂，它内部就像俄罗斯套娃，有多个子容器，子容器下又可以有多个子容器。正如Engine的英文含义，引擎，驱动和管理内部子容器。因为是最顶端的管理者，会包含一些组件辅助管理子容器。Engine可以有多个Host容器，可以理解为虚拟主机（URL地址中主机部分抽象）；Host容器里有多个Context容器，Context就是一个个Web应用；Context容器里有多个Wrapper容器，server.xml中一般不用配置，Wrapper是对Servlet的包装，就是一个个业务功能了。
5. 如果对应上Service房子的比喻，Engine可以比作房子里所有房间的总和，或者是通向每个房间的走道，Host就是一个个房间，房间里有一些家具家电（Context），每一个家具家电有很多功能（Wrapper）。

二、Tomcat运行实例Server

Server是Tomcat运行实例的抽象，管理着内部多个服务。在Tomcat源码中Server的默认标准实现是org.apache.catalina.core.StandardServer：

• 默认有6个生命周期监听器，监听Server不同运行阶段的事件并作出响应。
• GlobalNamingResources全局命名资源，通过JNDI提供统一的命名对象访问接口。
• Server监听了一个端口，默认8005，如果这个端口传来SHUTDOWN指令，则关闭Tomcat。
• Server还有两个定时任务，监听触发一些在Tomcat整个生命周期里周期性事件，暂时只有自动部署。

1、生命周期监听器

（1）VersionLoggerListener

org.apache.catalina.startup.VersionLoggerListener监听初始化阶段，输出一些运行日志，如操作系统、JDK、Tomcat版本信息以及catalina.base、catalina.home的定义等。

（2）AprLifecycleListener

Tomcat可以使用APR本地库从操作系统级别解决异步IO问题，通过JNI方式调用APR本地库大幅提高对静态资源的处理性能。org.apache.catalina.core.AprLifecycleListener对初始化前的事件和销毁后的事件感兴趣：

• 在Tomcat初始化前，AprLifecycleListener尝试初始化APR库，如果初始化成功，则使用APR接收并处理客户端的请求。
• 在Tomcat销毁后，AprLifecycleListener会对APR做一些销毁终止操作。

（3）JreMemoryLeakPreventionListener

org.apache.catalina.core.JreMemoryLeakPreventionListener监听器会在Tomcat初始化时使用系统类加载器预先加载一些JRE的类和设置URLConnection缓存禁用属性，以避免线程上下文类加载器是Tomcat自定义的Webappclassloader时，加载JRE导致的内存泄漏和URLConnection缓存导致的锁文件问题。

（4）GlobalResourcesLifecycleListener

org.apache.catalina.mbeans.GlobalResourcesLifecycleListener会在Tomcat启动时为JNDI创建MBean，停止时销毁MBean。

（5）ThreadLocalLeakPreventionListener

org.apache.catalina.core.ThreadLocalLeakPreventionListener监听器监听Context停止后，销毁连接器Connector中Executor的所有核心工作线程，并重新创建，以避免使用ThreadLocal带来的内存泄漏。

（6）NamingContextListener

org.apache.catalina.core.NamingContextListener监听器在Tomcat启动时创建并绑定全局命名资源，在Tomcat停止前做一些解绑全局命名资源、反注册销毁等操作。

2、GlobalNamingResources

GlobalNamingResources全局命名资源，通过JNDI提供统一的命名对象访问接口。而JNDI（Java Naming and Directory Interface）是一个比较老旧的技术，在历史遗留的企业级应用中可能还在用，诸如获取一个数据库连接资源、自定义配置等，这种强耦合在启动配置文件里的方式已经不适用现在轻量级的应用和分布式服务了。（后续可以单独研究下，这里了解即可。）

3、监听SHUTDOWN命令

Tomcat启动时，主线程做完所有启动工作后，会进入循环等待SHUTDOWN的状态。如果接收到SHUTDOWN，结束循环调用Tomcat停止销毁接口。

实现方式很简单，单独给主线程建立一个socket连接，时刻监听某个端口（默认8005），是否发来SHUTDOWN命令。

4、定时触发自动部署周期性事件

Server启动时，会开启两个定时任务，一个是每10秒触发一次自动部署事件，而这个定时任务可能会因为自动部署的检查和部署过程中出现异常导致该定时任务停止，所以就有了另一个定时任务每1分钟检查一次自动部署定时任务是否有在正常运行，没有就重新设置。（自动部署是Host的工作，在Host的生命周期监听器HostConfig中监听执行）

三、服务抽象Service

Service默认标准实现是org.apache.catalina.core.StandardService，如果在Server中配置了多个Service，name必须唯一，不可重复。

Service包含的组件有Executor、Connector、Engine，还有一个Mapper组件没有在配置中体现，一般也不需要配置。

1、共享线程池Executor

Service中可以定义一些线程池，供Connector和其他组件使用。Tomcat没有另起炉灶实现自己的线程池，而是在JUC的ThreadPoolExecutor基础上做了定制化改造，默认标准实现是org.apache.catalina.core.StandardThreadExecutor。

Executor可配置项如下：

配置项	备注	默认值
name	线程池名称，必须唯一，供其他组件直接引用
className	Executor的实现类名称	org.apache.catalina.core.StandardThreadExecutor
namePrefix	指定线程池中线程的名称前缀。	tomcat-exec-
maxThreads	最大线程数	200
minSpareThreads	核心线程数	25
threadPriority	工作线程优先级别	NORM_PRIORITY（5）
daemon	工作线程是否为守护线程	true
maxIdleTime	非核心工作线程空闲时存活时间	60000ms
prestartminSpareThreads	是否在启动Executor时创建核心工作线程	false
maxQueueSize	任务队列最大容量	Integer.MAX_VALUE
threadRenewalDelay	Context停止时，会销毁重建工作线程，为避免同一时间重建所有线程，该参数指定任意两个线程之间的创建延迟时间	1000ms

注意：

如果指定Executor的实现是StandardThreadExecutor，那么prestartminSpareThreads无论是true还是false，都会预先创建minSpareThreads个核心工作线程。

2、连接器Connector

Connector是Service的门户，一个Service可以有多个Connector。Connector定义了多种连接协议，配置较为复杂，现仅提供常见配置说明：

配置项	备注	默认
executor	引用Executor的名称，如果为空，则会自己新建一个私有的线程池使用。
port	服务端socket监听的端口号，用于等待请求连接，如果设置为0，则会随机分配一个可用端口。
protocol	协议，可以填HTTP/1.1或AJP/1.3，也可以填具体的协议实现类如org.apache.coyote.http11.Http11NioProtocol或org.apache.coyote.ajp.AjpNioProtocol等	HTTP/1.1
connectionTimeout	接收连接等待超时时间，-1表示不超时。	60000ms
acceptCount	当所有请求处理线程都被占用时，socket等待请求队列的最大长度。	100
redirectPort	非SSL请求重定向到指定SSL端口。	443
URIEncoding	URI解析编码	UTF-8
maxPostSize	post请求的最大字节数，0或者负数则没有限制	2 * 1024 * 1024（2MB）
maxHttpHeaderSize	HTTP消息头的最大字节数	8 * 1024
maxConnections	服务端接收处理的最大连接数，是设置给LimitLatch限流器的，如果超过该值，则会阻塞等待，此时依然会接收连接，但是不能超过acceptCount，否则拒绝连接。	8*1024

注意：

Tomcat10.0.6中NioEndpoint已经不能配置Poller线程和acceptor线程的个数，默认都是一个，同时AprEndpoint也标注为不建议使用，所以关于APR的配置也可以不用深入了解。后面会详细研究Connector的内部实现，到时讲解其他与源码相关的配置项。

3、容器引擎Engine

Engine是Servlet容器最顶端的管理者，负责处理对应Service中所有请求，包含多个Host和其他组件。默认标准实现是org.apache.catalina.core.StandardEngine。Engine以及其子容器都继承自ContainerBase，都有些相似的组件，如AccessLog、Pipeline、Cluster、Realm、Log、LifecycleListener、ContainerListener等。

Engine、Host、Context都有一个同名前缀的LifecycleListener，如Engine的是EngineConfig，Host的是HostConfig，Context是ContextConfig，分别监听自己感兴趣的生命周期事件，如EngineConfig就是在Engine启动停止时输出一些日志。

对于Engine节点可选配置有如下几个：

配置项	备注	默认
name	engine的名称，用于日志输出，必须唯一。
defaultHost	默认Host名称，当请求找不到Host时，就用该默认Host
backgroundProcessorDelay	后台线程处理延迟时间。	10s
startStopThreads	用于启动和停止子容器的线程数	1

注意：

• Engine即其子容器Host、Context、Wrapper都可以设置backgroundProcessorDelay这个参数，都可以有自己的后台线程来延迟backgroundProcessorDelay时长周期性处理一些事情。如果backgroundProcessorDelay<=0则不会创建私有的后台线程，默认Engine中这个参数是10，其他子容器是-1，所以一般情况子容器需要后台处理的事情，都交由Engine启动的后台线程周期性延迟处理。
• 上层容器启动停止下层容器时，会用一个线程池来做异步处理。

4、URI映射器Mapper

Service中Mapper组件主要提供给Connector和Context使用，Connector中处理完连接后需要将请求信息交给对应的Host处理，可以通过Mapper的解析找到Host；Context通过Mapper找到对应的Servlet（Wrapper）处理业务。

Mapper还有一个对应的生命周期监听器MapperListener，其主要监听容器启动后，将容器注册到Mapper的关系中，建立一个树状结构。容器停止后做一些销毁、反注册操作。

（详细的Mapper原理后面会单独出文章讲解）

四、虚拟主机Host

Host是Engine的子容器，默认标准实现是org.apache.catalina.core.StandardHost。它的主要职责就是管理和部署子容器Context，比如，Host启动前，预先创建好部署web应用的目录；Host启动时，部署web应用；Host运行过程中，周期性检查web应用是否需要自动部署，这些监听工作都是在HostConfig中做的。

如下是Host的一些常用配置：

配置项	备注	默认
name	Host名称，必须要有一个Host名称与Engine的defaultHost对应。
appBase	web应用基础目录，可以是绝对路径，也可以是相对路径（相对于CATALINA_BASE）	webapps
unpackWARs	Context启动时是否将appBase目录下的war包解压。	true
autoDeploy	开启热部署，即在Tomcat运行阶段，定期检查和自动部署appBase和xmlBase目录下有无新增或者更新的web应用。	true
createDirs	若设置为true，Host在启动时预先创建好appBase和xmlBase目录。	true
backgroundProcessorDelay	后台线程处理延迟时间。一般不需要配置，直接用Engine的后台线程。	-1
workDir	Host下web应用的临时目录。每个web应用都有自己的临时目录，如果Context中设置了workDir，则Host中的配置会被覆盖。web应用中的Servlet将通过ServletContext的jakarta.servlet.context.tempdir属性访问workDir。	%CATALINA_BASE%/work/[EngineName]/[HostName]/ContextName
deployOnStartup	若设置为true，Host在启动时自动部署web应用。	true
xmlBase	XML基础目录，即context描述文件方式部署的路径，可以是绝对路径，也可以是相对路径（相对于CATALINA_BASE）。	%CATALINA_BASE%/conf/[EngineName]/[HostName]/

Host部署web应用

Host部署web应用（Context）的三种方式：

• Context描述文件部署，默认是%CATALINA_BASE%/conf/[EngineName]/[HostName]/目录下，可以有多个Context配置，后缀必须为.xml。可以通过xmlBase指定Context配置文件存放目录。
• WAR包部署，即将web应用打包成一个.war部署，默认放在%CATALINA_BASE%/webapps目录下，可以通过appBase指定一个绝对路径。
• 目录部署，默认也是放在%CATALINA_HOME%/webapps目录下。

三种部署的过程都是解析实例化Context，而后两者web应用可能有自己的META-INF/context.xml，则通过解析它来组装生成Context，否则就解析全局的%CATALINA_BASE%/conf/context.xml。

五、Web应用Context

Context是对Web应用的抽象，相对其他容器有很多组件，且结构上复杂很多。默认标准实现是org.apache.catalina.core.StandardContext，其主要的职责有：

• Wrapper管理，Context下有很多Wrapper，Wrapper是对Servlet的包装抽象，是最小的容器。
• 错误页面ErrorPage管理，在web.xml里可以配置请求处理过程中发生异常重定向的页面路由。
• 会话Session管理。
• Jar包扫描和加载，一个Context有一个自定义类加载，扫描和加载/WEB-INF/lib下的jar包。
• 热加载，定期检查/WEB-INF/lib和/WEB-INF/classes目录下的.jar和.class文件是否更新，更新了就重新加载。热加载过程较消耗资源，仅适用于开发环境，不可用于生产环境。
• ServletContainerInitializer的初始化。
• 除了生命周期监听器外，还有很多其他监听器。
• 实例管理。
• 静态资源缓存管理。

Context常用配置如下

配置项	备注	默认
path	web应用路径，同一个Host下必须唯一。如果path为空字符串，意味着为当前Host指定了默认web应用，该应用会处理根路径下的所有请求。这个属性只有在server.xml里配置Context有用，单独的Context配置文件里不会生效，会通过context文件名或docBase生成path。
reloadable	若设置为true，则开启热加载，即后台线程会定期检查/WEB-INF/lib和/WEB-INF/classes目录下的.jar和.class文件是否更新，如果更新，则重加载。	false
docBase	web应用目录或者war包部署路径。可以是绝对路径，也可以是相对路径（相对于Host的appBase）。
workDir	web应用的临时目录，如果配置了，会覆盖Host中配置的workDir。
backgroundProcessorDelay	后台线程处理延迟时间。一般不需要配置，直接用Engine的后台线程。	-1

Resources配置

Resources是对静态资源的抽象，可以设置缓存以提高响应性能。默认标准实现是org.apache.catalina.webresources.StandardRoot。

配置项	备注	默认
cacheMaxSize	静态资源缓存最大值	10MB
cacheObjectMaxSize	单体静态资源最大值	512KB
cacheTtl	缓存失效时间	5000ms
cachingAllowed	是否使用缓存	true

StandardRoot中有五种WebResourceSet：preResources、mainResources、classResources、jarResources、postResources，支持的配置如下：

配置项	备注	默认
base	资源的位置，用于指定文件、目录或者jar包的绝对路径。
webAppMount	当前资源挂载的web应用内部路径，如果添加一个jar包目录，可以将其挂载在/WEB-INF/lib下，必须“/”开头。	/
className	资源实现类。可选实现类有：org.apache.catalina.webresources.DirResourceSet，org.apache.catalina.webresources.JarResourceSet，org.apache.catalina.webresources.FileResourceSet
internalPath	资源的内部路径，通常用于jar内文件的加载。必须“/”开头。	/
readOnly	资源是否可读，如果设置为true，资源将不会删除、创建、修改。	false

六、Servlet包装器Wrapper

Wrapper相对于Engine、Host、Context是最小的容器，其父容器必须是Context，没有其他子容器。默认标准实现是org.apache.catalina.core.StandardWrapper。一般情况一个Servlet对应一个Wrapper，这就是为什么Servlet不是线程安全的了，Servlet以单例的实现存在，多个线程访问肯定不是线程安全的，虽然有Servlet对象池的选择，但是Tomcat10.0.6已经不建议这样做。

七、要点总结

本篇只对server.xml常用的配置进行解释，并通过配置文件节点关系，大概梳理了Tomcat整体架构。

Tomcat是一个非常优秀的开源项目，值得揉碎了仔细研究的细节实在太多，比如：

• 线程池定制化改造；
• 连接Connector的设计以及如何连接到容器Engine的；
• Mapper组件如何解析映射URI；
• 一个请求的处理和响应过程；
• 生命周期框架的设计；
• 自定义类加载器加载机制，如何做到隔离和共享，如何打破双亲委派；
• 热部署，热加载的实现细节；
• 如何解析server.xml配置；
• 部署web应用的细节；
• 容器之间如何做到有序连接，Pipeline和Valve的实现细节；
• Servlet如何实现双向过滤；
• 各种监听器
• 等等

后续会一个个详细解读，敬请期待。

非常感谢以下两本书：

• 《Tomcat内核设计剖析》汪建著
• 《Tomcat架构解析》刘光瑞著
• 参考源码Tomcat10.0.6和Tomcat8.5.9

Tomcat源码详细注释链接（非推广，持续更新）：https://gitee.com/stefanpy/tomcat-source-code-learning

如若文章有错误理解，欢迎批评指正，同时非常期待你的评论、点赞和收藏。