静态文件处理器

在现代 Web 开发中，静态资源的高效管理和分发对提升用户体验至关重要。TioBoot 作为一款高性能的 Java Web 框架，提供了内置的静态文件处理器 DefaultStaticResourceHandler，实现了 StaticResourceHandler 接口。然而，在某些复杂场景下，我们可能需要根据不同的域名加载不同目录下的静态文件。本文将深入探讨如何自定义 TioBoot 的静态文件处理器，实现基于域名的动态静态资源加载，并结合 Redis 实现高效的缓存机制。

背景与目标

在多租户系统或需要对资源进行域名隔离的场景中，我们希望：

• 根据不同的域名，从对应的目录中加载静态文件；
• 提高静态资源的加载效率，减少服务器的 I/O 负载；
• 实现缓存机制，进一步提升响应速度。

自定义静态文件处理器

设计思路

自定义的静态文件处理器需要解决以下问题：

1. 域名解析：从请求中获取域名信息，确定静态文件的存储目录。
2. 文件加载：根据域名和请求路径，加载对应的静态文件。
3. 缓存机制：引入缓存，减少磁盘读取，提高性能。
4. 响应构建：根据文件内容和请求头，构建适当的 HTTP 响应。

实现代码

以下是自定义静态文件处理器 MyStaticResourceHandler 的实现：

package com.litongjava.file.handler;

import java.io.File;

import com.litongjava.constatns.ServerConfigKeys;
import com.litongjava.tio.boot.http.handler.StaticResourceHandler;
import com.litongjava.tio.http.common.HeaderName;
import com.litongjava.tio.http.common.HeaderValue;
import com.litongjava.tio.http.common.HttpConfig;
import com.litongjava.tio.http.common.HttpRequest;
import com.litongjava.tio.http.common.HttpResource;
import com.litongjava.tio.http.common.HttpResponse;
import com.litongjava.tio.http.common.HttpResponseStatus;
import com.litongjava.tio.http.server.handler.FileCache;
import com.litongjava.tio.http.server.util.Resps;
import com.litongjava.tio.utils.cache.AbsCache;
import com.litongjava.tio.utils.environment.EnvUtils;
import com.litongjava.tio.utils.hutool.FileUtil;

import lombok.extern.slf4j.Slf4j;

@Slf4j
public class MyStaticResourceHandler implements StaticResourceHandler {
  private static final long MAX_CACHE_FILE_SIZE = 5 * 1024 * 1024; // 最大缓存大小5MB

  public HttpResponse handle(String path, HttpRequest request, HttpConfig httpConfig, AbsCache staticResCache) {
    boolean enable = EnvUtils.getBoolean(ServerConfigKeys.SERVER_RESOURCES_STATIC_FILE_CACHE_ENABLE, false);
    String host = request.getHost().replace(':', '_');
    String fileKey = host + path;

    HttpResponse response = null;
    FileCache fileCache = null;

    // 从缓存中获取FileCache
    if (enable && staticResCache != null) {
      fileCache = (FileCache) staticResCache.get(fileKey);
    }

    if (enable && fileCache != null) {
      long lastModified = fileCache.getLastModified();
      // 检查是否需要返回304
      response = Resps.try304(request, lastModified);
      if (response != null) {
        response.addHeader(HeaderName.tio_from_cache, HeaderValue.Tio_From_Cache.TRUE);
        return response;
      }

      // 构建HttpResponse
      response = new HttpResponse(request);
      response.setBody(fileCache.getContent());

      response.setLastModified(HeaderValue.from(String.valueOf(lastModified)));
      response.setHasGzipped(fileCache.isHasGzipped());

      // 设置必要的响应头
      if (fileCache.getContentType() != null) {
        response.addHeader(HeaderName.Content_Type, fileCache.getContentType());
      }
      if (fileCache.getContentEncoding() != null) {
        response.addHeader(HeaderName.Content_Encoding, fileCache.getContentEncoding());
      }
      return response;
    } else {
      String extension = FileUtil.extName(path);
      File file = new File(fileKey);
      if (!file.exists()) {
        //从默认配置中读取文件
        String pageRoot = httpConfig.getPageRoot(request);
        if (pageRoot != null) {
          HttpResource httpResource;
          try {
            httpResource = httpConfig.getResource(request, path);
          } catch (Exception e) {
            e.printStackTrace();
            return null;
          }
          if (httpResource != null) {
            file = httpResource.getFile();
          } else {
            return null;
          }
        } else {
          return null;
        }
      }
      // 文件存在,读取文件内容
      long fileLastModified = file.lastModified();
      byte[] content = FileUtil.readBytes(file);
      HeaderValue lastModified = HeaderValue.from(String.valueOf(fileLastModified));
      response = Resps.bytes(request, content, extension);
      response.setStaticRes(true);
      response.setLastModified(lastModified);

      // 缓存文件内容，如果文件大小小于最大缓存大小
      if (enable && response.isStaticRes() && staticResCache != null) {
        if (response.getBody() != null && response.getStatus() == HttpResponseStatus.C200) {
          if (content.length <= MAX_CACHE_FILE_SIZE) {
            HeaderValue contentType = response.getHeader(HeaderName.Content_Type);
            HeaderValue contentEncoding = response.getHeader(HeaderName.Content_Encoding);
            FileCache newFileCache = new FileCache(content, fileLastModified, contentType, contentEncoding, response.hasGzipped());
            staticResCache.put(fileKey, newFileCache);
            if (log.isInfoEnabled()) {
              log.info("add to cache:[{}], {}(B)", fileKey, content.length);
            }
          } else {
            log.info("File size exceeds cache limit, not cached: [{}], {}(B)", fileKey, content.length);
          }
        }
      }
    }
    return response;
  }
}

