上文说到有赞搜索系统的架构演进，为了支撑不断演进的技术架构，除了 Elasticsearch 的维护优化之外，我们也开发了上层的中间件来应对不断提高的稳定性和性能要求。 Elasticsearch 的检索执行效率可以表示为： O(num_of_files * logN) 其中 numoffiles 表示索引文件段的个数，N 表示需要遍历的数据量，从这里我们可以总结出提升查询性能可以考虑的两点： 减少遍历的索引文件数量 减少遍历的索引文档总数 从 Elasticsearch 自身来说，减少索引文件数量方面可以参考几点：…
Read More有赞搜索平台是一个面向公司内部各项搜索应用以及部分 NoSQL 存储应用的 PaaS 产品，帮助应用合理高效的支持检索和多维过滤功能，有赞搜索平台目前支持了大大小小一百多个检索业务，服务于近百亿数据。 在为传统的搜索应用提供高级检索和大数据交互能力的同时，有赞搜索平台还需要为其他比如商品管理、订单检索、粉丝筛选等海量数据过滤提供支持，从工程的角度看，如何扩展平台以支持多样的检索需求是一个巨大的挑战。 我是有赞搜索团队的第一位员工，也有幸负责设计开发了有赞搜索平台到目前为止的大部分功能特性，我们搜索团队目前主要负责平台的性能、可扩展性和可靠性方面的问题，并尽可能降低平台的运维成本以及业务的开发成本。 Elasticsearch Elasticsearch 是一个高可用分布式搜索引擎，一方面技术相对成熟稳定，另一方面社区也比较活跃，因此我们在搭建搜索系统过程中也是选择了…
Read More背景 在有赞早期的时候，当时只有 MySQL 做存储，codis 做缓存，随着业务发展，某些业务数据用 MySQL 不太合适， 而 codis 由于当缓存用， 并不适合做存储系统， 因此， 急需一款高性能的 NoSQL 产品做补充。考虑到当时运维和开发人员都非常少， 我们需要一个能快速投入使用， 又不需要太多维护工作的开源产品。 当时对比了几个开源产品， 最终选择了 aerospike…
Read More在系列文章前面几篇中，介绍了NSQ改造的过程和几个基础特性，本文中我们继续介绍几个高级特性及其使用场景，这些都是结合有赞业务场景总结提炼出来的重要功能。 NSQ拓展消息格式的设计 有赞中间件在NSQ中引入了支持拓展内容的消息格式，通过支持拓展的消息格式。业务方能够在消息体外定义额外的数据，拓展了应用功能，支持更多的场景。 相比较于Kafka等消息中间件，NSQ的消息格式在内容和数量上较为简单。一条消息除了基本的元数据之外，其余内容为消息体。消息的元数据主要包括了消息在服务端产生时的时间戳，服务端对于该消息的下发次数，消息ID。Kafka消息格式(record batch,control record,record)中出现的部 分元数据例如压缩格式（…
Read More之前的 文章 讲述了我们重塑NSQ的目的和目标, 接下来我们将详细描述下每个功能的具体技术细节. 重构后架构图 首先, 看一下重构后的整体架构图: 原来的几个NSQ组件大部分功能是复用的, 图中新增的就是元数据存储服务-etcd, 以及数据同步和HA处理逻辑. 改造topic queue 为了增加副本和其他特性, 首先需要改造的就是nsq的topic数据写入方式, 要保证数据最终落盘, 才能继续后面的改造. 所以我们第一步重构数据写入逻辑, 这块逻辑本身并不依赖分布式功能, 可以独立重构. 数据落盘 原版的topic写入流程是通过golang里面的chan来做的, 只有超过chan容量之后, 才会落盘. 但是chan有几个缺点, 首先是内存数据,…
Read More