导读
百度百科 2026年09月23日 15:46 间夜量是酒店及在线旅游平台（OTA）的核心运营数据指标之一。在OTA平台的运营中，间夜量常被用作衡量酒店服务质量的关键指标之一，对酒店的流量获取和曝光度有重要影响。2019年，美
详情
美团 · 技术团队首页历史文章技术沙龙关于我们美团酒店直连产品数据一致性演进 李响 2016-12-26系统数据前言美团酒店直连项目自2013年末开始，通过业务上的不断完善和技术上的不断改进，至今已经接入200多家供应商，其中在线酒店3万以上，在线SPU30万以上。经过两年的成长，美团酒店直连平台终于在2015年末发展为国内最大的酒店直连业务平台，其接入的业务类型也从最初的经济连锁，拓展到高星渠道、小连锁集团、非标准住宿等，获得了业界一致好评。
随着美团的日益壮大，客户的需求和系统体量的不断增加，直连平台的技术架构和数据应用面临着诸多挑战。为了保障美团的用户体验度，对技术方面会提出更高的要求。
这些是直连平台每天都在思考的问题。技术平台和数据应用的改进完善并非一蹴而就。考虑到数据是业务运营的核心，这里先以产品数据一致性问题的解决方案作为切入点与大家分享，也希望借此抛砖引玉，欢迎更多的同学一起探讨，共同进步。
为了使数据一致性完善方案更直观易懂，这里引用美团酒店直连项目中直连平台与供应商酒店产品数据一致性方案作为分析案例，通过面临问题、总体思路、解决方案和总结思考四个方面进行论述。
酒店直连系统的主要工作是将供应商的酒店产品（房型），通过系统对接的方式，转化为美大点评平台可以售卖的产品（房型）。
酒店产品购买是一个可预订日期跨度比较长的业务。以美团App为例，可以预订60天内的酒店。
因此我们的系统需要将供应商全部酒店全部房型信息以及60天内的价格、库存、售卖取消规则等信息，获取到我方，落地后形成产品数据，一则用在C端给用户进行展示，二则参与交易环节。
问题：直连系统在上单流程中如何保证产品缓存与供应商系统的数据一致性？
上述面临的情况很像数据库的主从同步问题，那我们是不是可以借鉴主从同步的方式来解决该问题呢？我们来看一下MySQL主从备份的实现细节：
MySQL使用3个线程来执行复制功能（其中1个在主服务器上，另2个在从服务器上）。当开始同步时，从服务器开始创建一个I/O线程，以连接主服务器，并且让主服务器发送在其二进制日志中的语句。主服务器创建一个线程将二进制日志中的内容发送到从服务器。 该线程即为主服务器上show processlist输出中的Binlog Dump线程。从服务器I/O线程读取主服务器Binlog Dump线程发送的内容，并将该数据复制到从服务器数据目录中的本地文件（即中继日志）中。 第3个线程是SQL线程，由从服务器创建，用于读取中继日志并执行日志中包含的更新。 在从服务器上，读取和执行更新语句被分成两个独立的任务。当从服务器启动时，其I/O线程可以很快地从主服务器索取所有二进制日志内容。
以上的数据同步方案广泛的运用在数据库的数据一致性问题上，而这也正是我们长久以来一直寻求的解决之道。
具体对应到我们的系统，美团直连平台和供应商的关系为：在供应商数据产生变化的时候，将变化的部分推送至直连平台。
听上去这是个很不错的方式，但这只是个美好的目标。诸多摆在我们面前的问题无法忽略：供应商的支持力度低、供应商网络稳定性差、供应商系统可用性差。
大思路有了，但是还有很多具体问题，接下来我们就来说说是怎么解决的。
直连产品数据一致性的演进大致可以分为四个阶段，按照落实的时间顺序具体的解决方案是：
前期合作的供应商经济连锁集团大都有一个特点，他们会提供一套标准的API给有合作意向的OTA进行开发，供应商不会对API进行任何逻辑上的修改。
因此，初期我们选取的产品数据同步方案为：从无到有，定时拉取供应商全量产品数据。
应用前提：数据量级不大，数据传输效率高，拉取耗时可控。 方案优点：开发周期短，逻辑简单，串行拉取。 方案缺点：可持续性差，异常恢复成本高，对网络传输的带宽和本地存储容量要求高。 案例分析：直连平台每30分钟主动拉取供应商下的全部酒店下全部房型信息以及60天内的价格，库存，售卖取消规则等信息。
我们使用这个方案在同几家供应商进行合作了以后，陆续发现存在一些问题：
假设一家中等规模的供应商有1000家酒店，每个酒店下面有10个房型。 获取信息数据量＝1000（酒店）×10（房型）×60（天数）＝60W
供应商接口速度很慢 根据统计，供应商接口的平均响应时间在两三秒以上，获取产品接口由于数据量大，可能响应时间在几十秒甚至上百秒。
这时你可能会问：目前定时任务是每30分钟调起一次，缩短定时任务的调起时间就可以减少数据不一致问题的时间段呢？ 这确实可以解决一部分问题，提前是任务在短时间就可以执行完成。但是对于长时间执行无法完成的任务可能适得其反，过于频繁的接口调用，反到把供应商的系统压垮了。 这是我们不愿意看到的，慢总比不能使用来得好些。
随着业务量的增大，数据不断激增，全量数据拉取的缺点将被不断放大，实效上无法保障业务对数据一致性的要求。此时，只有主动求变才能有效应对，这里我们采取的方案是：分而治之，结合实际分析拉取部分数据。
应用前提：充分调研，因地制宜，数据可分段获取。 方案优点：同步数据体量大幅降低，数据准确度有效提升。 方案缺点：还存在数据不一致的时间差。 案例分析：根据酒店的预订特点，调研了美团用户的消费习惯：95%以上的用户都在预订10天内的酒店产品。
我们将产品拉取方式调整了两种： 固定时间点（例：1点，7点，13点，20点）拉取全量60天的酒店产品数据。 每15分钟拉取10天的酒店产品数据（这就好比我们在查询数据库的时候添加了limit）。 同时调整拉取规则，拉取任务没有执行完成，不再重复调起，以减少对供应商系统的压力。
上述方案我们可以简单的认为将拉取的数据量和响应时间减少了近5/6，同时我们可以根据供应商的服务能力动态调整拉取频率，例如：2分钟可以执行完的任务，设置为每3分钟拉取一次。 即使因为网络抖动等原因引起的任务时间增加，也不用担心任务重复调起压垮供应商系统。
综上，我们基本实现了不间断的拉取产品数据，同时是用户高频进行购买的产品，产品数据不一致性得大了很大幅度的缓解。
拉取部分产品数据的方案解决了绝大多数的产品数据不一致的问题，但是在2次拉取数据的间隔时间差内还会存在不一致的问题，会导致用户在支付之后没有预订到心仪的房型而自动退款，如选择退回原支付方账户，用户需要等待3～10个工作日，体验十分不好。
我们迫切需要改进该问题，提高用户体验。 对于“分而治之”方案的缺憾我们进一步思考，寻找到了解决的方案。
为了应对间隔时间差的问题，我们的解决的方案是：提前为用户准备热点数据。这个主要是靠触发式更新（被动）与库存预测（主动）来实现。
应用前提：摸清定位，准确匹配，对系统本身有深入的了解，同时对业务未来的发展趋势有一定的预测能力。 方案优点：数据准确度提高，降低数据一致性相关的资源消耗。 方案缺点：分析成本高，增加了分析数据捕获清洗的系统消耗。 案例分析：基于用户的访问行为情况，提前对产品进行数据更新，为用户准备好即将可能要购买的产品。
我们从预订流程入手，对原有的预订流程进行分析。 原有流程很简单，如下：
这其中最主要的问题是：用户下单时看到的产品是产品缓存，只是依据产品缓存就让用户进行了
版权说明：本文系毕昇酒店经编辑部根据公开信息整理转载，内容来源：美团酒店（阅读原文）。本文版权归原作者及原发布平台所有，转载仅为酒店行业信息交流之用，不用于任何商业目的；转载时已注明来源，如有疏漏请联系补充。
异议处理：如您认为本文涉及侵犯著作权、名誉权或其他合法权益，请通过邮箱 6589776@qq.com 联系我们（请附文章链接及权属证明），我们承诺核实后 24 小时内删除或更正。本文内容仅供参考，不构成任何投资建议。