基于线程池的线上服务性能优化

开发
需求,总是自我技术提升,架构升级优化的动力源。

最近居家办公。 正在发愁摸哪条鱼的时候,产品突然在群里at了我一下,说到某某订单曝光异常,让配合看看。

仔细询问了下订单信息,乖乖,原来用的是6年前开发的一个功能,要知道这个功能自上线后基本很少用,不知道为什么现在开始用起来了,只能先放弃摸鱼,先配合解决问题,毕竟要靠这个来吃饭的。

需求背景

在广告中,经常有这样一种需求场景,需要将某个广告定向投放给某一批指定用户。即假设有一个adid,指定了投放用户1和用户2,那么只有在用户1和用户2的流量请求过来的时候,才会返回给adid,而其他用户的流量,均不会返回该adid。

一般情况下,指定用户多达几百万个甚至上千万个,将这些用户ID直接随着广告订单推送过来,显然不切实际,所以当时的设计方案是广告主将包含有指定用户ID的数据包上传到广告后台,然后生成一个url,而该url则随着广告订单推送过来。在引擎中,有个服务专门订阅了广告订单消息,如果发现该广告订单是指定用户投放,则将url指向的数据包中的数据获取后,进行实时加载,这样当其用户ID流量过来的时候,就能匹配上该广告。

初始设计

在开始本节之前,我们不妨先思考几分钟,如果让你来实现这个功能,该如何实现呢?

好了,让我们把时间调回到2016年年底,产品提出该需求的时间点。

当时看了该需求,还是蛮简单的。为了便于内容理解,将加载定向包的服务称之为Retargeting。

Retargeting服务就两个基本功能:

  • 订阅广告订单消息队列
  • 如果获取到了有定向包的广告订单,则下载该定向包,然后获取里面的数据,建立倒排索引

是不是很简单,代码也非常好写,下载定向包可以使用libcurl,也可以使用wget进行下载然后读取文件加载到内存,当时因为排期比较紧张,所以选择了wget方式来实现,因为数据量比较大,所以使用redis作为倒排索引的存储媒介。

假设有一个广告订单我们称之为ad,其包含一个定向包地址url,此时会做如下几件事:

1、使用如下命令进行下载url所指向的定向包

auto cmd = "wget -t 3 -c -r -nd -P /data1/data/ –delete-after -np -A .txt http://url.txt";
auto fp = popen(cmd.str().c_str(), "r");
if (!fp) {
return;
}

2、以文件形式打开该包

// 获取本地包地址,如/data1/data/url.txt
fp = fopen(path.c_str(), "r");
std::string id;
char buf[128] = {'\0'};
while (fgets(buf, 128, fp)) {
id = buf;
boost::replace_all(id, " ", "");
boost::replace_all(id, "\r", "");
boost::replace_all(id, "\n", "");
noost::replace_all(id, "\^M", "");
if (!id.empty()) {
ids.emplace_back(id);
}
}

3、Redis中建立倒排索引

for (auto item : ids) {
redis_client_->SAdd(item, adid);
}

好了,到了此处,Retargeting服务功能已经基本都实现了。

在召回引擎中,当流量来了之后,会先以用户ID为key,从redis中获取指定投放该设备ID的adid,然后返回。

代码编译完后,在测试环境下了个单,推送,然后模拟请求,召回,完美。

问题初现

定向包功能,尤其是对于KA广告主,是不屑使用的,毕竟他们财大气粗,要的就是 脑白金 似的推广效果,即 「只关注展示量,而不在乎是否有效果」 。奈何随着国家政策的一步步调整,广告行业都开始勒紧裤腰带过日子,之前的大广告主也开始关注投放效果了,毕竟 品效合一 嘛。于是,他们开始挖掘了一批用户,在后台开始投放,尝试投放效果。随着此类定向包订单越来越多,之前实现的Retargeting也开始出现瓶颈了。。。

毕竟该功能使用不多,所以大部分情况下,产品或者运营提出问题的时候,都会找个借口搪塞回去。直到某一天,产品直接甩出来一张图,说某个部门老大非常看重的一个广告主的定向包投放曝光为0,并扬言当天解决不了,就通过其它渠道进行投放。。。

既然是部门老大都找过来了,那就不得不找下原因了,于是从订单的url是否有效开始查起,定向包设备的有效覆盖率,一直到整个订单的推送时间,一切都正常,看来问题出在ReTargeting服务了,服务正常,加载也正常,无意间看了下消费进度,不看不知道,一看吓一跳。才刚刚消费到昨天的订单,也就是说当天要投放的订单还没开始加载,怪不得还没有曝光,就这进度,有曝光才怪。

