实时计算价格库存的酒店电商检索系统.PDF

实时计算价格库存的 酒店电商检索系统 乔勇 高级总监 艺龙 yong.qiao@ 2016-4-21 静态价电商 vs 动态价类电商 不同点 静态类 动态类 基础数据规模 2个数 180 x 30 x 2 促销形式 打标的方式，订单环境促销复杂组合参与最终 (立减、返券、红包） 计算价格 计算 第三方维度 预订渠道、会员级别等 动态因素 预订窗口、周中周末、 上下午等 一些数字 • 仅库存价格的数据规模 • 50w酒店*50产品*180天*30天*2 = 2700亿 • 4byte去存储这类数字 = 1054G • 业务逻辑复杂 • 一百多张数据库表的复杂依赖 一些数字 • 酒店每日检索规模： 128亿/ 日 • 3.31数据： * 1000 + • 产品每日计算规模： 3840亿次/ 日 • 平均30个产品 • 一个酒店库存价格计算在1ms，那么搜索北京1w酒店？ • 注：16年3月底，流量低峰数据 传统方案A • 思路：DB+Cache • 基于数据库处理业务逻辑 • 结果全部cache • 瓶颈 • 冷query非常慢 • 单机吞吐量低 • Cache时效性延迟 • 扩展性差 传统方案B • 思路：业务内存 + “智能”cache • DB数据尽可能内存化 • cache尽可能智能 • 业务有损折中 • 瓶颈 • 资源高消耗 （内存、cpu） • 无法100%准确 • 事务一致性维护困难 elong实践 • 架构要满足业务的痛点 • 数据一致性 • 时效性，尤其高峰期 • 服务能力水平扩展 • 思路 • 单机能力提升可扩展 • 单机内部、多机之间要做到“一致性” • 时效性区分重要性分别满足 数据一致性 时效性 • 困难 • 缺乏传统db的事务支持 • 过度的性能优化依靠cache • 多机之间的cache • 解决方案 • 放弃部分性能，回避cache 的复杂度 • 引入数据的版本来控制一致性 • 分粒度 （小时、分钟、秒）保证时效性 数据一致性 时效性 数据一致性 时效性 • 同一个消息先后抵达 • 同一个消息同时抵达 • 前后两个消息逆序到达 • 儿子消息比父消息先到 单机能力 • 内存如何瘦身 • 计算如何更快 单机能力 • 内存瘦身方面的困难 • 数据量客观规模很大 • 数据引入版本后压缩效率降低 • 解决方法 • 利用信息量低做索引压缩 • 分版本压缩优化 • Shard