Hi all,

I'd like to propose a new client-side load balancer for brpc: *p2c* —
Power-of-Two-Choices with Peak-EWMA latency scoring (Finagle p2cPeakEwma /
Envoy LEAST_REQUEST / linkerd style).

*Why*
brpc's only latency-aware LB is la, which keeps a global weight tree (O(log
N) select) over an averaging window. It has no P2C sampler and reacts
slowly to a single degraded backend (GC pause, noisy neighbor) or a
heterogeneous fleet. P2C is the most widely deployed tail-latency policy in
modern RPC stacks and is currently absent from brpc.

*What*
Per request: sample two random backends, route to the lower
    score = ewma_us * (inflight + 1) / max(weight, 1)
A peak-sensitive EWMA sheds a stalled node within one sample; selection is
O(1). On completion, update the chosen backend's EWMA and in-flight count
(failure/timeout inflates latency so a failing node is avoided).

*No core change needed*
Every hook this needs already exists and is exercised by la:
SelectOut::need_feedback, virtual Feedback(CallInfo), and the
completion-path invocation in controller.cpp. New files only:
src/brpc/policy/p2c_ewma_load_balancer.{h,cpp}, registration in global.cpp,
a unit test in all three build systems, and a docs row.

I'm happy to implement this end-to-end (balancer + unit tests + docs + a
multi-protocol benchmark matrix across baidu_std / memcached / redis /
mysql / http). Full proposal and primary-source references are in the issue:
https://github.com/apache/brpc/issues/3340

Would the maintainers be open to a p2c policy? Happy to scope it on the
issue or here, whichever you prefer.

Thanks,
Varun Raj

Reply via email to