为什么呢？

 

车票搜索为什么用Redis而不是ES?

1.实时性能

Redis将数据存储在内存当中，读取延迟极低，可快速响应实时查询需求。列车数据是需要即时更新的，对实时性要求较高。

2.部署成本

和ES相比的，Redis的内存占用相对较低。更轻量级，可以在较小的硬件配置上运行。

3.只需后端查询一次

在12306的官网上可以看见是只允许选择一天的出发日期和一个出发地和一个目的地，可以用

“出发地_目的地_日期”这样的键缓存存储列车数据。

而且在页面上虽然有很多如车次类型，车次席别，出发车站，到达车站那些检索条件，但那些都是在前端进行检索的，也就是说，真正的查询条件只有上面的那一排。

4.数据模型简单

适合存储一些简单的键值对和常见数据结构,如出发地，目的地,便于快速筛选结果。

如果是需要进行全文搜索和别的一些高级查询,可以两个一起结合使用.比如出发地和目的地的全文检索就可以结合ES一起做。

购买列车票中间站点余票如何更新

一辆列车的途径站点有北京北，北京南，济南西，南京南，杭州东等。

比如购买了北京南到南京南的车票，不止要扣减北京南到南京南的余票，还要扣减北京南和济南西到杭州东，北京北到(济南西、南京南、杭州东)的车票。

因为中间的座位被别人买了，所以就没有一趟坐到底的直达车票了。

购买列车余票如何防止库存超卖？

常见的解决方案有

1.数据库乐观锁

2. Redis 缓存余量扣减，利用Redis 的 incrby 特性来扣减库存，可以解决超扣和性能问题。

这些不适用于12306的座位余量扣减业务。购买车票的时候要扣减站点相关的多个库存，这具有关联属性。

12306的限流算法类似于令牌桶，会以固定速率生成令牌的，这里项目中的不会，而是将没有出售的座位当做一个个令牌放到一个容器中，令牌限流容器中的数据和列车余票一一对应，用户获取到令牌后，令牌容器的数量会进行相应的减少。这里的令牌限流容器是一个Hash的结构，可以标识了是哪一辆列车，hash容器的key是“出发站_终点站以及座位类型”，value则是座位余量。

这里采用的令牌限流算法防止超卖，抢票的人数再多，但也只有个别获取到令牌的用户可以成功，多余的流量会在购票前直接返回。，这里要在令牌限流容器中进行自减，要操作多个Hash Key，这里是非原子性的，需要用Lua脚本完成。

用户注册接口如何防止缓存穿透

缓存穿透:大量请求去访问不存在于缓存的数据，请求直接打到了数据库，影响系统性能。

用户注册穿透场景:

用户注册时，需要从缓存和数据库查询数据是否存在。
高并发情况下，大量新用户同时注册，输入的用户名都不存在于数据库。这些用户名因为在数据库没有，所以也不会写入缓存，也不会缓存null值，导致每次请求都查询数据库。
极端情况下，还有可能注册接口被恶意请求访问。

常见解决方案：

1.不存在的key进行null值缓存

2.布隆过滤器：将已注册的用户名存入布隆，判断时先用布隆过滤器判断是否存在，只要不存在就是真的不存在，存在的话还要去数据库查询。

3.Redis存储已注册用户名。

大量用户信息存储在key中导致占用内存过多。

4.分布式锁

先查询缓存，然后再查数据库前要先获取分布式锁保证只有一个线程访问数据库。

但是在高峰时期这么干的话会导致大量用户注册请求超时。用户体验不好。

实际解决方案：

使用布隆过滤器+Redis一起来解决。

布隆过滤器存储所有注册过的用户名,为了解决布隆过滤器无法删除的问题，用Redis存储所有已经注销的用户名。

两次查询会增加查询耗时和存储损耗。

并且Redis的set结构有可能会变的非常大。出现大key问题，这里