如何做到99%的搜索请求延迟低于 150 毫秒？
admin
2021-01-12 09:51:05
0次
即时通讯的兴起改变了我们的交流方式。与来回的电子邮件相比，我们发送和接收消息的数量和速度都要高得多。在进行即时对话时，我们也希望能够轻松地搜索重要的短语、瞬间或有参考价值的东西。数据交换请求数量的快速增长为消息传递的可伸缩和快速发现带来了许多新的工程挑战。在这篇博文中，我们将讨论如何改进消息搜索体验，基本方法是从头开始改进消息传递后端架构，并引入我们称为 InSearch 的消息搜索后端。
本文最初发布于 LinkedIn 工程博客，经原作者授权由 InfoQ 中文站翻译并分享。
即时通讯的兴起改变了我们的交流方式。与来回的电子邮件相比，我们发送和接收消息的数量和速度都要高得多。在进行即时对话时，我们也希望能够轻松地搜索重要的短语、瞬间或有参考价值的东西。数据交换请求数量的快速增长为消息传递的可伸缩和快速发现带来了许多新的工程挑战。
在这篇博文中，我们将讨论如何改进消息搜索体验，方法是从头开始改进消息传递后端架构，并引入我们称为 InSearch 的消息搜索后端。挑战
如果我们使用 LinkedIn 的传统搜索基础设施来支持消息搜索，那么构建并提供近线索引服务的成本将会高得令人望而却步。这是因为：与其他用例相比，要索引的消息数据总量非常大。考虑到消息交换的增加（每秒数千次写操作），对索引的更新速度要高得多。这些数据需要进行静态和传输加密，因为消息数据是高度机密的。
此外，我们注意到，搜索查询与正在创建的消息的比率非常低。这使得降低搜索基础设施的成本成为一个重要的问题。我们使用这个和其他对于数据和使用模式的观察来设计了这样一个系统，它满足我们所有的需求，同时又具有成本效益。整体架构
InSearch 的高层架构
