使用XINCheck SDK开发查重系统

XINCHECK SDK是一个提供了文本查重引擎和文本查重算法的java包,使用它可以快速开发涉及文本查重相关的功能。比如标书查重、论文查重、文档查重、作业查重之类的。
也有基于这个sdk开发的桌面端软件,我这边也进行了试用。可以看这个链接XINCheck桌面端使用介绍
好了废话不多说,下面简单介绍一下SDK的使用方式

一、引入查重SDK

通过maven将本SDK 0.5.0版本引入到项目中

XINCHECK SDK需要使用1.8.0_151及以上版本的JDK,如JDK低于此版本,需要修改JDK加密策略文件或升级JDK。

SDK存放在私有maven仓库中,需要先在<repositories>中添加以下仓库

<repository>
    <id>XINCHECK</id>
    <name>XINCHECK Public Repository</name>
    <url>https://maven.xincheck.com/repository/maven-releases/</url>
</repository>

然后在<dependencies>中添加依赖

<dependency>
    <groupId>com.xincheck</groupId>
    <artifactId>duplicate-check</artifactId>
    <version>0.5.10</version>
</dependency>

除maven外同样支持Gradle、lvy等,修改对应引入语法即可。

二、授权SDK

非商业用户可以申请免费的许可证,需要先调用下面的方法获取并打印服务器或PC机的机器指纹

System.out.println(CheckManager.INSTANCE.getMachineCode());

访问获取免费版授权页面获取授权许可证
然后再拿获取到的免费授权对SDK进行授权

CheckManager.INSTANCE.setRegCode("授权许可证");
三、使用简易启动器开始查重

SDK内置了简易启动器EasyStarter,一行代码即可完成SDK调用。参数介绍如下
参数1:待查文件所在的文件夹路径(如果待查文件只有一个,可以传文件路径);
参数2:比对库文件所在的文件夹路径(如果比对库中只有一个文件,可以传文件路径);
参数3:保存查重报告的文件夹路径。如果不需要导出查重报告可以传空字符串;
参数4:白名单文本。对于标书查重等场景,有一些文本是允许重复的,这些文本可以通过该参数传入。该参数可选,如不需要可以不传或传null。

List<Reporter> reporters = EasyStarter.check(new File("参数1"), new File("参数2"), "参数3", "参数4");

横向查重应用场景下参数1和参数2可以相同,相同的文件会自动跳过比对,不会出现重复率100%的问题。除示例方法外,该方法还有多个重载,具体可以自行了解,如需详细了解。
完整示例代码可参见GitHub链接中的EasyStart部分。

四、查重结果

查重完毕后可以保存如下样式的html查重报告,部分样式可以通过接口自定义:
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

五、详细开发文档

EasyStarter只适用于逻辑简单、数据量少、无异步执行需求的应用场景,其中大量参数使用了默认值。实际项目开发过程中,对于复杂的应用场景,可以查阅完整的开发者接入文档,使用原生方式进行调用:开发者接入文档

五、付费?

XINCheck有付费版本可以购买,具体价格参加它的网站上的报价表。不过个人使用的话其实使用免费版就足够了,虽然免费版只支持8000字以下下的文本查重,但是超过8000字的可以拆分成多个文件进行查重也是一样的。报价表链接

<think>好的,我现在需要回答用户关于JMeter集合点(rendezvous point)的使用和配置的问题。首先,我得确认用户提到的“集合点”在JMeter中的对应实现。根据之前的引用内容,用户已经提到了JMeter使用Synchronizing Timer来实现类似LoadRunner中的集合点功能,用于模拟多用户并发请求[^4]。所以我的第一步是确认Synchronizing Timer的正确使用方法。 接下来,我需要回忆Synchronizing Timer的配置步骤。根据JMeter的文档,Synchronizing Timer的作用是让多个线程在某个点等待,直到达到指定的用户数量,然后同时释放这些请求,以模拟并发。用户可能需要知道如何添加这个定时器以及配置参数,比如Number of Simulated Users to Group by和Timeout in milliseconds。 然后,我应该考虑用户可能遇到的实际应用场景,比如测试秒杀系统或高并发接口。这时候需要举例说明在测试计划中添加Synchronizing Timer的位置,通常是在某个HTTP请求的子节点或者作为同级的定时器。同时,要注意超时时间的设置,避免线程长时间等待导致测试失败。 另外,需要提醒用户关于集合点使用的注意事项,比如合理设置并发用户数,避免服务器压力过大;超时时间不宜过长或过短;以及结合监听器来分析测试结果。这些点都是配置时容易忽略但重要的部分。 最后,根据用户提供的引用资料,特别是引用[4]提到的内容,我需要确保回答中正确引用这些信息,并指导用户如何实际应用这些配置步骤。可能还需要生成相关问题,帮助用户进一步了解JMeter的其他功能或优化方法,比如分布式测试或参数化配置。</think>### JMeter集合点(Synchronizing Timer)的使用及配置 在JMeter中,**集合点**通过`Synchronizing Timer`组件实现,用于模拟多用户在同一时刻发起并发请求。以下是具体步骤和配置说明: --- #### 一、配置步骤 1. **添加线程组** 右键测试计划 → 添加 → 线程(用户)→ 线程组,设置线程数(模拟用户数量)。 2. **添加HTTP请求** 右键线程组 → 添加 → 取样器 → HTTP请求,配置目标接口地址和参数。 3. **添加Synchronizing Timer** 右键HTTP请求(或其父级)→ 添加 → 定时器 → `Synchronizing Timer`。 - **关键参数**: - **Number of Simulated Users to Group by**:触发并发的最小用户数(例如设置为10,表示当10个线程到达时同时释放请求)。 - **Timeout in milliseconds**:最大等待时间(超时后,即使未达到指定用户数,线程也会继续执行)。 --- #### 二、典型应用场景 - **秒杀系统测试**:模拟大量用户同时抢购商品。 - **登录压力测试**:测试系统在高并发登录时的响应能力。 - **API并发验证**:验证接口在突发流量下的稳定性。 --- #### 三、注意事项 1. **线程组设置** 集合点的并发效果依赖线程组的用户数。例如,若设置`Number of Simulated Users=50`,则线程组中线程数应≥50。 2. **超时时间建议** - 超时时间不宜过长(避免线程卡死),一般设置为`1000-5000ms`。 - 若设为`0`,则线程会无限等待直到满足用户数[^4]。 3. **监听器配合** 添加`聚合报告`或`查看结果树`,分析并发请求的响应时间和成功率。 --- #### 四、示例配置 ```plaintext 测试计划 └── 线程组(线程数:100) ├── HTTP请求 └── Synchronizing Timer ├── Number of Simulated Users: 20 └── Timeout: 3000 ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值