缓存网页数据
一、功能概述
在某些场景下,我们需要对网页内容进行批量爬取和分析。但如果每次访问浏览器都进行实时加载,会消耗较多的系统资源(例如启动浏览器加载时可能会占用 90M 以上的内存)。因此,本方案的设计思路是:将已爬取到的网页内容进行缓存,后续重复访问同一页面时直接使用缓存内容,达到减少资源消耗和爬取时延的目的。
本方案主要包含以下几个部分:
- 数据库表结构:用于存储网页缓存内容。
- PlaywrightService:利用 Playwright 库来抓取网页内容的核心服务类,具备异步并发以及本地缓存判定的功能。
- 缓存清理定时任务:定期清理历史缓存,防止数据库膨胀。
- 测试类:演示如何使用
PlaywrightService
进行多线程网页爬取并验证其功能。
二、数据库表
首先,需要创建一张名为 palywright_brower_web_page_cache
的表,用于存储网页的纯文本内容、HTML 内容和Markdown 内容(如果有需求),并同时保存一些元信息(如创建时间、URL 等)。
示例 SQL 建表语句如下:
drop table if exists palywright_brower_web_page_cache;
CREATE TABLE "public"."palywright_brower_web_page_cache" (
"id" BIGINT NOT NULL PRIMARY KEY,
"url" VARCHAR,
"text" text NOT NULL,
"html" text,
"markdown" text,
"remark" VARCHAR(256),
"creator" VARCHAR(64) DEFAULT '',
"create_time" TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updater" VARCHAR(64) DEFAULT '',
"update_time" TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
"deleted" SMALLINT DEFAULT 0,
"tenant_id" BIGINT NOT NULL DEFAULT 0
);
CREATE INDEX "palywright_brower_web_page_cache_url" ON "palywright_brower_web_page_cache" USING btree ("url" varchar_pattern_ops);
其中各字段含义如下:
- id:唯一标识,通常可使用雪花算法或自增主键。
- url:页面地址。
- text:爬取到的网页文本内容(
<body>
部分或其他需要的文字)。 - html:网页完整的 HTML 内容。
- markdown:可选的 Markdown 格式内容(若需要转换,可在业务逻辑中进行)。
- remark:预留备注字段。
- create_time/update_time:记录该条数据的创建和更新时间,默认为当前服务器时间。
- deleted:逻辑删除标记字段,0 表示未删除。
- tenant_id:可用于多租户场景;若无多租户需求,可忽略或默认为 0。
该表同时建立了一个基于 url
的索引,优化按照 URL 查询的性能。
三、PlaywrightService 爬取服务
添加依赖
爬取服务依赖于以下 Maven 依赖(示例):
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>31.1-jre</version>
</dependency>
<!-- 需要引入Playwright相关依赖,请根据自己项目的Playwright版本选择 -->
<dependency>
<groupId>com.microsoft.playwright</groupId>
<artifactId>playwright</artifactId>
<version>1.32.0</version>
</dependency>
注:Playwright 需要在运行环境中安装特定浏览器内核,具体可参阅官方文档进行安装。
PlaywrightService
下面是核心的 PlaywrightService
类示例:
package com.litongjava.perplexica.services;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.Future;
import java.util.concurrent.locks.Lock;
import com.google.common.util.concurrent.Striped;
import com.litongjava.db.activerecord.Db;
import com.litongjava.db.activerecord.Row;
import com.litongjava.perplexica.instance.PlaywrightBrowser;
import com.litongjava.searxng.WebPageConteont;
import com.litongjava.tio.utils.hutool.FilenameUtils;
import com.litongjava.tio.utils.hutool.StrUtil;
import com.litongjava.tio.utils.snowflake.SnowflakeIdUtils;
import com.litongjava.tio.utils.thread.TioThreadUtils;
import com.microsoft.playwright.BrowserContext;
import com.microsoft.playwright.Page;
import lombok.extern.slf4j.Slf4j;
/**
* PlaywrightService 负责爬取网页并将结果缓存至数据库。
*/
@Slf4j
public class PlaywrightService {
// 数据表名称
public static final String cache_table_name = "palywright_brower_web_page_cache";
/**
* 批量异步抓取网页内容
*
* @param pages 包含url的WebPageConteont列表
* @return 返回同一个列表,但其中的content属性已被填充或保持为空
*/
public List<WebPageConteont> spiderAsync(List<WebPageConteont> pages) {
List<Future<String>> futures = new ArrayList<>();
// 为每个页面启动一个异步任务
for (int i = 0; i < pages.size(); i++) {
String link = pages.get(i).getUrl();
Future<String> future = TioThreadUtils.submit(() -> {
// 若后缀为pdf等其他非网页格式,直接跳过
String suffix = FilenameUtils.getSuffix(link);
if ("pdf".equalsIgnoreCase(suffix)) {
log.info("skip: {}", link);
return null;
} else {
// 爬取并返回文本内容
return getPageContent(link);
}
});
futures.add(i, future);
}
// 等待所有任务执行完成,并将结果填充回pages
for (int i = 0; i < pages.size(); i++) {
Future<String> future = futures.get(i);
try {
String result = future.get();
if (StrUtil.isNotBlank(result)) {
pages.get(i).setContent(result);
}
} catch (InterruptedException | ExecutionException e) {
log.error("Error retrieving task result: {}", e.getMessage(), e);
}
}
return pages;
}
// 使用Guava的Striped锁,设置64个锁段
private static final Striped<Lock> stripedLocks = Striped.lock(64);
/**
* 通过URL获取页面内容;若数据库有缓存则直接返回,否则利用Playwright实际爬取并写入缓存。
*
* @param link 要抓取的URL
* @return 页面文本内容
*/
private String getPageContent(String link) {
// 先检查数据库缓存
if (Db.exists(cache_table_name, "url", link)) {
// 此处可以读取 text 或 html 等字段
return Db.queryStr("SELECT text FROM " + cache_table_name + " WHERE url = ?", link);
}
// 使用Striped锁,为每个URL生成一把独立的锁,避免并发重复爬取
Lock lock = stripedLocks.get(link);
lock.lock();
try {
// 双重检查,防止其他线程已在获取锁后写入
if (Db.exists(cache_table_name, "url", link)) {
return Db.queryStr("SELECT text FROM " + cache_table_name + " WHERE url = ?", link);
}
// 使用 PlaywrightBrowser 获取context对象,执行真实的网页爬取
BrowserContext context = PlaywrightBrowser.acquire();
String html = null;
String bodyText = null;
try (Page page = context.newPage()) {
page.navigate(link);
// 获取文本内容
bodyText = page.innerText("body");
// 获取完整HTML
html = page.content();
} catch (Exception e) {
log.error("Error getting content from {}: {}", link, e.getMessage(), e);
} finally {
// 归还context
PlaywrightBrowser.release(context);
}
// 成功获取到的内容写入数据库缓存
if (StrUtil.isNotBlank(bodyText)) {
Row newRow = new Row();
newRow.set("id", SnowflakeIdUtils.id())
.set("url", link)
.set("text", bodyText)
.set("html", html)
.set("markdown", "") // 如果有需要,实际业务中可在此生成并保存Markdown
;
Db.save(cache_table_name, newRow);
}
return bodyText;
} finally {
lock.unlock();
}
}
}
关键点说明
异步爬取
spiderAsync
方法接收包含 URL 的WebPageConteont
列表,通过TioThreadUtils.submit
并行提交任务,减少总爬取时间。- 每个提交的任务会调用
getPageContent
方法获取页面内容。 - 最终在
Future.get()
处等待所有任务结束后,将结果填充回列表对象中。
Guava Striped 锁
- 利用 Guava 的
Striped.lock(64)
来为每个 URL 分配一把细粒度锁,避免多线程在短时间内同时爬取相同 URL,造成资源浪费或数据库重复插入。 - “双重检查”机制:在加锁前后都检查缓存是否已存在。
- 利用 Guava 的
数据库缓存
- 使用
Db.exists
来判断数据库中是否已存在该 URL 对应的内容,若有则直接返回缓存内容,省去了实际爬取开销。 - 若缓存不存在,则进行爬取,然后插入到数据库表中。
- 使用
异常处理
- 在网络或浏览器调用异常时,打印日志,并确保
BrowserContext
能够被释放。
- 在网络或浏览器调用异常时,打印日志,并确保
四、定时任务清理缓存
为避免数据库缓存持续增长,需要定期清理过期或超过一定期限的缓存。下面示例展示了如何在 Quartz 中实现一个简单的定时任务,每小时执行一次,清理一天前的数据。
package com.litongjava.maxkb.task;
import org.quartz.JobExecutionContext;
import com.litongjava.db.activerecord.Db;
import com.litongjava.tio.utils.quartz.AbstractJobWithLog;
import lombok.extern.slf4j.Slf4j;
@Slf4j
public class SchduleTaskPerHour extends AbstractJobWithLog {
@Override
public void run(JobExecutionContext context) throws Exception {
log.info("任务执行上下文: {}", context);
// 清理1天前的数据
Db.delete("DELETE FROM palywright_brower_web_page_cache WHERE create_time < NOW() - INTERVAL '1 day'");
}
}
可以在
application.properties
(或 Quartz 的其他配置文件)中配置该任务的调度时间,例如:# 表示每小时执行一次 com.litongjava.maxkb.task.SchduleTaskPerHour = 0 0 */1 * * ?
清理逻辑主要使用
DELETE FROM ... WHERE create_time < NOW() - INTERVAL '1 day'
语句,根据create_time
来判断哪些数据需要清理。具体间隔和清理策略可根据实际业务需求进行调整。
五、测试类示例
以下提供一个基于 JUnit 的简易测试类示例(可根据具体框架做适当修改)。
测试流程:
- 构造若干个
WebPageConteont
对象,每个对象包含一个url
。 - 调用
spiderAsync
方法进行多线程爬取。 - 验证爬取结果是否已写回到
WebPageConteont
的content
属性中。
package com.litongjava.perplexica.services;
import java.util.Arrays;
import java.util.List;
import org.junit.Assert;
import org.junit.Test;
import com.litongjava.searxng.WebPageConteont;
public class PlaywrightServiceTest {
@Test
public void testSpiderAsync() {
PlaywrightService service = new PlaywrightService();
// 构造测试数据
WebPageConteont page1 = new WebPageConteont();
page1.setUrl("https://www.example.com");
WebPageConteont page2 = new WebPageConteont();
page2.setUrl("https://www.wikipedia.org");
List<WebPageConteont> pages = Arrays.asList(page1, page2);
// 调用异步爬取
List<WebPageConteont> resultPages = service.spiderAsync(pages);
// 验证结果
for (WebPageConteont webPageConteont : resultPages) {
// 只要不是空,说明已成功抓取或者数据库已有缓存
Assert.assertTrue("Content should not be null or empty",
webPageConteont.getContent() != null && webPageConteont.getContent().length() > 0);
System.out.println("URL: " + webPageConteont.getUrl());
System.out.println("Content (partial): " + webPageConteont.getContent().substring(0, 100) + "...");
}
}
}
注意:
- 由于
PlaywrightService
内部使用多线程实现异步爬取,测试类执行时要注意可能的网络延迟、DNS 解析以及浏览器内核环境是否正确。如果环境没有正确安装 Playwright 支持的浏览器,可能出现异常。- 如果执行环境中不存在
Db
相关依赖(活跃记录、数据库连接等),则需要先初始化数据库连接池及对应的配置,保证Db
可用。- 在 CI/CD 环境中进行此类集成测试时,需确保网络和浏览器环境均可用,或使用 Mock 方式进行更精细的单元测试。
六、总结
通过上述方案,借助 Playwright 强大的网页自动化能力和 数据库缓存 机制,可以在高并发或频繁重复访问某些网页时,大幅减少系统内存及网络资源的占用,并让后续的相同 URL 请求快速返回。关键要点在于:
- 数据库缓存:必须设计好存储结构,保证查询效率和持久性。
- 多线程爬取:利用线程池或并发框架提交任务,合理配置线程数量。
- 并发锁控制:对同一资源(URL)必须加以并发控制,避免在缓存尚未写入之前发生重复爬取。
- 定期清理策略:缓存数据需要配合业务逻辑进行定期清理,避免无限制增长。
如有更多业务需求,可在此方案基础上扩展:
- 将爬取结果转换为 Markdown 或 JSON 等格式并一起存储;
- 结合文本分词、内容分析等 NLP 技术;
- 引入消息队列实现更复杂的分布式爬虫系统;
- 灵活调整锁粒度和缓存过期策略。
至此,关于如何使用 Playwright 进行网页爬取并结合数据库缓存来减少重复爬取的方案已经介绍完毕,完整的开发与部署还需要根据实际业务环境、数据库配置和第三方依赖来整合和测试。祝开发顺利!