Как добавить элемент в отсортированный массив?

[voraa]

а вот кейс проверки всей очереди выглядит как узкое место, если очередь длинная. Здесь и надо как-то оптимизировать.

Тут все дело в конкретных условиях. Если в очереди тысячи запросов, то как то надо оптимизировать. Если десятки, то вся эта оптимизация съесть все время.

[Alexandroppolus]

Например освободились А и Б. Но в очереди есть А-Б и приходит запрос Б-А. Усложняется алгоритм выбора, какой запрос исполнять.

При освобождении А и Б, из очереди немедленно будет забрана задача А-Б. Запрос Б-А никак не сможет воткнуться между этими действиями и в любом случае добавляется в очередь.

Меня тут больше смущает другой кейс: обрабатывается А-Б, в очереди сидит А-С, пришёл запрос С-Д. Вроде как он свободен и можно запускать, но тогда для участника С он выполнится до предыдущего. Если так нельзя, то надо проверять участников не только в хешмэпе текущих обрабатываемых, но ещё в хешмэпе персональных очередей, о котором я говорил выше. И если там нашлось, то ставить в очередь.

[Alexandroppolus]

Тут все дело в конкретных условиях. Если в очереди тысячи запросов, то как то надо оптимизировать. Если десятки, то вся эта оптимизация съесть все время.

Ну это понятно мы тут обсуждаем оптимизацию, предполагая что там дохрена всего и оптимизировать надо )

[Aetae]

Ну если там ТАК много запросов, тут тут уж пора кластеризацию обсуждать, микросервисы там, Redis, Kafka, связность, отказоустойчивость...

А на деле у автора вопроса там по 3,5 запроса в час.)

[voraa]

Меня тут больше смущает другой кейс: обрабатывается А-Б, в очереди сидит А-С, пришёл запрос С-Д. Вроде как он свободен и можно запускать, но тогда для участника С он выполнится до предыдущего. Если так нельзя, то надо проверять участников не только в хешмэпе текущих обрабатываемых, но ещё в хешмэпе персональных очередей, о котором я говорил выше. И если там нашлось, то ставить в очередь.

И всего этого можно избежать, если просто сразу поставить в очередь

[webgraph]

Ну если там ТАК много запросов, тут тут уж пора кластеризацию обсуждать, микросервисы там, Redis, Kafka, связность, отказоустойчивость...

А на деле у автора вопроса там по 3,5 запроса в час.)

Для чего использовать эти комбайны? Одно дело, когда запросов приходит много и они всякие разные. И совершенно другое дело, когда запросов приходит много одинаковых.

Это тоже самое, что использовать WordPress или Bitrix для одностраничного сайта с одним номером телефона. Мало того, что они сами по себе тормозы лютые, так и ещё самое главное — зачем?

Готовые решения здесь совершенно неуместны, потому что они все избыточны, создают дополнительные зависимости, требуют бОльших мощностей и значительно отбирают скорость.

Исходя из логики программы — большинство запросов должны быть уникальными и выполняться сразу без использования очередей. Но мы должны быть готовы и к внеплановым ситуациям.

Лучшим решением всегда будет то, что создано специально под конкретную задачу с нуля.

[webgraph]

При освобождении А и Б, из очереди немедленно будет забрана задача А-Б. Запрос Б-А никак не сможет воткнуться между этими действиями и в любом случае добавляется в очередь.

Меня тут больше смущает другой кейс: обрабатывается А-Б, в очереди сидит А-С, пришёл запрос С-Д. Вроде как он свободен и можно запускать, но тогда для участника С он выполнится до предыдущего. Если так нельзя, то надо проверять участников не только в хешмэпе текущих обрабатываемых, но ещё в хешмэпе персональных очередей, о котором я говорил выше. И если там нашлось, то ставить в очередь.

Здесь играет роль только то, есть ли участники нового запроса в buffer или нет. Исходя из вашего примера С-Д выполнится первее, чем А-С, и это совершенно нормальное и правильное положение событий. Кто первый встал, того и тапки, как говорится.

[voraa]

Исходя из вашего примера С-Д выполнится первее, чем А-С, и это совершенно нормальное и правильное положение событий. Кто первый встал, того и тапки, как говорится.

Исходя из выше сказанного

1. На сервер приходит запрос "<Вася> хочет передать <Пете> то-то".

это не так
А сначала должен что то передать С, что бы потом С мог передать это Д
Если сначала выполнять С-Д, то у С может этого не быть.
Задачу на корректнее ставить.

[webgraph]

Исходя из выше сказанного

это не так
А сначала должен что то передать С, что бы потом С мог передать это Д
Если сначала выполнять С-Д, то у С может этого не быть.
Задачу на корректнее ставить.

Так проверка наличия чего-либо проверяется как раз в момент операции. И эти данные участников хранятся в другом месте, не в очереди.

Если в момент операции выясняется, что у С нет того, что надо передать Д, то будет возвращен ответ "Операция не выполнена — не достаточно того-то".

И какой смысл С что-то передавать Д, если у него этого нет? Только если для DDOS-атаки.

[webgraph]

Исходя из выше сказанного

это не так
А сначала должен что то передать С, что бы потом С мог передать это Д
Если сначала выполнять С-Д, то у С может этого не быть.
Задачу на корректнее ставить.

Более того, т.к. операции выполняются считанные микросекунды, то выполнять предварительную проверку "Есть ли у С то, что он хочет передать Д?" перед добавлением в buffer — некорректно. Проверка может сказать "ДА, True, у C есть то, что он хочет передать Д", но пока эта проверка проводилась, то успела произойти другая операция и по итогу у С уже нет того, что он хочет передать Д.