美团酒店直连项目自2013年末开始，通过业务上的不断完善和技术上的不断改进，至今已经接入200多家供应商，其中在线酒店3万以上，在线SPU30万以上。经过两年的成长，美团酒店直连平台终于在2015年末发展为国内最大的酒店直连业务平台，其接入的业务类型也从最初的经济连锁，拓展到高星渠道、小连锁集团、非标准住宿等，获得了业界一致好评。
为了使数据一致性完善方案更直观易懂，这里引用美团酒店直连项目中直连平台与供应商酒店产品数据一致性方案作为分析案例，通过面临问题、总体思路、解决方案和总结思考四个方面进行论述。
酒店直连系统的主要工作是将供应商的酒店产品（房型），通过系统对接的方式，转化为美大点评平台可以售卖的产品（房型）。
酒店产品购买是一个可预订日期跨度比较长的业务。以美团App为例，可以预订60天内的酒店。
因此我们的系统需要将供应商全部酒店全部房型信息以及60天内的价格、库存、售卖取消规则等信息，获取到我方，落地后形成产品数据，一则用在C端给用户进行展示，二则参与交易环节。
问题：直连系统在上单流程中如何保证产品缓存与供应商系统的数据一致性？
上述面临的情况很像数据库的主从同步问题，那我们是不是可以借鉴主从同步的方式来解决该问题呢？我们来看一下MySQL主从备份的实现细节：
MySQL使用3个线程来执行复制功能（其中1个在主服务器上，另2个在从服务器上）。当开始同步时，从服务器开始创建一个I/O线程，以连接主服务器，并且让主服务器发送在其二进制日志中的语句。主服务器创建一个线程将二进制日志中的内容发送到从服务器。该线程即为主服务器上showprocesslist输出中的BinlogDump线程。从服务器I/O线程读取主服务器BinlogDump线程发送的内容，并将该数据复制到从服务器数据目录中的本地文件（即中继日志）中。第3个线程是SQL线程，由从服务器创建，用于读取中继日志并执行日志中包含的更新。在从服务器上，读取和执行更新语句被分成两个独立的任务。当从服务器启动时，其I/O线程可以很快地从主服务器索取所有二进制日志内容。
以上的数据同步方案广泛的运用在数据库的数据一致性问题上，而这也正是我们长久以来一直寻求的解决之道。
具体对应到我们的系统，美团直连平台和供应商的关系为：在供应商数据产生变化的时候，将变化的部分推送至直连平台。
听上去这是个很不错的方式，但这只是个美好的目标。诸多摆在我们面前的问题无法忽略：供应商的支持力度低、供应商网络稳定性差、供应商系统可用性差。
大思路有了，但是还有很多具体问题，接下来我们就来说说是怎么解决的。
前期合作的供应商经济连锁集团大都有一个特点，他们会提供一套标准的API给有合作意向的OTA进行开发，供应商不会对API进行任何逻辑上的修改。
因此，初期我们选取的产品数据同步方案为：从无到有，定时拉取供应商全量产品数据。
应用前提：数据量级不大，数据传输效率高，拉取耗时可控。方案优点：开发周期短，逻辑简单，串行拉取。方案缺点：可持续性差，异常恢复成本高，对网络传输的带宽和本地存储容量要求高。案例分析：直连平台每30分钟主动拉取供应商下的全部酒店下全部房型信息以及60天内的价格，库存，售卖取消规则等信息。
获取信息数据量庞大
假设一家中等规模的供应商有1000家酒店，每个酒店下面有10个房型。获取信息数据量＝1000（酒店）×10（房型）×60（天数）＝60W
供应商接口速度很慢
随着业务量的增大，数据不断激增，全量数据拉取的缺点将被不断放大，实效上无法保障业务对数据一致性的要求。此时，只有主动求变才能有效应对，这里我们采取的方案是：分而治之，结合实际分析拉取部分数据。
综上，我们基本实现了不间断的拉取产品数据，同时是用户高频进行购买的产品，产品数据不一致性得大了很大幅度的缓解。
我们迫切需要改进该问题，提高用户体验。对于“分而治之”方案的缺憾我们进一步思考，寻找到了解决的方案。
这其中最主要的问题是：用户下单时看到的产品是产品缓存，只是依据产品缓存就让用户进行了下单购买，这显然是不可靠的。
需要在用户下单的时候对产品的正确性进行验证。
针对这个问题，我们对下单流程进行优化，在用户进行支付前，添加下单前校验功能，对产品数据进行校验（价格，库存等）。
下单前校验的底层接口由供应商提供，要求实时校验产品数据，不能使用缓存数据。
同时对于校验失败的产品会及时更新产品缓存，避免其他用户重复对失效产品进行反复下单。
在完成上述的改造之后，用户退款单量下降了一个数量级，由原来每天几千单下降到了几百单，用户体验大大提升。
那么为什么每天还会有几百单的退款？
针对变价问题，可以优化流程告知用户，用户可以选择继续购买。
针对库存不足问题，可以为用户继续推荐其他产品。尽量满足用户需求。
以上问题不属于本文讨论范畴，故不再展开讨论。
在这里有个策略问题：直连酒店详情页的浏览每天有几千万次，直连系统提供的异步接口QPS可以达到几百，过滤后的访问量也还是很大，将这些访问量全部转化成对于供应商系统的数据拉取，会导致供应商系统过载，甚至崩溃。这里我们针对每个不同的供应商设置一个“数据最小拉取时长”，小于该时长的访问，不再重复进行拉取，以减少供应商系统的访问次数。
例：P供应商，设置数据拉取时长为60秒。
至此，我们已经解决了产品数据拉取的绝大多数问题，基本可以保证用户的正常购买。
谋求数据一致性提升必定带来系统成本的消耗，如何降低系统运行成本将是未来我们需要思考的方向。
数据的有效预测可以帮助我们很大程度上降低成本消耗。
仍以美团直连平台为例，触发式更新确实解决了“第一个用户”的问题，虽然我们使用了“数据最小拉取时长”的方案，但新增大量访问对供应商系统还是造成一定的压力。
如：P供应商，包含1000家酒店，数据最小拉取时长为：120秒。访问量：1000（酒店数量）×30（每小时访问次数）×24（每天24小时）=720000
是不是有办法减少访问次数？同时尽量避免减少访问数次对用户的影响？答案也是肯定的。
我们抽象一下问题即为：在数据过载的前提下，及时为用户提供有意愿购买的产品信息。
那么什么是用户有意愿购买的产品呢？可以简单的根据二八定律（20%的产品会给我们带来80%的收益），来维护这20%的头部产品数据，来达到我们的目的。
这20%的头部产品数据怎么获取？单纯的已浏览量和订单量，好像都不太正确。回看一下问题中的关键词：数据过载，有意愿购买，产品信息，这些关键词都指向了一个明确的实现方案——推荐系统。
推荐系统常规的使用方式向用户推荐用户感兴趣的信息和商品。我们这里对推荐系统进行灵活运用，当预测到用户对某些信息或商品感兴趣时，为用户提前准备好信息或商品数据。
我们可以根据购买历史、价格区间、重点商圈、热销品牌等产品多维度信息，使用基于物品的协同过滤算法，区分出高中低频用户有意愿购买的产品，实现不同的数据拉取频率，以降低供应商接口的访问次数。如果我们面临的属性维度极其复杂，要分析的数据量也十分巨大的时候，协同过滤算法可能就不适用了，这时可以考虑基于深度神经网络的推荐系统。
关于推荐系统这里不再展开讲述。
目前该方案我们还没有实现，但这是我们的发展方向。
虽然我们一直致力于完善我方系统提高数据一致性，但不可否认的是，最有效的手段还是谋求合作双方的合作，而这往往是个长期、艰苦卓绝、潜移默化的过程。虽然有着共同的目标，但由于工作量的增加对方往往并不积极配合，推动合作方系统的改进工作通常十分艰难。当然，这并不能阻止我们不断前进的步伐，我们在实践中逐渐摸索出一套方案，那就是：建立有效的沟通渠道＋有力的技术支持。
应用前提：保持良好的沟通渠道，开发接口具备便利性和标准化。方案优点：降低系统的访问次数，维护成本降低，数据准确度提升。方案缺点：需要提供接入的标准API，同时沟通成本较高。案例分析：在我们和供应商合作的过程中，经过我们的不断推动，供应商也意识到了，当数据发生变化时，主动推送数据给我们是最好的解决方案。
主动推送数数据其优势表现在：-减少服务访问次数，降低服务压力，服务更加稳定。-预订成功率上升，订单增多，收益也就增多。
酒店开放平台在适宜的时候开始提供标准API，部分有技术能力的供应商开始进行接入。
接入后提供数据分析平台，对接入数据实时进行统计。
采取以上措施之后，供应商对接入更加可控，线上产品运营情况更加透明。这样一来，供应商的接入意愿就有了极大的提升。
总结一下上述四个阶段使用的数据的更新方式，分别为：-触发式-被动拉取-主动推送
数据一致性的问题是O2O行业中最常见的问题，掌握一套有效的解决方案对项目建设，尤其是系统对接类的项目建设尤为重要。这里为大家介绍的是美团酒店直连平台应对此类问题时的具体实践。其中，随着项目规模变化而采取不同的应对方法是我认为最值得借鉴的地方。四个阶段的论述之前我分别对应用前提、方案优点、方案缺点加以说明，旨在让大家更有针对性的比对，结合自身系统现状予以应用。接着通过美团酒店直连平台的案例进行分析，从而方便大家更直观的理解。
技术平台的建设和维护，是个道阻且长的过程，数据一致性的问题仅仅是沧海一粟。希望这篇博文在数据一致性问题上可以为大家提供一些思路和借鉴。