趋势分析
广告引擎系统涉及业务趋势：
Ø搜索广告召回依赖商品品牌与类目
关键词通过语义分析出品牌与类目
利用商品、关键词的品牌与类目，进行广告召回
Ø搜索广告召回依赖人群定向策略
识别特征人群、定向召回广告
广告检索系统支持定向策略更新
Ø搜索广告召回依赖更多的广告属性筛选
关键词通过语义分析出品牌与类目，其他的属性
利用商品、关键词的品牌与类目，进行广告召回，并根据其他的属性进行筛选
Ø搜索广告召回需过滤无效商品及店铺
广告检索系统支持商品寻源，文本价格等实时性数据更新
广告检索系统支持店铺实时性数据更新
广告引擎系统涉及性能趋势
Ø搜索广告召回面临高性能挑战
促销期间支持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 |