趋势分析
广告引擎系统涉及业务趋势:
Ø搜索广告召回依赖商品品牌与类目
关键词通过语义分析出品牌与类目
利用商品、关键词的品牌与类目,进行广告召回
Ø搜索广告召回依赖人群定向策略
识别特征人群、定向召回广告
广告检索系统支持定向策略更新
Ø搜索广告召回依赖更多的广告属性筛选
关键词通过语义分析出品牌与类目,其他的属性
利用商品、关键词的品牌与类目,进行广告召回,并根据其他的属性进行筛选
Ø搜索广告召回需过滤无效商品及店铺
广告检索系统支持商品寻源,文本价格等实时性数据更新
广告检索系统支持店铺实时性数据更新
广告引擎系统涉及性能趋势
Ø搜索广告召回面临高性能挑战
促销期间支持TPS>1W
促销期间平均响应时间<20ms,最高响应时间<50ms
促销期间支撑广告物料数据更新频次1秒钟1000,延迟时间<1分钟
促销期间支撑广告物料>3G,数据量1000万
单次检索数据量:500条
技术决策最终目标
1,满足索引量超过1000万。
2,满足索引查询条件添加到7-10个条件,召回量>200。
3,满足性能TPS>1W,响应时间20-50ms内。
4,满足分布式,可靠性(索引持久化)。
可选技术方案
SOLRCLOUD |
SOLR Master/Slave |
自主研发 |
ElaticSearch |
性能比较
公共条件
业务功能 | 单品推广(app/pc)
|
广告物料数量级 | 200万/500万/1000万 |
物料更新频次 | 1分钟60次/1秒100次/1秒800 |
提交索引 | 实时/延时 |
单次数据检索量 | 200条/1000条
|
最小服务组合 | 单机/最新组合 |
是否分片 | 分片/非分片 |
压测方式 |
|
分析结果(结果依赖于作者工作环境,仅作为参考)
分析效果的方法:
1)压测寻找系统瓶颈。
2)压测观察线程状态,堆的消耗,GC情况,CPU消耗。
3)压测过程性能分析CPU资源和内存资源消耗非常大的程序方法。
业务功能 | 广告物料数量级 | 物料更新频次 | 更新索引频次 | 单次数据检索量 | 最小服务组合 | 是否分片 | 压测方式 | SOLRCLOUD | SLOR(全内存)(Master/Slave) | 自主研发 | ES | |||||||
单品推广 | 200万 | 1秒钟10 次 | 1000条/5秒软提交条 | 200条 | 单机 (2C4G) | 非分片 | http | TPS:149.05 平均响应时间: 资源消耗:98% | TPS:267.57 平均响应时间: 0 资源消耗: 98% |
|
| |||||||
单品推广 | 200万 | 1秒10次 | 1000条/5秒软提交条 | 200条 | 2台 | 非分片 | http | TPS:496.25 平均响应时间: 资源消耗:CPU:60% | TPS:370.35 平均响应时间: 资源消耗: |
|
| |||||||
单品推广 | 2万 | 1秒10次 |
| 200条
Query查询 | 2台 | 非分片 | http |
|
|
| TPS:500 平均响应时间: 资源消耗:CPU:75% | |||||||
单品推广 | 2万 | 1秒10次 |
| 200条 Query查询 | 2台 | 2个分片 | http |
|
|
| TPS:510 平均响应时间: 资源消耗:CPU:75% | |||||||
单品推广 | 2万 | 1秒10次 |
| 200条
Filter查询 | 2台 | 2个分片 | http |
|
|
| TPS:4000 平均响应时间: 资源消耗:CPU:75% | |||||||
单品推广 | 200万 | 1秒10次 |
| 200条 Query查询 | 2台 | 2个分片 | http |
|
|
| TPS:220 平均响应时间: 资源消耗:CPU:90% | |||||||
单品推广 | 10万(商品数据) | 1秒10次 | 1秒提交10次 | 200条 | 单机2C4G | 非分片 | http |
|
| TPs:1203 平均响应时间: 资源消耗: |
| |||||||
单品推广 | 20万(商品数据) | 1秒 50次 | 1秒提交10次 | 200条 | 单机8C16G | 非分片 | http |
|
| TPS:2230 平均响应时间: 资源消耗: |
|
高可用对比(作者的实战经验,仅作为参考)
高可用 | SolrCloud | Solr | 自主开发 | ES |
读写分工(保证稳定性) | 读的过程不区分Leader和replica,同步读取shard数据进行merge 写的过程直接写入Leader,由Leader进行分发 根据document Id hash到不同的 数据同步采用Leader分发,同步接收数据。
| 读的过程,根据特定分片方式 (PID)直接定位shard,Nginx进行负载均衡,访问slave机器 读写机器分离、保证写入和读取互不干扰! 读写分开优化性能提升! 写的过程直接定位master机器。 写机器的负载采用nginx,根据特定分片方式(PID)直接进行shard。 数据同步采用slave主动拉取。 需要自定义路由策略 master/slave 角色清晰明朗。 | 可以采用 去主从复制。
采用各自消费各自数据。
| 类似于SolrCloud netty 相对而言,效率更高
|
负载均衡 | LBHttpSolrServer 写采用shard负载 (轮询方式)
| 采用Nginx进行负载(自定义) | 采用Nginx进行负载(自定义) | 集群方式discover |
分布式 | 写入采用documet ID hash算法写入
读取采用并发从shard中获取数据进行数据merger
| 自定义路由策略 (读写共享路由策略) 提升性能。
| 自定义路由策略 (读写共享路由策略) 提升性能。
| 分布式 node 与shard的关系 可以1对多
合理的分片能够提升写入效率 |
可扩展性 | shard 增加replica
| 自定义路由,shard策略。 (需要自定义扩展)
增加master/slave 可以提升负载能力 (需要修改nginx配置
| 自定义路由,shard策略。 (需要自定义扩展)
增加master/slave 可以提升负载能力 (需要修改nginx配置)。
| shard 增加replica
|
高可用性 | leader和replica是同一shard的相同数据,存放在不同的主机上 | 同一shard数据,存在多个master/salve内。 master机器进行高可用策略。(nginx 负载实现高可用)
| 检索机器集群化 索引机器自定义集群化
| master和slave是同一shard的相同数据,存放在不同的主机上 |
数据一致性 | 一致性与读写性能是个矛盾的指标 SolrCloud选择了一致性而适当放弃了写的性能 数据写入Leader,Leader负责分发,同步分发。
| 不强一致性, 可以做到最终一致性! (需要自定义修改) 后续采用数据重推 或者kafka(独立消费)
| 不强一致性 最终一致性。
| 主分片写完,在同步到副本分片上,等待所有的分片写完才返回成功 |
简单性(恢复与部署速度) | 机器恢复后,自动复制数据。 Leader宕机,在发送的更新数据已经失败。 replica宕机,重新启动就行
| master宕机; 在发送的更新数据已经失败(后续考虑考虑异步消息发送)。 slave宕机,重新启动就行、并更新索引数据
| 索引系统宕机 检索系统正常保证服务。 如果索引系统与检索系统同时宕机,先恢复索引系统,再回复检索系统。
| 机器恢复后,自动复制数据。 master宕机,在发送的更新数据已经失败。
slave宕机,重新启动就行
|
伸缩性(删减服务器) | SolrCloud支持将一份shard分成两份小的shard | shard分片(需要自定义) 提前考虑后续的分片(3片) 后面提供扩展方案(*)
| shard分片(需要自定义) 提前考虑后续的分片(3片)
| 支持将一份shard分成两份小的shard |
配置信息(动态配置) | zookeeper集中管理 所有solr node节点,获取zookeeper配置信息
| zookeeper集中管理
| zookeeper集中管理
| 集群方式discover |
容错(数据可重复性、可校验) | Leader节点宕机 会自动选举 Replica宕机会从 恢复数据 会自动剔除Dwon的机器(采用Overseer+watch)
| 宕机之后,nginx自动剔除无用机器。 master手动维护 (写入机器也采用nginx做负载)。
| 宕机之后,nginx自动剔除无用机器。 master手动维护 (写入机器也采用nginx做负载)。
| master节点宕机 会自动选举 slave宕机会从 恢复数据 会自动剔除Dwon的机器(采用Overseer+watch)
|
集群管理 | 完全依赖zookeeper | 依赖zookeeper | 依赖zookeeper | 集群方式discover |