现在越来越多的人出行都会住酒店，使用酒店APP的人越来越多，客户的需求和系统体量不断增加，为了保障用户体验度，酒店直连平台的技术架构和数据应用需要进一步完善。
（业务需求）我们做的直连系统主要解决将供应商的酒店产品（房型），转化为酒店APP可以售卖的产品（房型）。
（为什么要解决这个需求）因为我们是做酒店平台的，需要满足用户住宿的需求。
酒店产品购买是一个可预订日期跨度比较长的业务。我们的酒店APP，可以预订60天内的房源。
因此我们的系统需要将供应商全部酒店全部房型60天内的价格、库存、售卖取消规则等信息，获取到我方，落地后形成产品数据，一则给用户进行展示，二则参与交易环节。
我主要负责后台管理系统和下游交互。是主要以数据为主的交互。
为保证自己的数据和下游供应商数据的一致性，
初期，我实现定时拉取供应商全量产品数据，我们的直连平台会每30分钟主动拉取供应商下的全部酒店下全部房型60天内的价格，库存，售卖取消规则等信息。
但是采用该方案后仍旧存在一些问题：双方数据存在不一致性的时间跨度超过30分钟；30分钟定时任务执行不完，会出现任务重复调起的情况。导致这两个问题的主要原因有俩个：数据量庞大；供应商接口速度很慢。
为解决这些问题，我对数据拉取的方案进行调整，结合实际分析拉取部分数据。经过调研，我发现95%以上的用户会订购10天内的酒店房源，所以我将拉取方式调整为两种：固定时间点（例：1点，7点，13点，20点）拉取全量60天的酒店产品数据；每15分钟拉取10天的酒店产品数据。 同时调整拉取规则，拉取任务没有执行完成，不再重复调起，以减少对供应商系统的压力。
这个方案使我们基本实现了不间断的拉取产品数据，但是在2次拉取数据的间隔时间差内还会存在不一致的问题，会导致用户在支付之后没有预订到心仪的房型而自动退款，这个体验感是很不好的。
为提高用户的体验度，我采用了提前为用户准备热点数据的方案。基于用户的访问行为情况，提前对产品进行数据更新，为用户准备好即将可能要购买的产品。这个主要是靠触发式更新（被动）与库存预测（主动）来实现。
-触发式更新分为两个部分，
一个是基于用户下单行为的数据更新，可以解决非第一个用户依靠无效的产品缓存进行下单的问题，我们对原有预订流程分析发现，用户下单时看到的产品信息是产品缓存，只是依据产品缓存就让用户进行了下单购买，这显然不可靠。所以我对下单流程进行优化，在用户进行支付前，添加下单前校验功能，对产品数据进行校验。下单前校验的底层接口由供应商提供，要求实时校验产品数据，不能使用缓存数据。若校验成功则继续支付，校验失败则更新失效产品数据，防止其它用户重复对失效产品下单。经过上述改造，用户退款单量下降了一个数量级，由原来每天几千单下降到了几百单，用户体验大大提升。
另一部分是基于用户浏览行为的数据更新，这解决了第一个用户对失效产品进行下单问题。我们会在用户浏览页面的时候，异步通知直连系统，为用户提前准备可能购买产品的相关数据。（“数据最小拉取时长”）
-我们已经基本可以保证用户的正常购买了。但在谋求数据一致性的同时带来了系统成本的消耗，增加了系统运行成本。为降低系统运行成本，我采用了库存预测，会在数据过载的前提下，及时为用户提供有意愿购买的产品信息。根据购买历史、价格区间、重点商圈、热销品牌等产品多维度信息，使用基于协调算法的推荐系统实现。
虽然我们一直致力于完善我方系统提高数据一致性，但最有效的手段还是谋求合作双方的合作。在数据变化时主动推送数据。
通过对获取产品数据功能的持续改造，使得直连系统为用户提供了可靠的数据来源。
做项目的时候，
遇到的问题？
最难的点？
有无使用redis？
redis，缓存击穿血崩 关系？