首页 文章详情

基于Protobuf共享字段的分包和透传零拷贝技术,你了解吗?

云加社区 | 243 2021-11-14 13:03 0 0 0
UniSMS (合一短信)


导语 | 本文通过介绍实现Protobuf共享字段Guard,并将其应用于中控/召回场景,并获得了显著CPU/时延收益。即使不使用Guard,希望本文的经验和思路也能为读者带来一些帮助和参考。


引言


在推荐系统中,用户级的字段常常需要贯穿整条链路,例如,实验参数,行为序列,用户画像等等。


召回/过滤/排序等模块都需要用户特征,此时最好的方法自然是从请求开始时一次性获取,然后一路透传下去。此前笔者的写法常常是:


const GetRecommendReq & oReq;//from rpcRankReq 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 rpcGetRecommendReq & 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厉害在哪?(附实现原理细节)

终于!12年后Golang支持泛型了!(内含10个实例)

揭秘!用标准Go语言能写脚本吗?

大咖共探万物智联时代风云!Techo TVP物联网开发者峰会圆满落幕





good-icon 0
favorite-icon 0
收藏
回复数量: 0
    暂无评论~~
    Ctrl+Enter