基于Kafka和Elasticsearch构建实时站内搜索功能的实践

目前我们在构建一个多租户多产品类网站，为了让用户更好的找到他们所需要的产品，我们需要构建站内搜索功能，并且它应该是实时更新的。本文将会讨论构建这一功能的核心基础设施，以及支持此搜索能力的技术栈。

问题的定义与决策

为了构建一个快速、实时的搜索引擎，我们必须做出某些设计决策。我们使用 MySQL 作为主数据库存储，因此有以下选择：

直接在 MySQL 数据库中查询用户在搜索框中输入的每个关键词，就像 %#%#%... 这样。

使用一个高效的搜索数据库，如 Elasticsearch。

考虑到我们是一个多租户应用程序，同时被搜索的实体可能需要大量的关联操作（如果我们使用的是 MySQL 一类的关系型数据库），因为不同类型的产品有不同的数据结构，所以我们还可以能需要同时遍历多个数据表来查询用户输入的关键词。所以我们决定不使用直接在 MySQL 中查询关键词的方案。

因此，我们必须决定一种高效、可靠的方式，将数据实时地从 MySQL 迁移到 Elasticsearch 中。接下来需要做出如下的决定：

使用 Worker 定期查询 MySQL 数据库，并将所有变化的数据发送到 Elasticsearch。

在应用程序中使用 Elasticsearch 客户端，将数据同时写入到 MySQL 和 Elasticsearch 中。

使用基于事件的流引擎，将 MySQL 数据库中的数据更改作为事件，发送到流处理服务器上，经过处理后将其转发到 Elasticsearch。

选项1并不是实时的，所以可以直接排除，而且即使我们缩短轮询间隔，也会造成全表扫描给数据库造成查询压力。除了不是实时的之外，选项 1 无法支持对数据的删除操作，如果对数据进行了删除，那么我们需要额外的表记录之前存在过的数据，这样才能保证用户不会搜索到已经删除了的脏数据。对于其他两种选择，不同的应用场景做出的决定可能会有所不同。

在我们的场景中，如果选择选项 2，那么我们可以预见一些问题：如果 Elasticsearch 建立网络连接并确认更新时速度很慢，那么这可能会降低我们应用程序的速度；或者在写入 Elasticsearch 时发生了未知异常，我们该如何对这一操作进行重试来保证数据完整性；不可否认开发团队中不是所有开发人员都能了解所有的功能，如果有开发人员在开发新的与产品有关的业务逻辑时没有引入 Elasticsearch 客户端，那么我们将在 Elasticsearch 中更新这次数据的更改，无法保证 MySQL 与 Elasticsearch 间的数据一致性。

接下来我们该考虑如何将 MySQL 数据库中的数据更改作为事件，发送到流处理服务器上。我们可以在数据库变更后，在应用程序中使用消息管道的客户端同步地将事件发送到消息管道，但是这并没有解决上面提到的使用 Elasticsearch 客户端带来的问题，只不过是将风险从 Elasticsearch 转移到了消息管道。最终我们决定通过采集 MySQL Binlog，将 MySQL Binlog 作为事件发送到消息管道中的方式来实现基于事件的流引擎。关于 binlog 的内容可以点击链接：https://dev.mysql.com/doc/refman/5.7/en/binary-log.html，在这里不再赘述。

服务简介

为了对外提供统一的搜索接口，我们首先需要定义用于搜索的数据结构。对于大部分的搜索系统而言，对用户展示的搜索结果通常包括为和，这部分内容我们称之可搜索内容（Searchable Content）。在多租户系统中我们还需要在搜索结果中标示出该搜索结果属于哪个租户，或用来过滤当前租户下可搜索的内容，我们还需要额外的信息来帮助用户筛选自己想要搜索的产品类别，我们将这部分通用的但不用来进行搜索的内容称为元数据（Metadata）。最后，在我们展示搜索结果时可能希望根据不同类型的产品提供不同的展示效果，我们需要在搜索结果中返回这些个性化展示所需要的原始内容（Raw Content）。到此为止我们可以定义出了存储到 Elasticsearch 中的通用数据结构：

基础设施

Apache Kafka: Apache Kafka 是开源的分布式事件流平台。我们使用 Apache kafka 作为数据库事件（插入、修改和删除）的持久化存储。

mysql-binlog-connector-java: 我们使用 mysql-binlog-connector-java 从 MySQL Binlog 中获取数据库事件，并将它发送到 Apache Kafka 中。我们将单独启动一个服务来完成这个过程。

在接收端我们也将单独启动一个服务来消费 Kafka 中的事件，并对数据进行处理然后发送到 Elasticsearch 中。

配置技术栈

我们使用 docker 和 docker-compose 来配置和部署服务。为了简单起见，MySQL 直接使用了 root 作为用户名和密码，Kafka 和 Elasticsearch 使用的是单节点集群，且没有设置任何鉴权方式，仅供开发环境使用，请勿直接用于生产环境。

在服务启动成功后我们需要为 Elasticsearch 创建索引，在这里我们直接使用 curl 调用 Elasticsearch 的 RESTful API，也可以使用 busybox 基础镜像创建服务来完成这个步骤。

核心代码实现（SpringBoot + Kotlin）

Binlog 采集端：

在这段代码里面，我们首先是对 binlog 客户端进行了初始化，随后开始监听 binlog 事件。binlog 事件类型有很多，大部分都是我们不需要关心的事件，我们只需要关注 TABLE_MAP 和 WRITE/UPDATE/DELETE 就可以。当我们接收到 TABLE_MAP 事件，我们会对内存中的数据库表结构进行更新，在后续的 WRITE/UPDATE/DELETE 事件中，我们会使用内存缓存的数据库结构进行映射。整个过程大概如下所示：

随后我们将收集到的事件发送到 Kafka 中，并由 Event Processor 进行消费处理。

事件处理器

首先使用 SpringBoot Message Kafka 提供的注解对事件进行消费，接下来将事件委托到  去进行处理。实际上  是个自定义的函数式接口，我们自定义事件处理器实现该接口后通过 Spring Bean 的方式注入到  中。

在这里我们只需要简单地判断是否为删除操作就可以，如果是删除操作需要在 Elasticsearch 中将数据删除，而如果是非删除操作只需要在 Elasticsearch 重新按照为文档建立索引即可。这段代码简单地使用了 Kotlin 中提供的 mapOf 方法对数据进行映射，如果需要其他复杂的处理只需要按照 Java 代码的方式编写处理器即可。

总结

其实 Binlog 的处理部分有很多开源的处理引擎，本文使用手动处理的方式也是为其他使用非 MySQL 数据源的同学类似的解决方案。大家可以按需所取，因地制宜，为自己的网站设计属于自己的实时站内搜索引擎！