我们要使用 Scala 和先前介绍的 Finagle 框架构建一个简单的分布式搜索引擎。

设计目标：大图景

从广义上讲，我们的设计目标包括 抽象 （abstraction：在不知道其内部的所有细节的前提下，利用该系统功能的能力）、 模块化 （modularity：把系统分解为小而简单的片段，从而更容易被理解和/或被更换的能力）和 扩展性 （scalability：用简单直接的方法给系统扩容的能力）。

我们要描述的系统有三个部分： （1） 客户端 发出请求，（2） 服务端 接收请求并应答，和（3） 传送 机制来这些通信包装起来。通常情况下，客户端和服务器位于不同的机器上，通过网络上的一个特定的端口进行通信，但在这个例子中，它们将运行在同一台机器上（而且仍然使用端口进行通信） 。在我们的例子中，客户端和服务器将用 Scala 编写，传送协议将使用Thrift 处理。本教程的主要目的是展示一个简单的具有良好可扩展性的服务器和客户端。

探索默认的引导程序项目

首先，使用 scala-bootstrapper 创建一个骨架项目（ “ Searchbird ” ）。这将创建一个简单的基于 Finagle 和 key-value 内存存储的 Scala 服务。我们将扩展这个工程以支持搜索值，并进而支持多进程多个内存存储的搜索。

首先，来看下 scala-bootstrapper 为我们创建的默认项目。这是一个模板。虽然最终将替换它的大部分内容，不过作为支架它还是很方便的。它定义了一个简单（但完整）的 key-value 存储，并包含了配置、thrift 接口、统计输出和日志记录。

在我们看代码之前，先运行一个客户端和服务器，看看它是如何工作的。这里是我们构建的：

这里是我们的服务输出的接口。由于 Searchbird 服务是一个 Thrift 服务（和我们大部分服务一样），因而其外部接口使用 Thrift IDL（“接口描述语言”）定义。

src/main/thrift/searchbird.thrift

这是非常直观的：我们的服务 SearchbirdService 输出两个 RPC 方法 get 和 put 。他们组成了一个到 key-value 存储的简单接口。

现在，让我们运行默认的服务，启动客户端连接到这个服务，并通过这个接口来探索他们。打开两个窗口，一个用于服务器，一个用于客户端。

在第一个窗口中，用交互模式启动 SBT（在命令行中运行 ./sbt [1]），然后构建和运行项目内 SBT。这会运行 Main.scala 定义的 主 进程。

现在，我们将使用 控制台 shell脚本初始化和运行一个客户端实例，即 SearchbirdConsoleClient 实例 (SearchbirdConsoleClient.scala) 。在另一个窗口中运行此脚本：

该服务器还输出运行统计（配置文件中指定这些信息在 9900 端口）。这不仅方便对各个服务器进行检查，也利于聚集全局的服务统计（以机器可读的 JSON 接口）。打开第三个窗口来查看这些统计：

除了我们自己的服务统计信息以外，还有一些通用的 JVM 统计。

现在，让我们来看看配置、服务器和客户端的实现代码。

…/config/SearchbirdServiceConfig.scala

配置是一个 Scala 的特质，有一个方法 apply: RuntimeEnvironment => T 来创建一些 T 。在这个意义上，配置是“工厂” 。在运行时，配置文件（通过使用Scala编译器库）被取值为一个脚本，并产生一个配置对象。 RuntimeEnvironment 是一个提供各种运行参数（命令行标志， JVM 版本，编译时间戳等）查询的一个对象。

SearchbirdServiceConfig 类就是这样一个配置类。它使用其默认值一起指定配置参数。 （Finagle 支持一个通用的跟踪系统，我们在本教程将不会介绍： Zipkin 一个集合/聚合轨迹的 分布式跟踪系统。）

…/Main.scala

在 SBT 控制台中键入“run”调用 main ，这将配置和初始化服务器。它读取配置（在 development.scala 中指定，并会作为参数传给“run”），创建 SearchbirdService.ThriftServer ，并启动它。 RuntimeEnvironment.loadRuntimeConfig 执行配置赋值，并把自身作为一个参数来调用 apply [3]。

这是实质的服务：我们用自己的实现扩展 SearchbirdService.ThriftServer 。回忆一下 thrift 为我们生成的 SearchbirdService.ThriftServer 。它为每一个 thrift 方法生成一个 Scala 方法。到目前为止，在我们的例子中生成的接口是：

scala-bootstrapper 默认实现的 key-value 存储很简单：它提供了一个通过 get 和 put 访问的 数据库 数据结构。

其结果是构建在 Scala HashMap 上的一个简单 thrift 接口。

一个简单的搜索引擎

现在，我们将扩展现有的例子，来创建一个简单的搜索引擎。然后，我们将进一步扩展它成为由多个分片组成的 分布式 搜索引擎，使我们能够适应比单台机器内存更大的语料库。

