当前位置: 首页 > >

一次架构方案选型评估过程

发布时间:

趋势分析

广告引擎系统涉及业务趋势:


?搜索广告召回依赖商品品牌与类目


关键词通过语义分析出品牌与类目


利用商品、关键词的品牌与类目,进行广告召回


?搜索广告召回依赖人群定向策略


识别特征人群、定向召回广告


广告检索系统支持定向策略更新


?搜索广告召回依赖更多的广告属性筛选


关键词通过语义分析出品牌与类目,其他的属性


利用商品、关键词的品牌与类目,进行广告召回,并根据其他的属性进行筛选


?搜索广告召回需过滤无效商品及店铺


广告检索系统支持商品寻源,文本价格等实时性数据更新


广告检索系统支持店铺实时性数据更新


?


广告引擎系统涉及性能趋势

?搜索广告召回面临高性能挑战


促销期间支持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

*均响应时间:
最大响应时间:2559
最小响应时间:0

资源消耗:98%

TPS:267.57

*均响应时间:
最大响应时间:
最小响应时间:

0

资源消耗:

98%

?

?

单品推广

200万

1秒10次

1000条/5秒软提交条

200条

2台

非分片

http

TPS:496.25

*均响应时间:
最大响应时间:1674
最小响应时间:2

资源消耗:CPU:60%
内存:100%

TPS:370.35

*均响应时间:
最大响应时间:
最小响应时间:1

资源消耗:
CPU:98%
内存:100%

?

?

单品推广

2万

1秒10次

?

200条

?

Query查询

2台

非分片

http

?

?

?

TPS:500

*均响应时间:
最大响应时间:1000
最小响应时间:2

资源消耗:CPU:75%
内存:90%

单品推广

2万

1秒10次

?

200条

Query查询

2台

2个分片

http

?

?

?

TPS:510

*均响应时间:
最大响应时间:1000
最小响应时间:2

资源消耗:CPU:75%
内存:90%

单品推广

2万

1秒10次

?

200条

?

Filter查询

2台

2个分片

http

?

?

?

TPS:4000

*均响应时间:
最大响应时间:180
最小响应时间:1

资源消耗:CPU:75%
内存:90%

单品推广

200万

1秒10次

?

200条

Query查询

2台

2个分片

http

?

?

?

TPS:220

*均响应时间:
最大响应时间:600
最小响应时间:2

资源消耗:CPU:90%
内存:90%

单品推广

10万(商品数据)

1秒10次

1秒提交10次

200条

单机2C4G

非分片

http

?

?

TPs:1203

*均响应时间:
20
最大响应时间:
1000
最小响应时间:
0

资源消耗:
CPU:80%
内存:100%

?

单品推广

20万(商品数据)

1秒

50次

1秒提交10次

200条

单机8C16G
JVM 4G

非分片

http

?

?

TPS:2230

*均响应时间:
17
最大响应时间:
800
最小响应时间:
0

资源消耗:
CPU:50%
内存:80%

?


?


高可用对比(作者的实战经验,仅作为参考)

高可用

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 负载实现高可用)

?

检索机器集群化

索引机器自定义集群化

?

masterslave是同一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



友情链接: