背景

序事簿/F7模糊搜索功能原来是通过DB中SQL语言的like关键字实现的，当表中的数据量很大时，会出现以下2个比较大的瓶颈：

• 搜索响应时间慢，每次查询需要时间很久，用户体验差

• like需要全表扫描，DB压力大，可能会影响到别的正常的SQL操作

模糊搜索通过ElasticSearch实现，可以有效的解决上述问题

特性介绍

• 搜索响应时间提高

• 数据库负载降低

具体数据参考以下【性能测试报告】部分

流程设计

1. 当指定要搜索的实体表数据发生增删改时，ORM会更新数据库

2. 更新数据库的同时，把消息写入RabbitMQ

3. DTS监听并消费数据变化的消息

4. DTS把收到的消息更新到ElasticSearch中，完成数据同步

5. 当用户使用序事簿/F7做模糊搜索时，直接通过搜索ElasticSearch

MC参数配置

# 是否开启ES全文搜索模糊搜索功能，默认false
fuzzynf7.query.fulltext=true

由于该功能依赖dts数据同步，故以下参数必须开启才能生效

# 启动数据同步
data.sync.enable=true
# 启动数据同步查询
data.sync.query.enable=true
# 关闭DB全文索引
db.fulltext.fields=false

实体配置

需要ES全文索引搜索的实体，通过页面配置生效

1. 搜索实体配置列表

2. 新增搜索实体配置

3. 当搜索实体保存成功后，数据同步实体列表也会同步增加一条记录

部署建议

• 此功能的ElasticSearch部署需要和ELK的分开，独立部署

问题定位

如果出现数据同步的问题，可以通过查看日志定位问题

性能测试报告

第一次测试

第二次测试

1. 重新构造测试用例，只做模糊搜索和F7查询

2. 添加1000w数据测试数据对比

3. 添加cpu使用率比较

4. 1000w数据去掉了过滤搜索用例，只测试模糊搜索