基于Protobuf共享字段的分包和透传零拷贝技术,你了解吗?
导语 | 本文通过介绍实现Protobuf共享字段Guard,并将其应用于中控/召回场景,并获得了显著CPU/时延收益。即使不使用Guard,希望本文的经验和思路也能为读者带来一些帮助和参考。
引言
在推荐系统中,用户级的字段常常需要贯穿整条链路,例如,实验参数,行为序列,用户画像等等。
召回/过滤/排序等模块都需要用户特征,此时最好的方法自然是从请求开始时一次性获取,然后一路透传下去。此前笔者的写法常常是:
const GetRecommendReq & oReq;//from rpc
RankReq oRankReq;
oRankReq.mutable_user_portrait()->CopyFrom(oReq.user_portrait());
这样的透传自然有好处,例如,下游如果需要用户特征,不需要再每个请求去请求一次。尤其是上游发起分包时,透传用户级别特征能够显著减少下游获取用户特征的RPC开销。
然而,RPC开销减少了,再得陇望蜀想一想,是否能直接省去这个CopyFrom的开销呢?
我们知道,protobuf提供了Allocated/Release系列接口,通过直接转移指针所有权的方式消除Copy或Swap的开销。
换个思路,如果不是转移指针所有权,而是借出指针所有权,就能够实现共享字段了。所谓借,其实就是在使用前把字段指针转移,但在使用结束后立刻收回(收回所有权以防被delete)。而这正是经典的Guard抽象。
当然,即使不使用Guard,相信上面这个思路已经足够提供一些帮助了。我们可以直接使用pb的接口实现:
const GetRecommendReq & oReq;//from rpc
GetRecommendReq & oMutableReq = const_cast<GetRecommendReq &>(oReq);
RankReq oRankReq;
oRankReq.set_allocated_user_portrait(oMutableReq.mutable_user_portrait());
Client.Rank(oRankReq);
oRankReq.release_user_portrait();
对于一些更复杂的操作,例如我想要拷贝部分字段,共享部分字段,修改部分字段(分包的场景),我们在下文给出了我们的解决方案。
设计
我们的Guard提供了两个接口,分别是Attach和Detach,接口如下。实现通过pb的反射机制,使得release和set_allocated能够相互绑定,实现Guard析构时回滚。
void AttachField(Message* pMessage, int iFieldId, Message* pFieldValue);
Message* DetachField(Message* pMessage, int iFieldId);
AttachField:先把字段set_allocted借给pMesage,Guard析构后回滚释放,以防双重delete。
DetachField:先把pMessage的字段release借出,Guard析构后回滚归还,以防内存泄漏。
回滚的顺序是FILO,也就是严格按照相反的顺序(因为release和set_allocated并非严格对称,如果在成环的情况下可能会有问题)。
由于C++的构造和析构也是FILO(https://isocpp.org/wiki/faq/dtors#order-dtors-for-locals),一定要在pb初始化后再初始化Guard。
这两个接口已经足够满足在我们的业务中存在的几种抽象:
(一)主调透传/分包
把上游传递的某个字段,零拷贝传入下游的请求。此时直接Attach字段即可。
//usecase:
const AReq & oAReq;
BReq oBReq;
SharePbFieldGuard guard;
guard.AttachField(&oBReq, BReq::BigFieldId, const_cast<AReq &>(oAReq).mutable_bigfield());
(二)被调分包
控制某些字段不同,而其他字段共享/相同。为了避免拷贝大字段,我们可以在拷贝前先释放这些重的字段;拷贝结束后,把重字段共享给所有的分包。使用CopyFrom好处在于,我们不需要为所有新增的字段都手动判断,只需要特殊处理重的字段即可。
//usecase:
Req & oReq;
std::vector<Req> vecMultiReq(n);
SharePbFieldGuard guard;
auto* pField = guard.DetachField(&oReq, Req::BigFieldId);
for(auto && oSingleReq: multiReq)
{
oSingleReq.CopyFrom(oReq);
oSingleReq.set_field(...);
guard.AttachField(&oSingleReq, Req::BigFieldId, pField);
}
(三)多字段共享写法(以下是一段脱敏的实际代码)
由于操作的指针都是Message*类型,可以直接用容器存储pb index到字段指针的映射关系。通过循环即可共享所有重字段。
std::vector<uint32_t> vecHeavyField{};//初始化为一组fieldId
SharePbFieldGuard oGuard;
std::unordered_map<uint32_t, ::google::protobuf::Message*> mapIndex2Message;
for(auto uField: vecHeavyField)
{
mapIndex2Message[uField] = oGuard.DetachField(&oReq, uField);
}
for (auto && oSingleReq: vecReq)
{
oSingleReq.CopyFrom(oReq);
//shared filed
for(auto uField: vecHeavyField)
{
oGuard.AttachField(&oSingleRecallReq, uField, mapIndex2Message[uField]);
}
}
展望
安全性:因为回滚时set_allocated会delete掉原本的字段,假如成环可能会很危险,如何侦测这种情况。
性能:是否存在不使用反射,就能自动绑定set_allocated和release的方法?
Repeated字段支持:怎样处理Repeatd字段不同的反射接口?
(https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.message#repeated-field-getters)
作者简介
朱文杰
腾讯后台开发工程师
腾讯后台开发工程师,毕业于上海交通大学,知乎笔名朝闻君,目前负责微信公众平台推荐系统后台的开发和优化。
推荐阅读
深度解读!新一代大数据引擎Flink厉害在哪?(附实现原理细节)
大咖共探万物智联时代风云!Techo TVP物联网开发者峰会圆满落幕