代码解析

• 域名处理：使用 request.getHost() 获取请求的主机名，替换其中的冒号为下划线，防止文件系统路径错误。
• 文件键生成：将主机名与请求路径拼接，形成唯一的文件键，便于文件定位和缓存。
• 缓存机制：
  • 检查缓存：如果启用了缓存，尝试从 staticResCache 中获取 FileCache 对象。
  • 缓存命中：如果缓存存在，检查文件的 Last-Modified，决定是否返回 304 Not Modified。
  • 缓存更新：如果缓存不存在或已过期，读取文件并更新缓存。
• 文件读取：
  • 直接读取：尝试根据文件键直接读取文件。
  • 默认路径：如果文件不存在，使用 httpConfig 获取默认的 pageRoot，从默认路径读取文件。
• 响应构建：根据读取的文件内容，设置响应体、状态码、头信息等。

配置自定义处理器到 TioBoot

要使自定义的静态文件处理器生效，需要将其配置到 TioBoot 中。在 TioBootServerConfig 类中进行如下设置：

import com.litongjava.annotation.AConfiguration;
import com.litongjava.annotation.Initialization;
import com.litongjava.file.handler.MyStaticResourceHandler;
import com.litongjava.tio.boot.server.TioBootServer;

@AConfiguration
public class TioBootServerConfig {

    @Initialization
    public void config() {
        // 设置自定义的静态资源处理器
        TioBootServer.me().setStaticResourceHandler(new MyStaticResourceHandler());
    }
}

使用 Redis 作为缓存存储

原因分析

• 高性能：Redis 作为内存数据库，具有高速的读写性能，适合缓存场景。
• 可扩展性：在分布式环境中，Redis 可以作为集中式的缓存存储，便于扩展和管理。

配置实现

package com.litongjava.file.config;

import com.litongjava.annotation.BeforeStartConfiguration;
import com.litongjava.annotation.Initialization;
import com.litongjava.tio.boot.server.TioBootServer;
import com.litongjava.tio.utils.cache.redismap.RedisMapCacheFactory;
import com.litongjava.tio.utils.environment.EnvUtils;

import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

@BeforeStartConfiguration
public class BeforeTioStartConfig {

    @Initialization
    public void config() {
        // 从环境变量获取 Redis 配置
        String host = EnvUtils.getStr("redis.host", "localhost");
        int port = EnvUtils.getInt("redis.port", 6379);
        int timeout = EnvUtils.getInt("redis.timeout", 2000);
        String password = EnvUtils.getStr("redis.password", null);
        int database = EnvUtils.getInt("redis.database", 0);

        // 创建 Jedis 连接池
        JedisPoolConfig poolConfig = new JedisPoolConfig();
        JedisPool jedisPool = new JedisPool(poolConfig, host, port, timeout, password, database);

        // 设置 RedisMapCacheFactory 的 Jedis 连接池
        RedisMapCacheFactory.INSTANCE.setJedisPool(jedisPool);

        // 注册销毁方法，确保应用关闭时连接池被正确关闭
        TioBootServer.me().addDestroyMethod(jedisPool::close);
    }
}

