前言

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

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

12306 列车搜索

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

搜索条件如下：

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

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

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

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

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

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

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

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

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

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

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

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