顺便看了眼服务状态,乖乖,CPU占用这么低。。。

尝试优化

既然CPU占用这么低,那么有没有可能从CPU占用这个角度进行优化呢,提升CPU占用,提高服务处理能力,这样就能加快其加载速度了。对于这种,一般稍微有点经验的,就会知道该怎么优化,对,就是使用 多线程 。

既然决定使用多线程,那么就得彻底点,多线程处理订单,在每个订单中,又采用多线程进行数据加载和处理,我们暂且称之为 M*N 多线程设计模型,如下:

在上图中,采用多线程方式对Retargeting服务进行优化,假设此时有m个定向包订单,则会同时有m个线程进行处理,每个线程处理一个定向包订单,看起来很完美,等等,会不会有其他问题呢?要不然一开始为什么就不这么设计呢?

大家知道,对于多线程程序, 「线程的执行顺序,完成时间是不可控的」 ,使用上述设计方案,如果多个线程 「同时处理多个不同的订单,那么是没有任何问题的」 ,但是,如果对于另外一种场景,该方案就不可行了,如下:

假设此时销售创建了一个定向包订单ad0,先推送上线。然后发现订单有问题,所以随即推送下线。那么此时消息队列中有两条消息,先是ad0的上线消息,然后是ad0的下线消息。基于上述多线程设计模型,假设 线程1执行订单上线,线程2执行订单下线 ,可能的结果就有如下几种:

  • 先执行上线订单加载,再执行下线订单加载,此种情况符合预期
  • 下线订单先完成,然后上线订单完成,此种情况最终与我们期望的相反
  • 上线订单和下线订单同时执行,且中间交叉进行,结果不可控

很明显,该种方案不可行,尽管其最大可能地优化了性能,但是得不到正确的结果,即使性能再好,又有啥用呢?

难道多线程设计模型真的不适用于我们这个服务吗?

不妨调整下思路,在上述的方案分析中,多个线程同时处理多个订单就会有问题,换句话说在M*N多线程设计模型中,正是因为M>1导致了结果不可预期,那么如果M=1呢?这样会不会就会避免上述问题呢?

我们仍然以上述案例进行举例,因为是单线程处理消息队列,那么永远都是先处理上线消息,然后再处理下线消息,这样的结果永远符合我们的预期。

既然方案已经定了,那么就可以直接写代码了。在该方案中,我们用到了多线程进行处理,如果每次来了订单消息都创建多个线程进行处理,处理完成后,销毁线程。虽然也可以这么做,但多少对性能有所影响,所以干脆使用 线程池 来完成吧。base库中有之前手撸的线程池,直接拿来使用。

for (auto did : ids) {
thread_pool.enqueue([did, adid, this]{
RedisClient client;
redis_client_pool_.Pop(&client);
if (client) {
client->SAdd(did, adid);
redis_client_pool_.Push(client);
}
});
}
}

编译、部署、测试,一气呵成,没问题。开始上线,上线完成,看了下CPU利用率,完美:

数据说话,对比下优化前后同一个订单的处理时间:

性能提升接近30倍,符合预期。。。

需求,总是自我技术提升,架构升级优化的动力源。有时候,一个简单的小优化,就能达到事半功倍的效果。

责任编辑:张燕妮 来源: 高性能架构探索
相关推荐

2012-12-24 09:55:15

JavaJava WebJava优化

2011-07-19 10:46:49

Windows 7优化

2023-03-08 18:43:50

GPU模型隔离

2010-01-08 09:43:23

SQL Server分Analysis Se

2021-11-18 10:05:35

Java优化QPS

2021-05-19 08:04:11

ASP.Net服务性原则

2009-11-05 10:45:58

WCF服务

2022-11-10 08:16:19

java性能服务性能

2021-06-30 10:16:54

微服务架构测试

2017-09-26 14:56:57

MongoDBLBS服务性能

2012-04-26 14:08:52

2021-07-06 12:07:27

Go 服务性能

2020-12-14 15:40:59

Nodefastifyjs

2020-12-28 08:48:44

JS工具fastify

2011-07-22 09:50:34

云服务云计算

2015-12-30 19:19:37

云存储

2009-11-06 17:10:34

WCF服务性能计数器

2013-04-10 09:26:59

智能网络云服务

2020-12-14 08:55:00

Node.js服务性框架

2013-04-09 15:44:12

智能网络云服务网络性能
点赞
收藏

51CTO技术栈公众号