搜索功能技术方案

1. 背景与需求分析

门户平台需要实现对服务信息的高效查询，包括通过关键字搜索服务以及基于地理位置进行服务搜索。面对未来可能的数据增长和性能需求，选择使用 Elasticsearch 来替代 MySQL 的全文检索功能。这一选择的背景与需求可以总结为以下几点：

关键字查询：用户可能需要通过服务的名称、描述、分类等信息进行关键字搜索，且搜索性能对用户体验至关重要。MySQL 提供了有限的全文检索能力，但在大数据量、高并发下的性能不如专门的搜索引擎。
地理位置查询：系统要求支持基于用户地理位置的服务搜索，Elasticsearch 的 geo 查询功能专门用于解决此类地理坐标相关的查询，MySQL 在这方面的支持较为有限。
数据增长预期：虽然当前数据量较小，但考虑到未来服务数据的增长（可能从几千条增长到几万或几十万条），需要一个能够横向扩展、应对海量数据的搜索解决方案。
查询实时性与并发性能：门户系统的用户访问量较大，尤其是面向 C 端用户，要求搜索查询不仅需要高效，还要在数据更新后能及时反映变化。因此，对索引同步的实时性和查询性能有较高要求。

基于以上需求，采用了 Elasticsearch 作为搜索引擎，同时引入了 Canal + MQ 方案以实现索引的实时同步。

Elasticsearch 是一个分布式搜索引擎，基于 Lucene 构建，提供强大的全文检索、结构化查询和地理位置查询功能。选择它的原因包括：

高效全文检索：基于倒排索引的数据结构，Elasticsearch 能够快速处理海量文本数据，支持各种查询方式（如模糊匹配、同义词匹配等）。
地理位置查询：Elasticsearch 内置支持地理位置查询，能够高效处理基于地理坐标的距离计算和范围过滤查询，特别适用于服务场景中需要根据用户当前位置进行服务推荐的需求。
分布式架构：Elasticsearch 通过分片和副本机制实现了良好的水平扩展能力，能够应对未来的数据增长和高并发查询。

为了确保 Elasticsearch 的索引与数据库保持一致，项目采用了 Canal + MQ 的方式进行数据同步。

Canal会定时读取数据库的binlog日志，解析出增加、修改及删除的数据内容并将其写入MQ。

同步程序监听MQ，收到消息后根据消息内容请求ES同步索引数据。

Canal 的作用：Canal 是阿里巴巴开源的一款工具，专门用于解析 MySQL 的 binlog 日志，模拟 MySQL 从库的增量数据同步。在项目中，Canal 会实时监听数据库的增、删、改操作，并解析出具体的操作数据。
MQ 的作用：Canal 将解析后的数据变动事件（如新增、修改、删除操作）以消息的形式推送到消息队列（MQ）。MQ 起到了缓冲作用，确保系统的消息异步处理能力。当数据库发生大量数据变动时，消息可以在队列中被有序处理，避免 Elasticsearch 的索引更新被短时间内大量请求压垮。
数据同步逻辑：监听到 MQ 中的消息后，系统中的同步程序会根据消息内容决定对 Elasticsearch 的操作：
- 对新增的数据进行索引添加。
- 对修改的数据进行索引更新。
- 对删除的数据进行索引移除。

这种异步处理机制大大提高了系统的稳定性和扩展性，尤其是在高并发和高频率数据变更的场景下，能够有效减轻数据库的负担。