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

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

问题的定义与决策

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

1. 直接在 MySQL 数据库中查询用户在搜索框中输入的每个关键词，就像 %#{word1}%#{word2}%… 这样。
2. 使用一个高效的搜索数据库，如 Elasticsearch。

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

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

1. 使用 Worker 定期查询 MySQL 数据库，并将所有变化的数据发送到 Elasticsearch。
2. 在应用程序中使用 Elasticsearch 客户端，将数据同时写入到 MySQL 和 Elasticsearch 中。
3. 使用基于事件的流引擎，将 MySQL 数据库中的数据更改作为事件，发送到流处理服务器上，经过处理后将其转发到 Elasticsearch。

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

对于其他两种选择，不同的应用场景做出的决定可能会有所不同。在我们的场景中，如果选择选项 2，那么我们可以预见一些问题：如过 Elasticsearch 建立网络连接并确认更新时速度很慢，那么这可能会降低我们应用程序的速度；或者在写入 Elasticsearch 时发生了未知异常，我们该如何对这一操作进行重试来保证数据完整性。

不可否认开发团队中不是所有开发人员都能了解所有的功能，如果有开发人员在开发新的与产品有关的业务逻辑时没有引入 Elasticsearch 客户端，那么我们将在 Elasticsearch 中更新这次数据的更改，无法保证 MySQL 与 Elasticsearch 间的数据一致性。

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

服务简介

为了对外提供统一的搜索接口，我们首先需要定义用于搜索的数据结构。对于大部分的搜索系统而言，对用户展示的搜索结果通常包括为标题和内容，这部分内容我们称之可搜索内容（Searchable Content） 。在多租户系统中我们还需要在搜索结果中标示出该搜索结果属于哪个租户，或用来过滤当前租户下可搜索的内容，我们还需要额外的信息来帮助用户筛选自己想要搜索的产品类别，我们将这部分通用的但不用来进行搜索的内容称为元数据（Metadata） 。最后，在我们展示搜索