轻量级缓存策略的关系型数据库全文搜索加强与扩展.pdf

2023 08 10计算机应用,Journal of Computer Applications2023,43(8):2431-2438ISSN 10019081CODEN JYIIDUhttp：/轻量级缓存策略的关系型数据库全文搜索加强与扩展杨婷，莫若玉，张秀娟，朱洲森*（四川师范大学 物理与电子工程学院，成都 610101）（通信作者电子邮箱）摘要：针对关系型数据库（RDB）现有的全文搜索方案存在的效率低下、资源占用高的问题，提出一种具有增强式辅助缓存的轻量级关系型数据库全文搜索模型。首先，该模型构建基于Redis的倒排索引，并利用缓存索引缩小搜索范围，从而用内存高效的数据处理能力解决关系型数据库I/O瓶颈，并提升系统整体性能；其次，为保证搜索结果的准确性和时效性，进一步提出索引同步策略，而且设计并实现了增量索引组件来隐藏索引处理细节，从而提高模型的易用性和通用性；最后，对于热点数据提供一种基于访问热度的索引更新机制，以降低倒排索引的内存占用。实验结果表明，所提模型在保证关系型数据库全文搜索响应速度和准确度的前提下，空间资源消耗比MySQL全文索引降低了48.8%60.9%，比Elasticsearch降低了85.2%96.2%，证明所提模型在实际应用中可行且有效。关键词：MySQL；Redis；全文搜索；倒排索引；一致性中图分类号：TP311 文献标志码：AEnhancement and expansion of full-text search in relational databases based on lightweight caching strategyYANG Ting，MO Ruoyu，ZHANG Xiujuan，ZHU Zhousen*（School of Physics and Electronic Engineering，Sichuan Normal University，Chengdu Sichuan 610101，China）Abstract:Aiming at the problems of low efficiency and high resource consumption in the existing full-text search schemes of Relational DataBase（RDB），a lightweight full-text search model for relational databases with enhanced secondary cache was proposed.Firstly，an inverted index based on Redis was built in the proposed model and cache index was used to reduce the search scope，which solved the I/O bottleneck of relational database with efficient data processing capacity in memory，and the overall performance of the system was improved.Secondly，in order to ensure the accuracy and real time performance of the search results，the index synchronization strategy was further proposed，and the incremental index component was designed and implemented to hide the index processing details，so as to improve the usability and universality of the model.Finally，an index update mechanism based on access heat was provided for hotspot data to reduce memory usage of the inverted index.Experimental results show that on the premise of ensuring the response speed and accuracy of full-text search in relational databases，the space resource consumption of the proposed model is 48.8%-60.9%lower than that of MySQL full-text index and 85.2%-96.2%lower than that of Elasticsearch，verifying that the proposed model is feasible and effective in practical applications.Key words:MySQL;Redis;full-text search;inverted index;consistency0 引言 现阶段数据库管理技术持续发展，广泛应用的数据库系统分为两大类1：关系型数据库（Relational DataBase，RDB）和非关系型数据库（Not Only SQL，NoSQL）。尽管 NoSQL 发展迅速，占据了一定比例的市场份额，但关系型数据库仍是存储和管理数据的普遍选择2-3，是信息化建设的重要基础。erek等4指出，很多企业产生的数据必须借助RDB进行存储。RDB全文搜索是针对数据库中文本类型字段，通过对任意位置、任意内容的文本匹配，快速提取相关记录完整信息的手段，是实现海量数据快速查询的有效方式，也是影响RDB查询性能的关键因素之一。文献 5 中的研究表明，RDB全文搜索是数据处理中充分发挥海量数据资源优势的关键技术。因此，如何高效地实现RDB全文搜索也成为近年来的研究热点之一。在各类RDB中，MySQL因其稳定性、低成本、高可用和成熟生态等优点，成为应用最广泛、最具代表性的RDB6。根据不同的应用场景，MySQL提供了多种方式支持全文搜索，其中应用较为广泛的是Like匹配和RegExp正则匹配7。此外，也可通过内置函数Instr（）、Locate（）和Position（）判断子字符串是否存在于目标字段。基于模糊查询语法构建结构化查询语言（Structured Query Language，SQL），是MySQL实现全文搜索的传统方式，但这些方法都存在一定局限性：文章编号：1001-9081（2023）08-2431-08DOI：10.11772/j.issn.1001-9081.2022071108收稿日期：20220729；修回日期：20220919；录用日期：20220919。基金项目：国家社会科学基金资助项目（20BMZ092）。作者简介：杨婷（1997），女，四川广元人，硕士研究生，主要研究方向：智能信息处理；莫若玉（1994），女，四川广元人，硕士研究生，主要研究方向：智能信息处理；张秀娟（1996），女，四川南充人，硕士研究生，主要研究方向：智能信息处理；朱洲森（1966），男，陕西西安人，教授，硕士，主要研究方向：智能信息处理、数据计算与分析、大数据。第 43 卷计算机应用1）Like 匹 配、RegExp 正 则 匹 配、Instr（）、Locate（）和Position（）等内置函数均需要扫描全表，效率极低；2）三种查询方式的匹配规则单一，不支持分词查询。RDB数据存储在磁盘上，对于海量数据、高并发的全文搜索应用场景，频繁的全表扫描会造成大量系统资源消耗，甚至导致数据库崩溃。随着信息化建设深入推进，RDB中的数据量呈指数增长，以上传统方法的性能无法满足企业级深度检索信息的需求。文献 5-10 均指出，传统的模糊查询方式已无法满足全文搜索需求。MySQL为弥补Like、RegExp等传统模糊查询方式效率低下的缺陷，提供了全文索引（Full-Text）9，并在5.7.6版本之后内置了 n-gram parser 全文检索插件，用于支持中文分词。此方式对MyISAM和InnoDB引擎都有效，支持的字段类型包括 CHAR、VARCHAR 和 TEXT 三种10。FullText 索引在检索速度方面有了一定提升，但仍存在诸多弊端：1）创 建 FullText 索 引 十 分 消 耗 资 源，对 INSERT、UPDATE、DELETE操作不友好，不适用于有频繁增删改操作的表。2）仅5.7.6版本之后支持中文，且中文分词效果不佳，如果要实现较完美的中文分词，还需额外安装插件。3）使用全文索引并不是对应用透明的，必须修改查询语句为全文索引规定的语法。4）全文索引文件会占用大量空间。无论是传统的模糊查询还是MySQL提供的全文索引，都不是RDB全文搜索的理想解决方案，当前对于RDB全文搜索的研究主要由Elasticsearch等搜索引擎实现，相关研究主要有文献 11-18。Elasticsearch是当下最流行的全文检索工具，是实现RDB全文搜索的常用手段，基于Elasticsearch的全文搜索方案主要设计思路为：1）搭建Elasticsearch服务并建立搜索引擎数据库。2）读取RDB完整数据，并将它序列化为JSON数据格式，JSON文档中的字段（Field）类似于数据库中的列。3）将转换后的数据存储于Elasticsearch中。4）构建基于Elasticsearch的查询语句进行检索。5）此外，还需建立数据源与Elasticsearch的数据同步，目前常用方式是消息队列14或额外同步插件15，如 logstash-input-jdbc、go-mysql-elasticsearch和Kafka等。文献 16 中研究了Elasticsearch在构建服务时面临的数据索引、接入技术选型等问题，并提出分布式的全文搜索实现方案；但这种分布式架构消耗资源巨大，更适用于一些专注于信息检索或复杂数据分析的应用，如维基百科、GitHub和电商网站等。此外，Elasticsearch数据同步较为复杂，梁爽等17对SQL Server 的数据导入 Elasticsearch 测试，将 SQL Server 中的 900万条记录（约15 GB）同步到Elasticsearch中，共占空间35 GB左右。文献 17 中的研究表明，Elasticsearch主要以空间换时间，占用空间大，使用成本较高，并且数据库同步更新需建立较复杂的逻辑关系。文献 18 也指出 Elasticsearch 是面向文档的搜索引擎。文档中的文本具有复杂、多样的特性，但RDB中的文本信息有其自身特点：数据冗余度小、共享性高，通常文本长度较短，一般不超过 100个字符。对于以 RDB作数据存储的应用系统，额外部署Elasticsearch做全文搜索不仅成本高，开发和维护难度也大。针对RDB全文搜索研究现状，本文设计并实现了基于轻量级缓存策略的全文搜索模型。该模型利用Redis极高的读写性能和倒排索引检索优势，以极低的内存资源占用，有效提高了RDB全文搜索的速度和准确性。1 基于轻量级缓存的全文搜索模型 本文基于轻量级缓存的RDB全文搜索模型，致力于以低资源形式突破RDB全文搜索性能瓶颈，提升系统总体性能。得益于非易失存储技术和新型3D堆叠技术迅速发展19，内存性能持续提升、设备造价迅速降低，最大单机内存容量已达TB数量级，在实时大数据处理的业务应用中扮演着关键的角色。利用内存提升大数据处理性能已成为趋势，葛薇等20、Zulfa等21和Su等22都利用内存数据库Redis提高数据查询速度。Redis是一款优秀的内存数据库，在高并发场景中表现出性能高和配置简单等优势23-25，此全文搜索模型通过Redis实现索引缓存，主要包含分词模块、检索模块、全量索引模块和增量索引模块，整体架构如图1所示。2 索引缓存机制 本章详细介绍了基于缓存实现全文索引的具体设计，主要包含索引结构及存储模型、建立索引前的数据清洗与分词、数据库全量索引的构建以及数据检索的完整流程。2.1索引结构及存储模型2.1.1倒排索引数据结构倒排索引是信息检索中典型的数据结构26，由单词词典（Term Dictionary）和倒排列表（Posting List）两部分形成映射27。本文结合RDB全文搜索实际需求，设计倒排索引结构如图2所示，其中单词词典由MySQL表中部分字段文本分词后得到的词元（表示为T=t1，t2，tn）构成，倒排列表则包含字段信息和主键集合。例如，MySQL中question表中存在数据如表1所示。表1question表数据Tab.1Data from table questionid123stemRedis支持的数据类型消息队列在存取消息时要满足的3个需求Redis中Hash的实现answerString，Hash，List，Set和Zset消息保序、处理重复的消息和保证消息可靠性Hash类型的底层数据结构是由压缩列表或哈希表实现的假设对question表中stem字段和answer字段的文本内容图1基于辅助缓存的全文搜索模型的整体架构Fig.1Overall architecture of full-text search model based on secondary cache图2倒排索引数据结构Fig.2Inverted index data structure2432第 8 期杨婷等：轻量级缓存策略的关系型数据库全文搜索加强与扩展建立缓存索引（创建索引前需要对文本做分词处理，不同分词组件得到的结果不同，本节暂不展开讨论），按照上述倒排索引结构，可得表2的部分索引数据结构。由表2可知，同一词元映射的倒排列表可能包含多个表字段对应的主键列表，以词元“Hash”为例，对应倒排列表为question：stem；1，question：answer；1，3 ，表示词元“Hash”在表question的stem字段和answer字段存储的文本中均有出现。其中，question表中主键为1的记录在stem字段存在关键词“Hash”，主键为1和3的记录在answer字段存在关键词“Hash”。倒排列表中字段实质上由表名和字段名拼接而成，为便于解析，对其用“：”进行分隔。2.1.2Redis存储模型在Redis中，数据以键值对的形式进行组织和存储，这种键值映射存储模型与倒排索引数据结构类似。Redis规定，键值映射中的键只能为String类型，值可以在Redis支持的全部数据结构中选择，常见包括：字符串（String）、哈希（Hash）、列表（List）、集合（Set）和有序集合（Zset）28。随着版本的更新，Redis 又 增 加 了 4 种 数 据 类 型：BitMap（2.2 版 新 增）、HyperLogLog（2.8版新增）、GEO（3.2版新增）和Stream（5.0版新增）。倒排索引结构由词典和倒排列表构成映射，与Redis键值映射形成对应，故本文设计Redis的键存储词元，值存储倒排列表。由2.1.1节分析可知，同一词元映射的倒排列表中可以包含多个键值对元素，针对索引构建实际需求，本文选择Hash结构存储倒排列表，其中Hash的Filed由数据库表名和字段名构成，Hash中的Value由命中主键组成。索引存储模型如图3所示。但当数据量较多时（TB级别），倒排索引中过大的主键列表会引起Redis单个Key映射的Value占用空间过大问题。因Redis 单线程运行的特点，若一次操作的 Value 很大（超过10 KB）则需要较长的读写时间，阻塞后续请求，严重影响Redis的性能，故本文采用Key分段和Value压缩的方式构建Redis键值对。2.2数据清洗与分词建立索引前需进行数据清洗与分词：首先，通过大小写转换对文本作统一格式处理；其次，去空格、标点和特殊字符；最后，调用分词器进行分词处理。分词是指通过特定语法规则将一段连续的字符序列按照一定规范切分成独立的单词，分词效果也是影响全文搜索结果的重要因素。英文字符串可以直接通过空格进行分割，但中文由于复杂的语言特性，分词也要复杂得多。本文通过分析对比主流的、应用广泛的中文分词器，选择一个更适合RDB文本分词的分词器。此外，还可通过配合附加词库等方法提高分词的精度和准确度，使分词效率更高，分词效果更准确。常用中文分词组件包括word分词器、IK分词器、Ansj分词器、Jieba分词器等。通过比较4种分词器的特点得出：Ansj在中文分词方面功能强大，能够达到其他分词器的效果，支持词典拓展，并且分词速度极快，故本文使用Ansj实现分词功能。Ansj提供了4种分词方法：基本分词（BaseAnalysis）、精准分 词（ToAnalysis）、nlp 分 词（NlpAnalysis）和 面 向 索 引（IndexAnalysis）的分词。各方法支持功能如表3所示。精准分词是Ansj官方最推荐的分词方式，在易用性、稳定性、准确性以及分词效率上，都取得较好的平衡29，能够满足RDB文本分词需求，故本文采用精准分词ToAnalysis方法进行分词处理。本模型对从MySQL提取出来的文本信息和用户输入的查询关键语句都需进行数据清洗与分词处理，这两个步骤必须采用同样的分词器才能保证匹配结果的一致性。2.3全量索引构建全量索引（Full-index）即索引的初始化，主要工作是从RDB加载需要建立索引的字段文本信息，对获取的文本内容做分词处理后生成索引，并缓存在 Redis 中。Redis 不负责MySQL中数据的存储，只存储分词后的词元和数据库记录的主键信息，用于在MySQL中查询完整数据。全量索引操作仅针对RDB中需要建立索引的字段，应根据实际需求配置。为实现索引初始化，本文设计一个全局的集合C用于存储需要建立索引的字段信息，集合C中包含N个ColIndex对象（表示MySQL中字段的实体类，包含表名、主键名和字段名等属性）。根据集合中的元素构建查询SQL，从MySQL中读取相应数据。为减少应用程序与MySQL交互次数，构建查询语句时需根据字段所属数据库表进行分类，将属于同一表中的字段（多个ColIndex对象）合并成一条查询语句。此外，为降低索引构建时间，在构建查询语句时会过滤NULL值或空字符串。索引全量构建过程如图4所示，核心流程如下：1）服务启动，对集合C中的元素进行分类，并生成合并查询SQL语句。2）根据查询语句从MySQL读取数据，得到多个结果集。3）多线程处理各结果集的文本内容，遍历结果集中所有记录，通过分词器进行分词处理，得到独立词元（term）。4）构建索引：表2部分索引数据结构Tab.2Partial index data structure词元Redis支持数据类型Hash倒排列表question：stem；1，3 question：stem；1 question：stem；1 ，question：answer；1 question：stem；1 ，question：answer；3 question：stem；1 ，question：answer；1，3 图3索引存储模型Fig.3Index storage model表3Ansj功能统计Tab.3Ansj function statistics方法BaseAnalysisToAnalysisNlpAnalysisIndexAnalysis自定义词典数字识别人名识别机构名识别新词发现2433第 43 卷计算机应用index_map=termi，colIndexj，pk1，pk2，pki 其中：termi表示第i个词元，colIndexj表示第j个字段（由表名和字段名拼接组成的字符串），pk则表示主键。5）判断index_map大小是否超过阈值T：若超过，则将构建的index_map批量添加到 Redis（参考 2.1.2 节构建 Key，Field和Value）；否则，继续构建直到结果集中所有记录处理完成。6）检查Redis中是否有大Value的情况：如果有，则执行分段构建策略（参考2.1.2节）；否则，结束。2.4数据检索流程数据检索是面向用户的功能，系统接收并解析用户输入的搜索关键词，通过索引匹配返回满足搜索条件的数据信息。如图4所示，检索模块主要包含两个组件，分别是查询分析器和SQL转换器。查询分析器是对查询SQL语句进行语法解析30，即按照标准SQL语法抽象出若干属性，核心是条件解析（得到一个或多个条件表达式），目的是检验此SQL语句是否可以利用缓存索引降低查询响应时间。解析规则主要是根据 SQL 中的SELECT、FROM、JOIN和WHERE等关键字，拆分出查询字段、查询表和查询条件等。若WHERE后面包含Like、RegExp等模糊查询条件，则判断模糊匹配的字段是否建立索引（即集合C中是否包含该字段），否则直接到MySQL查询。本文设计一个ParseQuery类，用于表示标准查询SQL语义解析抽象出来的信息，部分属性如表4所示。表4ParseQuery类部分属性（部分）Tab.4Properties of ParseQuery（part）属性sqlsColConditionfTable说明原查询语句查询字段条件表达式（字段、条件运算符和条件值）表名SQL转换器的功能是将原有模糊查询SQL转换为根据主键查询的SQL，真正在数据库中执行的SQL是经过转换器处理的。对于 MySQL 来说，原 SQL 中的模糊查询条件转换为WHERE主键IN（主键列表）的查询，减少磁盘访问开销，实现高效全文搜索。数据检索的具体步骤如下：1）用户输入查询关键词信息，发起全文检索请求。2）利用式（1）中的P方法，对查询语句searchSql解析得到ObjSQL，ObjSQL是一个ParseQuery对象。ObjSQL=P(searchSql)（1）3）根据式（1）解析得到的ObjSQL，判断原查询语句是否存在模糊查询条件，且模糊查询字段wCol是否属于集合C。result=F(ObjSQL)，wCol CM(searchSql)，wCol C（2）其中：M方法是将原查询语句searchSql直接在数据库MySQL执行，并返回查询结果result。在F方法中，又包含以下处理：1）根据ObjSQL的 condition属性（条件表达式）提取条件值（即用户前台输入的查询关键词），并进行分词处理得到一系列词元T=t1，t2，tN。2）在 缓 存 层 面 根 据 倒 排 索 引 进 行 查 询，通 过get(ti，hashKey)方法获取各词元指定字段映射的主键列表。若缓存命中，则如式（3）所示，进一步对主键列表取并集，得到最终主键列表PK。PK=i=0Nget(ti，hashKey)（3）其中：ti表示词元，hashKey表示具体字段。若缓存层没有命中，则直接返回。3）利用SQL转换器，将原模糊查询语句转换为根据主键查询的SQL语句，再到数据持久层MySQL中执行转换后的语句，并将结果返回给前台用户。基于缓存索引完成的数据检索过程时序图如图5所示，数据检索模块的查询接口在接到用户的查询请求时，首先完成查询语句的解析，利用解析得到的 ParseQuery 对象，在Redis快速定位查询关键词映射的主键列表，并通过SQL转换器将复杂查询变成主键查询。图5数据检索时序图Fig.5Data retrieval sequence diagram3 索引同步策略 本文基于缓存策略的 RDB 全文搜索模型充分利用了MySQL和Redis的优势，但也意味着数据需要在这两个模块之间保持同步。就本模型而言，数据的存储由MySQL实现，并在Redis中进行索引缓存，如果MySQL中的数据发生了变更，Redis中的索引也需进行相应的变更。本文采用的实时索引策略是保证持久存储层和内存缓存层数据一致的重要支撑，也是影响搜索结果时效性和准确性的关键因素，主要包括增量索引组件、缓存一致方案和基于访问热度的索引更新策略三个方面。3.1增量索引组件全量索引的目的是在缓存层面建立一个初始的索引库，而增量索引（Delta-index）是针对MySQL中数据变更引起的索引更新。若将客户端的请求分成读请求和写请求（增、删、改），增量索引可以保证写请求下Redis和MySQL的数据一致性和读请求获取检索结果的实时性。总之，全量索引和增量索引的目的均是以低延时、高效率的方式完成全文搜索请求。图4检索模块结构Fig.4Retrieval module structure2434第 8 期杨婷等：轻量级缓存策略的关系型数据库全文搜索加强与扩展索引的更新主要有定时索引（Timing-index）和实时索引（Real-time index）两种方式。定时索引即指定时间间隔遍历数据库，对全库进行重新索引，海量数据下，每触发一次定时索引，会产生较大的资源开销；实时索引则是每一次增删改操作都会触发索引的变更。显然，实时索引更能保证数据搜索的准确性。本文采用实时索引的方式，对缓存中的索引记录进行管理。本文设计增量索引组件，对写请求执行的SQL进行监听，根据不同操作类型（INSERT、UPDATE和DELETE）分别进行异步的索引新增、更新和删除操作。增量索引组件监听到MySQL写操作时，首先通过式（4）对SQL语句进行解析，得到ParseUpdateObj，其中sql表示传入执行的SQL语句。ParseUpdateObj=parseUpdateSql(sql)（4）其中ParseUpdateObj为 ParseUpdate 类的对象，表示执行写操作的SQL语句解析得到的信息，所含部分属性如表5所示。下面根据sqlType进行分类处理：1）新增索引。若sqlType为INSERT，则进行索引新增，本文主要讨论典型的一次插入单条记录情况，基本语法如下：INSERT INTO table_name（列1，列2，）VALUES（值1，值2，）；下面给出新增索引的伪代码如算法1所示。算法1 addIndex（sql，ParseUpdateObj，C）。输入 要执行的结构化查询语句sql，SQL 解析得到的ParseUpdateObj和建立索引的字段集合C；输出 SQL执行结果。1）If ParseUpdateObj.cols C then2）return insertUpdateDelete(sql)#直接执行SQL3）Else4）ParseUpdateObj.colValues分词得Terms5）Foreach term in Terms do6）If 索引库不包含term then7）插入新的键值对索引8）Else9）更新term映射的主键列表10）End If11）End For12）return insertUpdateDelete(sql)13）End If2）更新索引。当sqlType为UPDATE时，执行索引更新操作。更新索引通常先删除该记录相关的原有索引，再根据更新值构造新的索引来实现索引的更新操作。算法 2 描述了更新索引的流程。算法2 upIndex（sql，ParseUpdateObj，C，pk）。输入 要执行的结构化查询语句sql，SQL 解析得到的ParseUpdateObj，建立索引的字段集合C和更新SQL操作表的主键pk；输出 SQL执行结果。1）If ParseUpdateObj.cols C then2）return insertUpdateDelete(sql)3）Else4）opRecord=findIDAndValue(pk，condition)5）对新值分词得到Tn=tn1，tn2，tnn6）对opRecord.oValue分词得到To=to1，to2，ton7）Pi=get(To，ParseUpdateObj.tbName)#集合To中每个词元映射的主键列表为Pi(1 i n)8）NPi=Pi-opRecord.pks#新的主键列表9）将To中各词元映射的主键列表更新为NPi10）根据opRecord.pks、ParseUpdateObj.cols和Tn建立新词元的索引11）return insertUpdateDelete(sql)12）End If假设ParseUpdateObj.cols中某个字段（表名：列名）旧值分词 词 元 映 射 的 主 键 列 表 为1，2，4，7，13，56，70，opRecord.pks为 4，7，70，那么旧词元更新后的主键列表为1，2，13，56，。3）删除索引。当sqlType值为DELETE时，执行索引删除操作。删除索引的伪代码如算法3所示。算法3 delIndex（sql，ParseUpdateObj，C）。输入 要执行的结构化查询语句sql，SQL 解析得到的ParseUpdateObj和建立索引的字段集合C；输出 SQL执行结果。1）If ParseUpdateObj.tbName存在字段属于C2）DPK=insertUpdateDelete(sql)#执行删除语句，并返回删除记录的主键集合DPK3）根据DPK和DC，对缓存索引进行更新4）Else5）return insertUpdateDelete(sql)6）End If本文通过对标准 SQL的执行进行监听实现索引动态更新，索引在初始化后可以根据数据的增加、删除和更新实时的管理维护，尽量降低索引更新带来的时间开销。本文设计的增量索引组件隐藏了对索引处理的细节，在保证此模型通用性和易用性的同时，还在一定程度上兼顾了容灾性：本文的数据搜索和索引更新均以标准SQL实现，即使Redis出现故障（如网络中断、内存故障等）31，也不会影响系统的正常运行。3.2索引一致性维护所谓索引一致性32，即对外查询每个时刻 MySQL 与Redis的数据保持一致。由于本文设计了增量索引组件实现索引的动态更新，Redis中的索引数据与MySQL中的数据的一致性问题成为不可忽略的问题。一致性是保证索引正确性与有效性的根本，数据的更新如果无法保证索引的同步更新，索引就失去了意义，甚至会出现错误索引的情况。数据一致性通常分为强一致性、弱一致性和最终一致性三种33。强一致性是一致性的最高标准，可以保证缓存中索引数据的有效性、实时性，但实现难度高，需要付出巨大的网络通信代价。通常在金融、银行等核心业务需要严格保证数据的强一致性，而缓存索引策略旨在提高 RDB 全文搜索效表5ParseUpdate类属性（部分）Tab.5Properties of ParseUpdate（part）属性sqlTypetbNamecolscolValuescondition数据类型StringStringString String Condition说明操作类型表单列名集合列值集合更新条件2435第 43 卷计算机应用率，为了保持数据与索引的同步引入强一致性协议是得不偿失的行为，因此本文选择维护数据的最终一致性。本文设计了基于CompletableFuture的异步双写策略，以接 近 实 时 的 方 式 实 现 缓 存 与 数 据 库 的 最 终 一 致 性。CompletableFuture 是 Java8提供的通过回调方式实现线程安全的高性能异步编程，可以组织不同任务的运行顺序、规则及方式。本文将数据库更新和缓存更新作为两个异步任务，通过CompletableFuture使两个异步任务产生依赖关系，组合两个任务的执行。缓存一致模型如图6所示，详细设计思路如下：1）后台接收到更新请求，首先创建任务一执行数据库更新操作；2）创建任务二执行索引的更新，任务二与任务一具有依赖关系，任务一的返回值作为任务二的方法输入参数；3）主线程中通过get（）方法获取任务一的返回值，并直接返回给前台。3.3基于访问热度的索引更新策略基于上述缓存索引模型，MySQL中的文本内容通过分词器处理后，建立倒排索引并存储于Redis中。通过分词器直接分词得到的结果细粒度较高，分词的细粒度越高，倒排索引在内存中占用的空间也就越大，但这往往不符合用户的搜索习惯。例如，用户经常搜索“强一致性”相关的内容，而Ansj分词器默认情况下不会将“强一致性”作为一个单词进行分词，而是拆分成“强”和“一致性”两个单词，即缓存索引中存在两条索引记录，那么在数据检索过程中也需要在缓存中做两次查询，并对每次获得的结果集作“与”运算。此外，在海量数据下，这种细粒度较高的分词方式也会增加索引带来的空间开销。针对上述问题，本文设计一种基于访问热度的索引更新优化策略，保证频繁访问的“热”数据（也称为“热搜词”）尽可能在缓存层面高效、精准地命中。基于访问热度的索引更新优化策略基本设计思想34是周期性地累积缓存索引被访问的次数，并计算其热度保存于全局变量中，对热度达到阈值的词进行索引更新。这种方式既能根据用户搜索偏好提高搜索结果相关度，又在一定程度上降低索引空间占用，具体设计思路如下。在用户全文搜索的过程中，系统需要记录不同搜索词的热度，故本文设计一个全局变量hot_map存储搜索词的访问频次，并将访问频率较高的搜索词定性为热度数据。热度计算公式35如式（5）：hotn=visitCountcountPeriod+(1-)hotn-1（5）其中：countPeriod表示热度计算周期；visitCount表示当前热度计算周期中，该搜索关键词被访问的次数；hotn-1表示历史热度，反映搜索词周期性累积的热度；参数（0 1）为衰减系数，用来确定当前周期累积的热度和历史热度在scoren中各自所占的权重36。越大表示最近的访问频次对当前周期的热度影响越大，历史访问热度在当前热度所占的权重越小；反之亦然。客户端发起全文搜索查询请求时，除了执行数据检索过程，还需通过额外的线程异步计算搜索词的热度（访问频次），当热度达到阈值则触发索引更新算法，具体步骤如算法4所示。算法4 upHotIndex（HT）。输入“热搜词”HT；输出 HT的索引键值对。1）对HT做分词处理得T=t1，t2，tN#根据实际全文搜索使用场景，用户输入的搜索关键词长度一般不超过25个字符，分词得到的词元个数N一般也在5以内2）分别读取T中各词元映射主键#记T映射的主键列表为P=P1，P2，PN3）HTP=i=1NPi#得到新的主键列表4）根据HT和HTP创建热数据对应索引5）NP=i=1N()Pi-HTP#将原主键列表P更新为NP6）return键值对 HT，HTP为保证搜索结果的正确性，检索过程采用的分词机制需要和建立索引使用的分词机制保持一致。除了对“热”数据动态建立索引，还需增加分词器的自定义词典。本文选用的Ansj分词器提供的ToAnalysis方法已经实现了用户自定义词典的动态添加删除，当hot_map单词热度达到阈值时，通过ToAnalysis方法将该单词添加到Ansj的词库。在后续增量索引和数据检索过程中，分词器会将“热搜词”作为一个独立单词处理。例如，对“缓存与数据库之间的强一致性”进行分词：原分词结果：缓存|与|数据库|之间|的|强|一致性增加词典后：缓存|与|数据库|之间|的|强一致性这种通过管理热搜词的缓存存储和分词策略实现基于访问热度的索引更新策略，使得全文搜索与用户实际需求更加贴合。4 实验与结果分析 系统开发平台为 jdk1.8，使用 IntelliJ IDEA 2020.1.3 完成开发。硬件环境如下：2.11 GHz 的 4 核 CPU（Intel i5-10210U），16 GB内存，Windows 11操作系统，512 GB硬盘。下面从索引构建时空代价、数据查询耗时和查询命中条数三个方面进行了实验对比。考虑特定情况下执行时间存在一定的随机性，为得到更准确的实验结果对比，每种操作重复10