搜索条件多就一定用Elasticsearch?不一定

前言

在文章正式开始前,大家打开12306中国铁路进行车票搜索,根据搜索条件判断,是否使用ElasticSearch或其他搜索技术是合适的?

实际上,12306车票搜索使用的是Redis,而不是常见的ElasticSearch。关于为何选择Redis而不是ElasticSearch,可以在继续阅读本文之前先自行思考一下。

12306 列车搜索

通过下面的截图,我们来分析下12306列车检索的条件

搜索条件如下:

  • 单程或者往返
  • 出发地
  • 目的地
  • 出发日或者返程日
  • 普通或者学生
  • 车次类型
  • 出发车站
  • 到达车站
  • 车次席别
  • 发车时间
  • 显示积分兑换车次
  • 显示全部可预订车次

搜索条件实在太多了,这似乎会严重影响数据库的性能。有些人甚至认为,如果性能不佳,至少应该使用 Elasticsearch 等搜索引擎来处理。这也是我一开始的想法。

然而,通过F12 来分析该页面的前后交互,有意思的事情发生了,我注意到了这张图的一个关键点?它只允许选择一天的出发日期。深思熟虑一下。

如果只能选择一天,那我们是不是可以这么来设计 Redis 缓存存储 12306 列车查询数据。

也许有些人会问,这么多的查询条件怎么处理呢?你可以亲自在12306网站上尝试,虽然页面上有很多查询条件,但大多数条件都是由前端进行筛选 ,实际上并没有触发后端的请求

通过F12打开控制台,打开"网络"板块,通过选择查询条件操作,你会发现只有在点击"查询"按钮时才会真正触发后端的请求,而点击页面上的其他筛选条件并不会向后端发出请求。意思就说数据缓存在了前端部分,前端可以直接基于缓存对数据进行条件过滤的查询操作,这样子就大大解放了后端的数据检索的性能消耗


那么现在对海量数据的过滤检索已经交给前端了,想要优化的思路自然而然就落到了缓存上面了,那么Redis此刻就格外亮眼,下面直接贴出几个说服点来再次突出在这个业务场景下选择Redis而不用Elasticsearch的原因

为什么使用 Redis

作为承受请求最多的列车搜索功能,需要同时兼容实时性并发性 以及部署成本几大要点。为此,我梳理了为什么必须用 Redis 的几个原因。

1. 实时性能

  • 内存存储: Redis 将数据存储在内存中,因此具有极低的读取延迟,可以快速响应实时查询请求。这对于需要即时更新的列车数据非常重要。
  • 单线程模型: Redis 使用单线程模型,虽然是单线程的,但通过非阻塞 I/O 和事件循环,它可以处理大量并发请求,减少了上下文切换和锁竞争,提高了实时性。

2. 并发性能

  • 多客户端支持: Redis 支持多个客户端并发连接,每个客户端可以独立地执行读取和写入操作,这使得它在处理高并发请求时表现出色。
  • 原子性操作: Redis 提供了原子性操作,如原子增减和原子加锁,这些操作可以在多线程或多进程环境下安全使用,有助于处理并发操作。

3. 部署成本

  • 轻量级: Redis 是一款轻量级的数据库,易于部署和维护。它的内存占用相对较低,可以在相对较小的硬件配置上运行,从而减少了部署成本。
  • 容易扩展: Redis 集群模式允许你将数据分布在多个节点上,以增加吞吐量和可伸缩性,而且这一扩展性是相对容易实现的。

实际用过 ElasticSearch 集群的应该知道,这玩意就是个性能深渊,非常消耗资源。

文末总结

12306列车数据搜索具有多个搜索条件,包括单程/往返、出发地、目的地、出发日期/返程日期、乘客类型、车次类型、出发车站、到达车站、车次席别、发车时间、显示积分兑换车次以及显示全部可预订车次等。这些条件使搜索功能变得复杂,但在实际使用中,大部分条件是前端筛选,而不是每个条件都会发起后端请求。

在这种情况下,Redis作为列车数据的缓存存储是有道理的,原因如下:

  1. 实时性: Redis 以内存为基础,具有极低的读取延迟,可以快速响应实时查询请求,这对于需要即时更新的列车数据非常重要。单程或往返、出发日期等条件可以通过快速的 Redis 查询来满足。
  2. 缓存: Redis 是一个出色的缓存数据库,可以用于缓存热门的列车路线和查询结果,从而减轻后端数据库的负载。对于需要被查询的路线,可以将其结果缓存在 Redis 中,以提高响应速度。
  3. 简单性: Redis 的数据模型相对简单,适合存储简单的键值对或一些常规数据结构。这使得 Redis 适合存储一些搜索条件,如出发地、目的地、车次类型等,以便快速筛选结果。
  4. 部署成本: Redis 是一款轻量级的数据库,易于部署和维护。它的内存占用相对较低,可以在相对较小的硬件配置上运行,从而减少了部署成本。
  5. 只需后端查询一次: 在实际操作中,页面上的搜索条件大多是前端筛选,而只有在点击查询按钮时才会发起后端请求。因此,Redis 可以用于快速存储和检索列车数据,而 Elasticsearch 等搜索引擎可以在需要进行全文搜索或复杂查询时使用。

总的来说,Redis 作为列车数据的缓存存储在实时性、并发性和部署成本方面具有一些优势,尤其适用于快速检索和缓存常用路线数据。然而,对于复杂的全文搜索和高级查询需求,可以考虑将 Redis 与 Elasticsearch 等搜索引擎结合使用,以充分发挥它们各自的优势。

相关推荐
考虑考虑19 分钟前
JDK9中的dropWhile
java·后端·java ee
想躺平的咸鱼干28 分钟前
Volatile解决指令重排和单例模式
java·开发语言·单例模式·线程·并发编程
hqxstudying1 小时前
java依赖注入方法
java·spring·log4j·ioc·依赖
·云扬·1 小时前
【Java源码阅读系列37】深度解读Java BufferedReader 源码
java·开发语言
martinzh2 小时前
Spring AI 项目介绍
后端
Bug退退退1232 小时前
RabbitMQ 高级特性之重试机制
java·分布式·spring·rabbitmq
小皮侠2 小时前
nginx的使用
java·运维·服务器·前端·git·nginx·github
前端付豪2 小时前
20、用 Python + API 打造终端天气预报工具(支持城市查询、天气图标、美化输出🧊
后端·python
爱学习的小学渣2 小时前
关系型数据库
后端
武子康2 小时前
大数据-33 HBase 整体架构 HMaster HRegion
大数据·后端·hbase