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