去哪儿酒店实时报价搜索技术分享.pdf

去哪儿酒店实时报价搜索技术分享 刘 玥 关于去哪儿酒店搜索 • 定位 –垂直搜索平台 • 目标 –Smart Your Hotel Reservation • 目前规模 –搜索210家酒店预订站点 –支持全球22699个城市 –覆盖368892家酒店 主要议题 • 系统结构总览 • 服务拆分和系统可用性 • 实时报价搜索的设计考量 • 监控系统 Overview Overview Overview 系统结构总览 • 系统的核心考量 –信息搜索准确和全面 –报价和房态的实时准确 –高可用性 –性能 系统结构总览 • 如何达到 –报价和房态的实时准确 –实时报价获取 –高可用性 –服务拆分 –监控和运维 –性能 –缓存设计 –监控和数字 系统结构总览 • 现有主要服务 – HotelSearch Render Service • 负责主要页面数据获取和展现 – HotelSearch Service • 负责关键字检索 – HotelSearch Rank Service • rank计算服务 – HotelSearch Price Service • 负责实时房价房态搜索和计算 – HotelSearch Price Crawl Service • 实时房价房态抓取服务 系统结构总览 服务拆分 • 拆分原则 – 功能内聚的独立业务模块 • 拆分目的 – 降低维护成本 – 提高系统整体可用性 • 故障隔离 • 服务降级 服务拆分 • 服务化模块间通讯 – http • nginx + QunarClient – rpc • dubbo • 可用性和负载均衡 – rpc • zookeeper – http • ngx-healthcheck • 负载均衡 – roundrobin – 按ip或cookie哈希 – 按搜索条件哈希 实时报价搜索 • Why – 酒店的价格和房态，尤其是房态变化快 – 价格和房态的准确性是保证用户的搜索体验的 前提条件 • Challenges – 保证用户请求的响应效率 – 保证用户看到最新的价格和房态 – 降低对目标网站的抓取量 实时报价搜索 • 核心组件 – 报价服务 – 抓取服务 – 消息中间件 – 分布式缓存 实时报价搜索 • 当前规模 – 报价服务每秒请求量峰值近1600qps，全天超过 1亿次动态请求 – 报价服务平均请求响应时间4ms – 报价抓取服务平均每秒处理完成4000个抓取请 求，全天近2.5亿次报价抓取 实时报价搜索 • 如何应对 – 服务拆分 – 异步化 – 缓存设计 – 降低抓取量 实时报价搜索 • 服务拆分 – 报价计算服务和抓取服务分拆 – HotelSearch Price Service – HotelSearch Price Crawl Service • 拆分意义 – 功能侧重点不同 – 报价服务 – 缓存+计算系统 – 对外接口响应时间是关键 – 抓取服务 – 定向抓取 – 整体吞吐量和获取率是关键 • 服务间通信 – 生产者消费者 – 异步通讯 实时报价搜索 • 异步化 – 消息中间件 – 线程池隔离 – 前端动态请求 实时报价搜索 • 消息中间件 – 用于报价计算服务和抓取服务之间的通信 – 方案选择 • activemq – 基于业务模式进行配置 • 不需要持久化 • 过期消息可以丢弃 – 直接丢弃 » • 提高吞吐量 – async send & async ack – 接收到消息后异步处理 • 可用性考量 – client端连接串配置成failover协议 实时报价搜索 • 消息中间件 实时报价搜索 • 线程池隔离 – 目的 • 提高性能 – 独立任务串行执行转并行执行 • 提高整体可用性 – 最大限度降低外部资源依赖失效的影响 – 使得整体吞吐量和响应时间可控 • 避免资源争用 – 关注点 • 线程池容量合理设置 • 任务超时设置 • 利用监控，持续运维 实时报价搜索 • 应用场景 实时报价搜索 • 应用场景 – 背景 • 用户提交一个酒店搜索，搜索列表页在得到符合条 件的酒店列表后，需要远程调用报价服务的接口获 取酒店报价 • 报价服务的任何问题都不能影响到搜索结果列表页 的展示 • 如果结果列表酒店数量太多，报价服务串行获取报 价效率较低，调用方等待时间较长 实时报价搜索 • 应用场景 – 解决方案 • 单独创建一个线程池来处理对报价服务的调用 • 对于超过一定阈值的酒店数的报价查询请求，拆成多个任务执行 – 设计考量 • 线程池配置 • 超时设置 – 经验值，我们一般是选择被调用方平均响应时间*10 • 超时后处理 – 任务需要能够响应中断 – 超时后要回收资源 – 超时需要记录监控 – 超时后需要将调用条件记录到日志中，供线下分析 实时报价搜索 • 应用场景 – 线程池参数选择 • corePoolSize – 该请求qps历史峰值*增长系数（1.5，依据业务预期而定）*调用外部接口 任务超时时间（s） • queue – LinkedBlockingQueue，无界队列，资源不可控，不考虑 – ArrayBlockingQueue，会产生任务等待，适合线下任务，只考虑吞吐量而 不关注响应时间时使用 – SynchronousQueue，Direct handoff，有任务立即尝试开线程执行，在关 注响应时间时选择 • maxPoolSize – max(该请求qps历史峰值*增长系数, corePoolSize) • rejection policy – 直接丢弃 – 记录监控 实时报价搜索 • 前端js动态请求 – 目的 • 报价服务不会等所有代理商都抓回报价 • 将最新报价及时展现给用户 – 设计考量 • 前端按照特定间隔poll报价服务接口 • poll的间隔根据以下因素动态改变 – 发送的报价抓取请求回数比例 – 随时间衰减 – 报价服务接口连续返回相同结果集的次数 实时报价搜索 • 缓存设计 – 进程内缓存的意义 • 提高整体性能 • 减少外部资源依赖，提高可用性 实时报价搜索 • 缓存设计 – 缓存分类 • 基础信息缓存 – 酒店的报价抓取元数据 – 全量缓存 »系统启动时加载 – 增量更新 • 报价缓存 – 进程内缓存 »LRU »命中率是关键 »多级策略 »控制读写锁粒度 – 分布式缓存 »memcached 实时报价搜索 • 构建内存缓存的基本原则 – 关注单个缓存对象的大小 – 要正确的使用数据类型 – 值域固定的字符串对象常量化 • String.intern() • 自定义String Pool – 要监控缓存命中率 – 要估算总的内存开销 – 缓存要有明确的容量上限 – 对于LRU缓存，不同业务数据尽量不要共用同一LRU队 列 实时报价搜索 • 报价多级缓存 – 目的 • 确保用户报价请求，即一级缓存的命中率 • 确保各代理商报价抓取结果合并时的缓存命中率 • 减少和memcached的通信开销 • 减少序列化反序列化的开销，控制负载 实时报价搜索 • 报价多级缓存 实时报价搜索 • 报价一级缓存命中率 实时报价搜索 • 内存缓存换出到memcached的次数优化前 后对比 实时报价搜索 • 从memcached换入到内存缓存的次数优化 前后对比 实时报价搜索 • Memcached的使用 – Slab Allocation Mechanism • 防止类似大小的不同业务数据缓存争用同一slab，导致eviction – 尽可能提高缓存命中率 • 保证memcached集群的总容量符合业务需要 • 缓存失效会导致对代理商网站的大量抓取 • 缓存一定要有合理的过期时间 • 定期主动清除过期数据，减少eviction – qmemcached-patch – 使用高效的序列化反序列化工具 • kryo – 确保可用性 • 监控和报警 • daemontools 实时报价搜索 • kryo替换java原生序列化/反序列化的效果 实时报价搜索 • 降低抓取量 – 目的 • 降低目标网站的负载 • 降低双方的成本 – 手段 • 为每个目标网站设置cachetime – 依据当前抓取量监控 – 依据目标网站房态房价变化频率监控 – 人工配置+动态调整 • 定时线下全量抓取配合线上用户触发抓取 • 与合作客户配合进行变价推送 运维和监控 • 意义 – 好的系统是运维出来的 – 及时发现问题 – 掌握系统运行状况 – 找出系统优化方向 – 为技术决策提供依据 • 分类 – 实时监控和运维脚本 – 监控系统 运维和监控 • 实时负载监控 运维和监控 • 实时日志监控 运维和监控 • 监控系统 Thank you for coming mail: yue.liu@ gtalk: the.6th.month@ 。