1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
//! Producer-side distribution policies built on the explicit-partition header.
//!
//! librdkafka's partitioner families (random, consistent, murmur2, fnv1a) cannot express
//! per-message round-robin, and keyless distribution may batch-stick to one partition. For
//! workloads with long, near-constant per-message processing times that unevenness turns into
//! one hot consumer and idle peers; [`RoundRobin`] stamps each outgoing reply with the next
//! partition in the cycle instead.
use ;
use ;
use crate;
/// A [`PublishTransform`] distributing replies round-robin across the first `count` partitions.
///
/// Each reply gets the [`PARTITION_HEADER`] of an incrementing counter modulo `count`, so the
/// publisher targets partitions 0..count in a cycle, one message each - the evenest possible
/// spread for long, near-constant-cost messages. A reply that already carries an explicit
/// partition or a record key is left alone: keys exist for ordering, and overriding either
/// would silently break the caller's placement.
///
/// The count is explicit on purpose (cheap and predictable); it must match the destination
/// topic's partition count, or the tail partitions simply receive nothing (a smaller count)
/// or publishes fail (a larger one).
///
/// # Examples
///
/// ```no_run
/// use ruststream::runtime::TypedPublisher;
/// use ruststream_rdkafka::{KafkaBroker, RoundRobin};
///
/// # #[cfg(feature = "json")]
/// # fn wire(broker: &KafkaBroker) {
/// let replies = TypedPublisher::new(broker.publisher()).transform(RoundRobin::partitions(8));
/// # let _ = replies;
/// # }
/// ```