一、中介者模式概述（一）生活场景引出中介者模式在大学班级场景中，如果没有类似QQ这样的通讯工具，班长或团支书传达消息以及同学之间交流就会呈现出一种复杂的网状结构。随着同学数量增多，这种网状结构会变得更加混乱，对象之间存在大量联系，耦合性极高，不利于复用和系统扩展。例如，新转来一个学生，可能需要改动很多地方来适应这种复杂的联系。
（二）中介者模式的定义与作用中介者模式（Mediator Pattern）定义一个中介对象来封装系列对象之间的交互。中介者使各个对象不需要显式地相互引用，从而使其耦合性松散，而且可以独立地改变它们之间的交互。就像引入QQ群后，班级同学之间的交流变为星形结构，每个学生对象不再直接耦合，而是通过QQ群（中介者）进行交流。（配图：展示班级同学交流从网状结构变为星形结构的示意图，突出QQ群作为中介者的作用）
（三）中介者模式的结构
角色构成
抽象中介者（Mediator）：定义了同事对象到中介者对象的接口，一般包含添加同事对象、通知同事对象等方法。例如，在代码中抽象中介者类有add_student（添加学生）、notify（通知）和chart（交流）等方法，为具体中介者 ...
设计模式
未读一、设计模式的分类与设计原则设计模式总体分为三大类：创建型模式（5种）、结构型模式（7种）和行为模式（11种）。在深入了解各种设计模式之前，先明确一下设计所遵循的原则，主要包括单一职责、开放封闭原则 - OCP（功能开放，代码闭合）、里氏替换原则（子类型能够替换掉父类型，松耦合）以及接口隔离原则 - ISP（不能出现胖接口，应该打散dao，多定义子接口）。这些原则为设计模式的合理运用提供了指导方针，确保软件系统具备良好的可维护性、扩展性和灵活性。
（一）创建型模式
单例模式（Singleton）
特征描述：
构造函数必须声明为私有，防止外部直接实例化该类。
类中声明静态常量，用于保存类的惟一实例。
为客户提供一个静态的方法，该方法能够返回惟一实例。
应用场景：
当类只能有一个实例且客户可从一个众所周知的访问点访问它时，例如在一些全局配置类中，整个系统只需要一个配置实例来保证配置的一致性。
当这个惟一实例应通过子类化可扩展，且客户无需更改代码就能使用扩展实例时，如在数据库连接池的实现中，单例模式可以确保在整个应用中只有一个连接池实例，同时可以根据不同的数据库类型进行子类扩展 ...
minitomcat
未读功能目标：
支持热部署（Hot Deployment）功能，能够在不重启服务器的情况下加载新的 Web 应用。
监控应用目录的变化，当检测到新的 Web 应用时，自动加载该应用的 Servlet 和资源。
支持 web.xml 的重新加载和应用更新。
实现内容：
实现一个 目录监控机制，当检测到应用目录中的变化（如新增应用、修改或删除文件）时，自动加载或卸载应用。
支持 web.xml 文件的重新加载，使得配置更新后能自动生效。
提供一个简单的 文件监控线程，持续检测应用目录中的变化，并在变化发生时触发相关的加载或卸载操作。
15.1 热部署的设计热部署的关键是动态地检测文件系统的变化，并自动加载或卸载 Web 应用。为此，我们可以借助 Java NIO 提供的 WatchService，实现对应用目录中文件的监控。
15.1.1 设计思路
文件监控：使用 WatchService 监控应用目录中的文件变化。包括新增、修改或删除操作。
自动加载应用：当监控到新的应用目录或文件发生变化时，自动加载或更新应用的 Servlet 和配置。
重新加载配置：当 web.xm ...
minitomcat
未读功能目标：
实现 Log 模块，支持日志记录和日志级别管理。
实现内容：
Log 模块：实现一个日志组件，用于记录请求日志、错误日志和系统日志。
日志级别：支持不同的日志级别（INFO、DEBUG、ERROR 等），以便控制日志的详细程度。
实现方式：设计一个简单的 Logger 类，提供不同级别的日志输出，并配置输出格式和文件路径。
14.1 日志记录的重要性在 Web 应用开发中，日志记录是非常重要的。日志帮助我们跟踪系统的运行状态，诊断问题，并提供可用的监控信息。常见的日志类型包括：
请求日志：记录每个 HTTP 请求的相关信息。
错误日志：记录程序异常和错误信息。
系统日志：记录系统级别的信息，如服务启动、停止等事件。
为了更高效地记录日志，我们需要将日志分为不同的级别，并根据日志级别来输出不同的日志内容。
14.2 日志级别的设计常见的日志级别如下：
DEBUG：最详细的日志，用于调试阶段，记录系统的详细信息。
INFO：常规信息，记录系统的正常操作，如请求处理过程等。
WARN：警告信息，用于记录可能出现问题的地方，但不一定会导致错误。
ER ...
minitomcat
未读功能目标：
实现 Lifecycle 组件，用于统一管理各个组件的启动、停止等生命周期操作。
实现内容：
定义 Lifecycle 接口，提供 start 和 stop 方法，供容器中的 Context、Wrapper 等组件使用，方便容器统一管理不同组件的生命周期。
背景：在 Web 容器中，不同的组件（如 Servlet、Web 应用等）通常有明确的生命周期，从创建到销毁需要一系列的管理操作。为了简化对这些组件生命周期的管理，可以引入统一的生命周期管理机制。通过定义 Lifecycle 接口，容器能够统一控制组件的启动、停止，确保资源的正确初始化与销毁。
13.1 生命周期管理的设计思路我们首先需要定义一个 Lifecycle 接口，所有需要管理生命周期的组件（如 Context、Wrapper、Servlet）都可以实现该接口。该接口定义了两个基本方法：
start()：表示组件的启动操作。
stop()：表示组件的停止操作。
这些组件在容器中启动时，将通过调用 start() 方法进行初始化，停止时通过调用 stop() 方法释放资源。
13.2 定义 Life ...
功能目标：
使用 Facade 模式简化外部对 Servlet API 的访问，隐藏内部复杂的实现细节，提供更简洁的接口供外部调用。
实现内容：
Facade 模式：Facade 是一种设计模式，用于封装复杂的子系统。通过封装，Facade 提供了一个统一的接口，使得外部系统在不需要了解内部实现的情况下，依然能够轻松访问子系统的功能。
在 Servlet 容器中，我们可以通过 Facade 包装如 HttpServletRequest 和 HttpServletResponse 等对象，限制对内部结构的直接访问，简化对外接口的复杂度。
RequestFacade 和 ResponseFacade 类作为具体实现，它们封装了 HttpServletRequest 和 HttpServletResponse，隐藏了请求和响应的复杂细节，提供标准的请求和响应接口。
示例功能：
创建一个 RequestFacade 类，封装实际的请求对象，屏蔽不必要的内部细节，简化外部对请求的访问。
12.1 Facade 模式设计Facade 模式的关键是将复杂的子系统操作封装在一个简单的接口 ...
minitomcat
未读功能目标：
Wrapper：负责管理单个 Servlet 的生命周期，封装 Servlet 的创建、初始化、调用和销毁过程。
Context：用于管理 Web 应用的上下文，一个 Context 可以包含多个 Wrapper，每个 Wrapper 代表一个 Servlet。Context 负责加载和卸载整个 Web 应用，并维护应用的配置和生命周期。
实现内容：
Wrapper：每个 Wrapper 对象封装了一个特定的 Servlet 实例，负责该 Servlet 的生命周期管理。Wrapper 管理 Servlet 的初始化、销毁，并提供对 Servlet 的访问。
Context：Context 代表 Web 应用的上下文，它包含多个 Wrapper，每个 Wrapper 对应一个 Servlet。Context 管理 Web 应用的配置、生命周期以及 Servlet 的加载和卸载。
示例功能：
在 Context 中配置多个 Wrapper，每个 Wrapper 绑定到不同的 Servlet，支持多个 Servlet 在同一 Web 应用中共存。
11.1 Wr ...
minitomcat
未读功能目标：
实现 Valve 和 Pipeline 机制，允许在请求处理流程中插入额外的控制和功能扩展。
Valve：是一种过滤器链机制，可以在请求和响应过程中插入额外的处理逻辑。例如，可以实现权限控制、日志记录和请求过滤等功能。
Pipeline：负责管理多个 Valve 的执行顺序，每个请求都会按顺序通过 Pipeline 中的 Valve 执行操作。
实现内容：
定义 Valve 接口，让每个 Valve 实现特定的逻辑，并将 Valve 按顺序添加到 Pipeline 中。
Pipeline 是一个容器，管理多个 Valve 的执行顺序。
每个请求都将通过一系列的 Valve，允许灵活地扩展请求处理逻辑。
示例功能：
实现一个日志记录 Valve，记录每个请求的 URI 和执行时间，并将该 Valve 添加到 Pipeline 中。
10.1 Valve 接口的设计Valve 接口定义了一个处理请求和响应的标准接口。每个实现了 Valve 接口的类都可以在请求流中执行特定的功能。
12345678package com.daicy.minitomcat;im ...
请简单介绍一下你在 Netty 方面的项目经验我开发了一套基于Netty的web容器，Netty 在此项目中发挥了关键作用。首先，利用 Netty 的 ChannelPipeline 机制，我们精心设计了一系列的解码器和编码器，实现了对不同数据格式的高效处理。比如，对于二进制数据的快速反序列化和序列化操作，确保数据在传输过程中的准确性和完整性。
同时，通过添加自定义的过滤器，我们能够对数据进行实时的校验和封装，极大地提高了数据的安全性和可靠性。在项目中，Netty 的高性能异步非阻塞 I/O 模型使得我们能够轻松应对数以万计的并发连接，大大提升了系统的吞吐量和响应速度。例如，在一次压力测试中，系统在高并发场景下依然保持稳定，响应时间始终控制在极低的范围内。
此外，我们还利用 Netty 的可扩展性，根据项目的特定需求进行了定制化开发。比如，开发了一个专门的业务处理器，用于处理特定类型的业务逻辑，进一步提高了系统的灵活性和可维护性。Netty 的使用不仅解决了项目中的实际问题，还为未来的业务扩展奠定了坚实的基础。
请说说你在使用 Spring Boot 时，遇到过哪些挑战，以及 ...
请介绍一下你在 Java 开发中最有成就感的一个项目，并说明你在其中承担的角色和主要贡献。我在爱卡汽车网担任技术经理和架构师，负责广告部门的团队组建、架构设计以及重要模块开发。
这个项目极具挑战，因为公司原本技术栈以 PHP 为主，而我要将其转换为 Java，并从 0 到 1 搭建起完整的 Java 开发体系，包括开发、测试、发布和监控。
项目采用微服务架构，主要分为以下几个部分：
广告管理系统：带有前端，方便进行广告业务的管理。
广告搜索引擎：这是我自主开发的核心功能之一。基于先进的搜索引擎技术，能够快速准确地为用户提供相关广告内容，极大地提升了用户体验和广告投放效果。
投放效果统计：分为离线统计和在线统计，为广告主提供精准的数据反馈，帮助他们优化广告投放策略。
消息中间件：我基于 Redis 开发了高效的消息同步机制，确保广告商务广告系统录入的广告能够及时同步到广告搜索引擎等相关模块，保证数据的实时性和一致性。
还包括注册发现、配置中心、定时任务管理系统和外部开放平台等，为整个广告系统的稳定运行和拓展提供了有力支持。
作为技术负责人，我面临的主要挑战是缺乏广告业务知识 ...
