Нужно держать Локи, а Локи держит сессия. Т.е такое решение работает для очень маленького числа консьюмеров.в oracle есть такие очереди.

Ssd это уже тянет . Зайдите в чат по pg , например.  Там есть люди ,которые проводили такие  тесты.

А кто хорошо использует 100k io?

Про платежи. Это всегда делали на workflow. Почти все банковские системы так построены. У платежа много состояний. В очереди платежу сидеть не нужно для того ,что бы ждать свой обработки. Он ждёт в определенном статусе. Приходит событие - меняется статус. Это как конечный автомат.

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

А можешь схематично написать, как на кафке ты делал бы? Я сейчас использую похожую модель поверх базы и пока мне в обозримой перспективе по нагрузке этого хватает. Но если в будущем появятся сущности с более высокими требованиями к нагрузке, то хочется иметь в запасе масштабируемое решение.

В моём представлении, число очередей не равно числу сессий. Очереди могут быть неактивны (сущности не меняются в данный момент). Нужно дизайн целиком смотреть.

Сессии на deque. На извлечение из очереди. Мы же сообщение должны заложить в базе , что бы его не считали другие пользователи .

У меня некая сущность не меняется год, мне для её очередей сессии открытыми год держать? При чём здесь deque?

Нет, конечно. Но вот вы делаете deque, что подразумевает , что эта функция вернёт вам следующий элемент из очереди. Вы же его в таблице залочите ? что бы другие знали ,что вы с ним работаете . И если все успешно , то вы его удалите и закомитите , а если не успешно ( у вас клиент, например упал ), то произойдет rollback и запись вновь станет доступной для обработки. Т.е Лок нужен только от начала извлечения записи и до комита. Если не так, о как иначе вы предполагаете ?

Мы на разных уровнях абстракции общаемся

Странный вопрос. Там же написано про dax и mmap.  Идея в том, чтобы выкинуть page cache и block layer из i/o path.

Эээ, ну не получается иметь заметно больше TPS, нежели IOPS. Обычно как раз меньше получается, увы.

Хм, а есть какие-то ссылки на реальные результаты? Т.е. для той же FDB и по 50K tps на узел тесты показывают, но вот на PG получить 10K сложных транзакций на простой узел - хочется посмотреть (при том, что IOPSов там будет, подозреваю, больше 100K)

Ну, банковские системы даже 1K Payment-per-second тянут очень с трудом, а 10K - просто никак.
Ну и описание сложных платежей через конечный автомат - очень сложное и очень тяжело меняемое. Ну и с взаимодействием с пользователем там все грустно.
Я то как раз про платежи и говорю в основном, но не только про банк, а про произвольную платежку

Такое может быть только если отключен батчинг специально. В том же оракле он по умолчанию включен. На какой у вас базе не получается? Или может  быть у вас транзакции генерят очень много данных для WAL и условный log writer тратит время на это. Или еще что-то. это надо смотреть на конкретную конфигурацию. У меня на оракле было 1K+ обычно.

Ну, я на таком делал платежку, даже на дешевом железе на Pg спокойно получал 100 payment-per-second (сложных сквозных платежей, которые банки вообще обычно не умеют) и быструю разработку.

смотря какого устройства iops. wal унести на отдельное быстрое устройство, например.

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

Ну, реально, конечно, число соединений нужно как число воркеров, а их много не нужно, но зависит от транзакционности обработки сообщения и вообще времени обработки сообщения. На 10K воркеров и 10ms получим 1mln MPS