美团酒店直连产品数据一致性演进

美团酒店直连项目自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线程可以很快地从主服务器索取所有二进制日志内容。

如下图： 

以上的数据同步方案广泛的运用在数据库的数据一致性问题上，而这也正是我们长久以来一直寻求的解决之道。

具体对应到我们的系统，美团直连平台和供应商的关系为：在供应商数据产生变化的时候，将变化的部分推送至直连平台。

听上去这是个很不错的方式，但这只是个美好的目标。诸多摆在我们面前的问题无法忽略：供应商的支持力度低、供应商网络稳定性差、供应商系统可用性差。

大思路有了，但是还有很多具体问题，接下来我们就来说说是怎么解决的。

直连产品数据一致性的演进大致可以分为四个阶段，按照落实的时间顺序具体的解决方案是： - 从无到有：没有数据全量拉取 - 分而治之：数据太多分段拉取 - 精益求精：热门数据分析拉取 - 合作共赢：数据变化主动推送

第一阶段：从无到有