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

Posted 2021-12-10 QcloudCommunity

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了基于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)

作者简介