文档目的
目前查重功能的主要问题
目前系统的查重功能只用在立项表单的提交功能上。当立项功能提交时触发查重检查。由于查重算法本身性能不是很快，在文档有1000多个时耗时大概5秒多；如果文档数量增加，耗时只会更多。
文档的要点
本文档主要讨论双创查重模块性能改进的方式方法。核心目标是改善用户体验。我们也许最终没有加快查重算法的性能，但是，我们的目标是改善用户的体验。使用户在使用过程中不会有不舒服的情绪。
文档目录
本文档讨论话题如下：
- 预先触发
- 支持增量数据
- 保存运行结果
- 改进运行节点
- 多节点运行
支持增量数据
目前的程序不支持增量查重数据，这意味着新通过的成果推广或者立项无法作为参考依据。可改进程序，支持增量数据写入缓存。
改进点
立项
1、立项通过后，添加到文档查重缓存中
2、立项删除后，从文档查重缓存中删除（如果有）
3、通过状态的立项修改后，重新加载到缓存（如果有）
成果推广
1、成果推广通过后，添加到文档查重缓存中
2、成果推广删除后，从文档查重缓存中删除（如果有）
3、通过状态的成果推广修改后，重新加载到缓存（如果有）
性能改进点
为了提升用户的体验，加快文档查重对比结果的输出可以在如下几点入手：
预先触发
目前触发检查的点是立项提交时同时运行查重的程序。一般用户需要等待4-5秒的时间。那么，在提交之前预先触发检查可以减少用户等待或者免于用户等待。
预先触发的方案
方案一 在立项的表单页面添加“对比”按钮。
添加方式说明
在立项表单页添加对比按钮。当用户填写完项目论证信息后，可以点击对比按钮。那么系统将在后台触发查重检查操作。
解决用户点击“对比”后再修改数据的问题
如果用户在点击完“对比”后发现先前填写的数据需要修改呢？
用户返回修改数据是无法避免的问题。
如果用户修改了项目论证中的数据，只能再次触发查重。这里涉及到两个问题：
- 如果之前的查重任务还没有完成，我们应该采取什么样的操作？
- 如果多次触发查重，是否会带来系统多重任务造成性能问题？
解决方法
由于页面提供了预先触发的功能，那么重复提交查重功能是无法避免的。但是，重复提交查重请求不代表我们一定会执行。由于我们后台的查重任务是分页抽取文档数据执行算法的，我们可以对同一个立项设置一个任务id,后面的提交请求执行前可以先检查是否正在对同一个立项执行查重任务。如果有，我们可以设置下一个分页任务不再执行，而重新开始新的查重任务。
方案二 不添加“对比按钮”,自动执行查重任务
当用户填写完一个项目论证项后，自动对该填写触发检查
说明：
1、用户在填写项目论证时，每一个框填写的文字都是比较多的，这意味着每一项的填写都是需要花费至少一分钟的时间；
2、基于上一点，如果用户填写第一项时，再填写第二项时，自动触发对第一项的查重检查，并不会影响用户，因为用户通常在第二项没有填写完成时第一项的查重结果就返回来了；
3、由于项目论证下面还有需要用户填写的内容，所以当用户填写完项目论证以后，通常可以继续正常填写下面的内容。所有查重结果返回后，用户并不会感觉系统已经提前完成了查重的任务；
4、用户在提交时，系统已经完成了所有项目论证的查重工作，所以用户不会等待查重结果返回。
用户返回修改项目论证的数据
与方案一一样，用户同样有可能返回修改先前填写的数据。这时解决思路是一样的。我们可以设置一个查重任务id，当同一个查重数据到来时，先前的任务如果还没有结束，可以提前让它结束；从而开始执行当前查重任务。
保存对比结果
由于目前的设计不保存检查的结果，那么当工单进入专家审核环节时，必须再次触发检查，这样的检查没有意义。保存检查的结果可以减少查重的次数。
保存方案的设计原则
查重的数据应该独立于业务模块
查重应该是一个独立的公用模块
查重模块的代码和数据表应独立于业务模块（代码目前是独立的模块）
查重模块的代码应该可以方便抽取成为微服务
数据表设计尽量简单，避免复杂
数据表设计
查重的表是独立的模块，但是，它还是要保存少量的业务数据。比如业务id和业务类型（随意自定义）。
| 字段名 | 中文名字 | 类型 | 备注 |
|---|---|---|---|
| id | id的值 | varchar2 | |
| business_id | 业务id | varchar2 | 32位，与业务类型组成复合主键 |
| business_type | 业务类型 | varchar2 | 自定义相应的类型 |
| hash | 哈希值 | varchar2 | 对应内容的哈希值，不需要直接保存原始内容值，只需要保存哈希，以此检测内容是否改变过 |
| create_time | 保存时间 | date | |
| state | 状态 | varchar2 | 1运行查重中 2 查重结束 |
| result_state | 是否存在可能重复的文档 | varchar2 | 1存在 2 不存在 |
| result | 查重结果 | clob | 如果触发前检查发现hash值没有发生变化，直接返回该字段结果 |
逻辑说明
1、业务模块创建一个查重任务。
参数：
业务id 业务类型 查重内容2、检查该业务查重任务是否正在运行
如果正在运行，则提前结束该任务（禁止下一个分页的查重，标志必须结束任务）
执行该查重任务3、返回查重结果。查重结果可以立即显示也可以先缓存，在需要的时候再显示。
4、一个业务类型可能查重的触发次数不止一次。当下一次触发时，如果检查hash的结果与先前一致，不必触发查重任务，只需要返回先前查重的结果。
改进运行节点
由于查重算法比较耗系统的资源，可以将查重任务转移到其他模块独立运行：
转换到BPP模块。
设置独立的微服务模块。并多节点运行。这个方案受限于系统的硬件资源情况。
多节点运行
多节点可以将查重的数据量N倍减少。可以大大提升效率，但对资源比较敏感。由于正式环境节点数量和开发难度的问题，目前这个方案可以作为备选方案。
多节点运行方案（草稿）
1、接到任务的节点成为查重任务的管理者和协调者（NameNode）
2、管理者根据文档总数量确定各节点任务，向各节点（taskNode,也可以是它自身）发送任务
3、任务的参数为查重的内容和分页的游标，文档数量
4、NameNode等待各节点返回各自的查重结果
5、所有taskNode返回查重结果后，NameNode合并结果，排序，生成最后结果
6、任何一个节点运行出错或者没有返回，该查重任务失败。（没有必要设计复杂的容错能力）
延时处理
性能改进的另一种思路是使用消息队列延时处理查重任务。但目前系统要求查重不能延时处理，因此这个方案可以作为备选。
延时处理概念方案
1、确定延时通知方案（短信、站内信、其他通知手段）
2、设计延时提交方案。（可以设置工单必须等待查重任务结束后才可以实质提交（系统自动提交），如果有重复内容，需要用户手动确认）