配置解析

• 环境变量读取：使用 EnvUtils 从环境变量或配置文件中读取 Redis 的连接信息，支持默认值。
• Jedis 连接池：配置连接池参数，提升 Redis 访问的性能和稳定性。
• 缓存工厂设置：将连接池设置到 RedisMapCacheFactory，使缓存数据存储在 Redis 中。
• 资源管理：在应用关闭时，调用 jedisPool.close()，确保连接池资源被正确释放。

配置文件（可选）

在 app.properties 或其他配置文件中，可以添加以下配置：

server.resources.static-locations=pages
server.resources.static.file.cache.enable=true

• server.resources.static-locations：指定静态资源的默认目录（可根据实际需求修改）。
• server.resources.static.file.cache.enable：启用静态文件缓存。

使用示例

完成上述配置后，当您访问 http://localhost:8123/channel_001/images/439681354499067904.png 时，服务器将从 localhost_8123 目录下加载对应的文件。这是因为自定义的处理器根据请求的主机名（localhost:8123）和请求路径，动态确定了文件的存储位置，实现了基于域名的资源隔离。

工作原理详解

1. 基于域名的资源隔离

• 核心思想：将请求的主机名作为静态文件目录的标识，结合请求路径，定位到具体的静态文件。
• 实现方式：在处理请求时，获取 Host 头，将其格式化后作为文件路径的一部分。

2. 缓存机制的实现

• 目的：减少磁盘 I/O，提高响应速度，降低服务器负载。
• 策略：
  • 缓存条件：文件大小小于设定的最大缓存大小（5MB）。
  • 缓存存储：使用 Redis 作为缓存存储，支持高并发访问。
  • 缓存校验：通过 Last-Modified 时间，判断缓存是否需要更新。
• 304 响应：如果文件未修改，返回 HTTP 304 Not Modified 状态码，减少数据传输。

3. Redis 的优势

• 高性能：内存存储，读写速度快。
• 持久化：支持数据持久化，防止数据丢失。
• 分布式支持：方便在集群环境中部署，扩展性强。

4. 动态资源加载流程

1. 接收请求：客户端请求静态资源，包含主机名和请求路径。
2. 处理请求：自定义处理器解析请求，生成文件键。
3. 检查缓存：查询 Redis 缓存，判断是否存在对应的文件内容。
   • 缓存命中：校验 Last-Modified，决定是否返回缓存内容或 304 状态码。
   • 缓存未命中：从文件系统读取文件。
4. 构建响应：根据文件内容和请求头，构建 HttpResponse 对象。
5. 返回响应：将响应发送给客户端，并根据需要更新缓存。

5. 资源管理与优化

• 连接池管理：使用 Jedis 连接池，优化 Redis 连接的创建和管理。
• 资源释放：在应用关闭时，确保所有资源（如连接池）被正确释放，防止资源泄漏。
• 日志记录：在关键操作处添加日志，方便调试和监控。

总结

通过自定义 TioBoot 的静态文件处理器，我们成功实现了基于域名的静态资源隔离和高效的缓存机制。这种设计适用于多租户系统、内容分发网络（CDN）等需要对资源进行域名隔离的场景。

利用 Redis 的高速缓存能力，我们大幅提升了静态资源的加载效率，改善了用户体验。同时，代码中充分考虑了可扩展性和可维护性，使用环境变量配置、连接池管理和日志记录等手段，确保系统的稳定运行。

建议与注意事项

• 环境配置：使用环境变量或配置文件管理系统参数，方便在不同环境下部署和维护。
• 安全性：在处理文件路径时，注意防范路径遍历等安全问题，确保服务器文件系统的安全。
• 性能优化：根据实际需求，调整缓存大小、连接池配置等参数，达到最佳性能。
• 监控与日志：建立完善的日志和监控机制，及时发现和处理潜在问题。