聊聊sphinx业务落地架构

内容纲要

前言

随着大数据时代的到来,每个企业都会积累一定量的数据。当数据到达一定体量时(如亿级别),传统的查询方式其实很难满足常见搜索场景了。比如模糊查询,关键字高亮等,关系型数据库也是可以实现的,但是成本和效果并不是很理想。这个时候就诞生了一个新的技术———— 搜索引擎

常见的搜索引擎技术


  1. MySQL模糊查询
    优点:简单易用,学习成本低
    缺点:不够灵活,数据量大时会很慢
  2. Sphinx
    优点:部署相对简单,类sql查询方式,学习成本还好
    缺点:分布式支持不是很好
  3. Elasticsearch
    优点:完善的分布式方案,无需额外的配置
    缺点:学习成本略高

几个技术方案看下来各有优缺点,做为一个技术人,技术本身没有好坏之分,只有哪一种技术适合自己的业务、团队、场景等。今天主要和大家分享一下sphinx的落地方案。欢迎一起探讨!

搜索引擎的业务流程


业务流程以一张图来简单说明:

有同学可能会有疑问,不是说替代mysql吗,怎么图中还是有它。其实这是一种误解,传统的关系型数据库,其实也有他自身的优势,借助于sphinx,很多时候只是为了弥补mysql的短板————模糊匹配效率太低
这里常见的具体做法是:
场景一:
1.模糊匹配让sphinx或者es来处理,得到一个结果(mysql中的主健)
2.再拿到结果到mysql中查详细的信息
场景二:
所有的数据全部存在搜索引擎中,直接替换了mysql

以上两种场景都存在,具体哪种好这里不展开细说

服务架构


这里用到的是一拖多的方式
1.一个负载均衡服务器
2.多台实体机
3.实体机上存在多个sphinx服务,每个实体机上是一样的服务(有没有感觉有点奇怪)

数据同步方案

一、全量数据同步

全量数据同步,每天定时的全量同步,以及实时数据同步故障是用到
实现方式:依赖于sphinx配置文件,从mysql中获取数据生成索引

二、增量数据同步(实时数据)

当有新的数据产生时,需要及时的同步数据到sphinx,而不至于用户搜索不到
实现方式:监听binlog实时同步数据,到sphinx的rt_index中

监听binlog用到的扩展是https://github.com/noplay/python-mysql-replication
当然,数据同步中还有很多小的细节,篇幅有限,就不展开来讲,感兴趣的同学欢迎一起探讨

总结

应该会有同学问,你们怎么还在用sphinx这个老古董啊,es难道不香吗?说实话es还是蛮香的,还在有的重要原因是,比较久远的业务一直在跑,还跑得比较正常,属于深度套牢的那种。后续应该会逐步的迁移到ES中去。
但是在接触了两种不同的技术后,发现其实技术的本质是相通的,只是实现的方式不一样。

发表评论

邮箱地址不会被公开。 必填项已用*标注

− 5 = 3