为了简单起见，我们将最小化扩展目前的 thrift 服务，以支持搜索操作。使用模型是用 put 把文件加入搜索引擎，其中每个文件包含了一系列的记号（词），那么我们就可以输入一串记号，然后搜索会返回包含这个串中所有记号的所有文件。该体系结构是与前面的例子相同，但增加了一个新的 @search@ 调用。

我们增加了一个 search 方法来搜索当前哈希表，返回其值与查询匹配的键列表。实现也很简单直观：

…/SearchbirdServiceImpl.scala

大部分修改都在这个文件中。

现在的 数据库 HashMap 保存一个正向索引来持有到文档的键映射。我们重命名它为 forward 并增加一个 倒排（reverse） 索引（映射记号到所有包含该记号的文件）。所以在 SearchbirdServiceImpl.scala 中，更换 database 定义：

需要注意的是（即使 HashMap 是线程安全的）同时只能有一个线程可以更新倒排索引，以确保对映射条目的 读-修改-写 是一个原子操作。 （这段代码过于保守；在进行 检索-修改-写 操作时，它锁定了整个映射，而不是锁定单个条目。）。另外还要注意使用 Set 作为数据结构；这可以确保即使一个文件中两次出现同样的符号，它也只会被 foreach 循环处理一次。

这个实现仍然有一个问题，作为留给读者的一个练习：当我们用一个新文档覆盖的一个键的时候，我们诶有删除任何倒排索引中引用的旧文件。

现在进入搜索引擎的核心：新的 search 方法。他应该解析查询，寻找匹配的文档，然后对这些列表做相交操作。这将产生包含所有查询中的标记的文件列表。在 Scala 中可以很直接地表达；添加这段代码到 SearchbirdServiceImpl 类中：

使用哪种方式大多是个人喜好的问题，虽然函数式风格往往会避开带有合理默认值的条件语句。

现在，我们可以尝试在控制台中实验我们新的实现。重启服务器：

单台机器上一个简单的内存搜索引擎将无法搜索超过内存大小的语料库。现在，我们要大胆改进，用一个简单的分片计划来构建分布式节点。下面是框图：

抽象

为了帮助我们的工作，我们会先介绍另一个抽象索引来解耦 SearchbirdService 对索引实现的依赖。这是一个直观的重构。我们首先添加一个索引文件到构建 (创建文件 searchbird/src/main/scala/com/twitter/searchbird/Index.scala ):

…/Index.scala

将 SearchbirdServiceImpl 类定义更换为以下（简单得多）的代码（其中不再包含索引实现细节）。注意初始化服务器现在需要第二个参数 Index 。

…/SearchbirdServiceImpl.scala

相应地更新 SearchbirdServiceConfig 的 apply 调用：

…/Index.scala

在 Index.scala 中定义了 CompositeIndex :

search 像以前一样工作。和提取第一个结果不同，我们把它们组合起来，通过使用 Set 确保其唯一性。

RemoteIndex 提供了到远程服务器的一个 Index 接口。

这样就使用一些合理的默认值，调用代理，稍微调整类型，就构造出一个 finagle thrift 客户端。

全部放在一起

现在我们拥有了需要的所有功能。我们需要调整配置，以便能够调用一个给定的节点，不管是主节点亦或是数据分片节点。为了做到这一点，我们将通过创建一个新的配置项来在系统中枚举分片。我们还需要添加 Index 参数到我们的 SearchbirdServiceImpl 实例。然后，我们将使用命令行参数（还记得 Config 是如何做到的吗）在这两种模式中启动服务器。

…/config/SearchbirdServiceConfig.scala

config/development.scala

让我们试试吧！我们将启动 3 个服务：2 个分片和 1 个主节点。首先编译改动：

然后，我们将通过控制台与它们进行互动。首先，让我们填充一些数据在两个分片节点。从 searchbird 目录运行：

• ResidentIndex 数据结构对网络、服务器或客户端一无所知。
• CompositeIndex 对其索引构成的底层数据结构和组合方式一无所知；它只是简单地把请求分配给他们。
• 服务器相同的 search 接口（特质）允许服务器查询其本地数据结构(ResidentIndex) ，或分发到其他服务器(CompositeIndex) 查询，而不需要知道这个区别，这是从调用隐藏的。
• SearchbirdServiceImpl 和 Index 现在是相互独立的模块，这使服务实现变得简单，同时实现了服务和其数据结构之间的分离。
• 这个设计灵活到允许一个或多个远程索引运行在本地机器或远程机器上。

这个实现的可能改进将包括：

• 当前的实现将 put() 调用发送到所有节点。取而代之，我们可以使用一个哈希表，将 put()调用只发送到一个节点，而在所有节点之间分配存储。
  • 但是值得注意的是，在这个策略下我们失去了冗余。我们怎样在不需要完全复制的前提下保持一定的冗余度呢？
• 当系统出错时我们没有做任何有趣的处理（例如我们没有处理任何异常）。

[1]本地 ./sbt 脚本只是保证该 SBT 版本和我们知道的所有库是一致的。

[2] 在 target/gen-scala/com/twitter/searchbird/SearchbirdService.scala 。

[3] 更多信息见 Ostrich’s README 。