redis请求的上下文id是怎么关联的 貌似没有找到

[tmacjay2015]

1. bool FiberTcpConnComplexConnector::MessageHandleFunction(const ConnectionPtr& conn, std::deque& rsp_list) {

2. bool conn_reusable = true;

3. for (auto&& rsp_buf : rsp_list) {

4. ProtocolPtr rsp_protocol;

5. bool ret = options_.trans_info->rsp_decode_function(std::move(rsp_buf), rsp_protocol);

6. if (TRPC_LIKELY(ret)) {

7.   TRPC_ASSERT(rsp_protocol);

8.   conn_reusable &= rsp_protocol->IsConnectionReusable();

9.   uint32_t id = 0;

10.   rsp_protocol->GetRequestId(id);

11.   auto ctx = call_map_->TryReclaimContext(id);   **// redis协议如何恢复这个上下文 貌似reqid再redis协议中没有透传逻辑**

12.   if (TRPC_UNLIKELY(ctx.Get() == nullptr)) {

13.     // The request corresponding to the response cannot be found,

14.     // and the request may have timed out, so it will not be processed

15.     TRPC_LOG_WARN("can not find request, request_id: " << id << ", maybe timeout");

16.     continue;

19. }

22.   if (ctx->backup_request_retry_info == nullptr) {

23.     ctx->rsp_msg->msg = std::move(rsp_protocol);

25.     DispatchResponse(std::move(ctx));

26.   } else {

27.     if (!ctx->backup_request_retry_info->retry->IsReplyReady()) {

28.       ctx->rsp_msg->msg = std::move(rsp_protocol);

30.       DispatchResponse(std::move(ctx));

31.     } else {

32.       TRPC_LOG_WARN("Get response late when retry, if too many this log, consider a bigger retry delay");

33.       DispatchException(std::move(ctx), TrpcRetCode::TRPC_INVOKE_UNKNOWN_ERR, "");

34.     }

35.   }

36. } else {

37.   conn_reusable = false;

38.   break;

39. }

40. }

41. return conn_reusable;

42. } 如以上代码11行的疑问 麻烦解答下 谢谢

[yujun411522]

一般对于共有协议，比如http,redis协议，因为协议中没有关联ID，所以一般采用独占链接模式(对应到代码中说法就是链接池，对应代码是fiber_tcp_conn_pool_connector.cc) 也就是请求在没有处理完成之前，这个链接是被这个请求独占不能被其他请求使用，所以有响应回来的话只可能是这个请求的，直接取出来对应上下文处理即可。

而对于一些私有协议，比如trpc协议，brpc协议，就可以在协议中定义一个关联ID，这样的话，每个响应回来之后就能根据关联ID对应上这个响应对应的请求，所以可以做到一个链接同时处理多组请求响应，称之为链接复用模式，也就是上面提到的FiberTcpConnComplexConnector类，有一个TryReclaimContext(id)逻辑。

[tmacjay2015]

一般对于共有协议，比如http,redis协议，因为协议中没有关联ID，所以一般采用独占链接模式(对应到代码中说法就是链接池，对应代码是fiber_tcp_conn_pool_connector.cc) 也就是请求在没有处理完成之前，这个链接是被这个请求独占不能被其他请求使用，所以有响应回来的话只可能是这个请求的，直接取出来对应上下文处理即可。

而对于一些私有协议，比如trpc协议，brpc协议，就可以在协议中定义一个关联ID，这样的话，每个响应回来之后就能根据关联ID对应上这个响应对应的请求，所以可以做到一个链接同时处理多组请求响应，称之为链接复用模式，也就是上面提到的FiberTcpConnComplexConnector类，有一个TryReclaimContext(id)逻辑。

了解 后续是否考虑在http协议头中添加自定义的id用来实现链接复用逻辑类似grpc协议的逻辑 另外比如kafka这种原生协议就支持添加上下文id作透传 后续trpc在扩展协议插件的是时候是不是可以考虑支持 链接池模式的资源利用率我感觉还是没有链接复用的高

追问一个问题: 鹅厂内部的trpc框架配置目前都是静态生效嘛 比如proxy配置或者其他插件调用链插件配置（如果需要扩展采样策略 希望采样策略热变更）是否支持平台动态生效