Учу жава и спринг, за одно хочу нарисовать торгового бота для бинанса. подключил их <artifactId>binance-connector-java</artifactId>, сделал @Service, в нем AtomicInteger ethPrice

        wsStreamClient.aggTradeStream(coinName,((message) -> {
            JSONObject obj = new JSONObject(message);
            String price = obj.getString("p");
            var decimalPrice = Double.valueOf(price)* 10000;
            ethPrice.set((int) decimalPrice);
        }));

планирую в эту же конструкцию тригеры на минимальную и максимальную цену затолкнуть и тоже в AtomicBoolean стримить флаги. тригер будет запускать через @Async логику которая подождет пару секунд не сменился ли флаг назад и что-нибудь предпримет.
на сколько подход разумен, писать стрим в атомик переменные и потом в отдельных тредах их читать в процессе выполнения логики тригеров ? я смотрю там трафик нехилый.

Здравствуйте, Ballista, Вы писали:

Честно говоря не увидел в сообщении заявленого в заголовке "Архитетура". Но судя по всему ты хочешь реализовать простой (с одной торговой стратегией) Smart Order Router. Нарисуй тогда схематически свою архитектуру, чтоб было понятно суть вопроса.

B>планирую в эту же конструкцию тригеры на минимальную и максимальную цену затолкнуть и тоже в AtomicBoolean стримить флаги.

Какие критерии оценки ты закладываешь в архитектуру? Расширяемость? Высокая скорость обработки? Рентерабельность/идемпотентность? Надежность?


B>на сколько подход разумен, писать стрим в атомик переменные и потом в отдельных тредах их читать в процессе выполнения логики тригеров ? я смотрю там трафик нехилый.

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

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

вопрос мне кажется это архитектурный, на сколько у меня здоровые ожидания: один зеленый тред получает WebSocket Stream данные о валюте(ах) и обновляет 3 AtomicInteger поля (цена и 2 флага) раз 20 в секунду, а параллельные зеленые треды с бизнес логикой уже работают с этими атомик полями в своем темпе. положим раз в минуту оценивают движение цены.
какие шансы у этого подхода стабильно работать или проц захлебнется 20 раз в секунду атомик менять ?

R>Какие критерии оценки ты закладываешь в архитектуру? Расширяемость? Высокая скорость обработки? Рентерабельность/идемпотентность? Надежность?

надежность

R>Подход писать "толстого многопоточного толстого клиента" без возможности кластеризации всегда вызывает вопросы.

кластеризация это в смысле несколько инстансов на разных машинах ? необходимости нет, деньги не заемные, даже если программка умрет — будет лишь выгода упущена. но ради прокачки может и стоит, что-то что будет выбирать primary узел. когда-то на работе были задачи вокруг curator библиотеки.

Здравствуйте, Ballista, Вы писали:

B>вопрос мне кажется это архитектурный, на сколько у меня здоровые ожидания: один зеленый тред получает WebSocket Stream данные о валюте(ах) и обновляет 3 AtomicInteger поля (цена и 2 флага) раз 20 в секунду, а параллельные зеленые треды с бизнес логикой уже работают с этими атомик полями в своем темпе. положим раз в минуту оценивают движение цены.
B>какие шансы у этого подхода стабильно работать или проц захлебнется 20 раз в секунду атомик менять ?

20 раз в секунду конечно ни о чем. но 3 атомика звучит кринжово.
Выгладит как будто ты поток сообщений хочешь обрабатывать. Для этого есть всякие реактивные flux, корутиновые flow и прочие аналоги.
там есть нужный тебе арсенал типа debounce, windowed и тд и тп. и голова не будет болеть про многопоточность.