Краткий ответ

Клоны Sender подключены к одной общей очереди, поэтому отправленное сообщение помещается в неё один раз. Каждый вызов получения извлекает следующий доступный элемент, и один элемент может быть получен только одним потребителем. Такая модель — распределение работы, а не широковещательная рассылка.

Исторический контекст

Каналы Rust основаны на модели обмена сообщениями: потоки взаимодействуют через передачу владения данными, не разделяя общую изменяемую память напрямую. Модель multiple producer, single consumer решает задачу безопасной передачи работ от множества производителей одному обработчику.

Позднее тот же принцип стали применять для пулов работников: несколько производителей отправляют задания, а рабочие потоки забирают их из общей очереди. Для рассылки одного события всем подписчикам требуется уже другая семантика канала.

Постановка проблемы

Предположим, несколько потоков создают задания, а несколько работников должны их обрабатывать. Если ошибочно ожидать от клонированных Sender поведения подписки, один и тот же заказ может быть обработан только одним работником, тогда как остальные его не увидят.

Это полезно для очереди задач, но неправильно для событий вроде «конфигурация обновилась», которые обязаны получить все подписчики. Выбор неподходящей модели приводит либо к пропущенным уведомлениям, либо к необходимости строить рассылку вручную.

Подробное решение

В std::sync::mpsc клонирование Sender создаёт ещё один дескриптор отправки в ту же логическую очередь. Оно не создаёт отдельную очередь и не превращает канал в набор независимых подписок.

Получатель извлекает сообщение из очереди, после чего оно там больше не находится. Поэтому два потребителя, синхронизированные через общий доступ к Receiver, не получают копии одного элемента: кто первым успешно выполнит получение, тот и заберёт владение сообщением.

use std::sync::mpsc;
use std::thread;

let (tx, rx) = mpsc::channel();
let tx2 = tx.clone();

thread::spawn(move || tx.send("A").unwrap());
thread::spawn(move || tx2.send("B").unwrap());

drop(tx);
for message in rx {
    println!("{message}");
}

В этом примере оба производителя отправляют данные в одну очередь, но каждое сообщение появляется у получателя один раз. Порядок сообщений от разных производителей не следует использовать как глобальный порядок событий; если он важен, его нужно задавать отдельно.

Для конкурентного пула работников std::sync::mpsc предоставляет одного Receiver, поэтому доступ нескольких потоков обычно организуют через синхронизацию вокруг получения. Это распределяет задания, но не превращает канал в broadcast-канал.

Если нужно доставить каждое событие всем подписчикам, применяют специальный broadcast-механизм или создают отдельный канал для каждого подписчика и явно отправляют сообщение в каждый из них. У такого решения выше стоимость памяти, отправки и управления жизненным циклом подписчиков.

Ситуация из практики

Сервис принимает HTTP-запросы и направляет задания в пул из четырёх работников. Вариант с общей очередью и одним логическим Receiver хорошо подходит: каждый заказ обрабатывается одним работником, а нагрузка распределяется без дублирования.

Вариант с четырьмя отдельными каналами потребовал бы диспетчера, который выбирает канал. Он даёт больше контроля, но усложняет балансировку: один работник может простаивать, пока очередь другого переполнена.

Если же те же сообщения являются уведомлениями для четырёх независимых подсистем, общая очередь непригодна: событие получит только одна подсистема. В этом случае выбран отдельный канал на подписчика и явная рассылка; затраты выше, зато семантика доставки соответствует требованиям.

Что кандидаты часто упускают

Означает ли клонирование Sender, что каждый получатель получит копию сообщения?

Нет. Клонируются права отправки, а не сообщение и не очередь для каждого получателя. Отправка передаёт один элемент в общую очередь, поэтому для копирования нужны отдельные отправки или специальный broadcast-канал.

Что произойдёт, если один из клонов Sender будет уничтожен?

Канал не считается закрытым, пока существует хотя бы один Sender. Получатель увидит окончательное завершение только после уничтожения последнего отправителя; поэтому лишние клоны важно явно удалять, когда они больше не нужны. Иначе потребитель может продолжать ждать сообщения бесконечно.

Можно ли превратить std::sync::mpsc в полноценную рассылку, обернув Receiver в Arc<Mutex<_>>?

Нет. Такая обёртка позволяет нескольким потокам безопасно по очереди извлекать элементы, но каждый элемент всё равно получает только поток, захвативший mutex и выполнивший получение. Для рассылки необходимо либо отправлять отдельную копию в канал каждого подписчика, либо использовать канал с явно поддерживаемой broadcast-семантикой.