Topic: Давайте создадим с нуля биржу Open Source? - page 9. (Read 32292 times)

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

да. лучше всего проводить операции обмена сразу в регистрах процессора) или хотя бы в озу))))
но для надежности лучше писать каждый обмен в ячейку SSD TLC/MLC NAND)))
У автора не стоит пока цели оптимизации скорости работы. ПОка все упирается в дизайн и безопасность фреймворков

Либо я чего-то не понял, либо ты себе противоречишь, когда пишешь что перевёл базу данных в отдельный процесс и скорость стала получше. Если у биржи мало клиентов, то конечно с нагрузкой справится любая БД. Не знаю специфику запросов твоей биржи, но SQLite точно сливает enterprise решениям при высокой нагрузке и даже при низкой, когда ей сопутствует большое количество writes.

В том то и дело, что "какой-нибудь"...

Я для себя сформулировал сначала: что мне нужно от базы данных:
1. Чтобы умела SQL запросы
2. Хммм... Все собственно.

Если не собираешься писать логику работы на голом SQL (таких умельцев хватает), а используешь более или менее нормальный высокоуровневый язык, то для бухгалтерской книги подойдет вообще любая база данных.

Выбор SQLite для меня был естественным: с этой базой у меня есть выбор - использовать ее как встроенную в процесс или вынести в отдельный сервер. С большинством остальных баз такого выбора нет - отдельный процесс-сервер без вариантов.
Чем лучше встроенная база? Тем, что ее скорость всегда будет в сотни раз выше любой базы на отдельном сервере. Ибо общение между процессами всегда проходит сильно медленней, чем общение процесса внутри себя.

Чем не устраивает какой-нибудь PostgreSQL?

База как была SQlite так и осталась. Но теперь она крутится в отдельном от биржи процессе и теперь к ней можно из разных процессов обращаться.

какая БД?

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

Скорость работы невыносимая

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

Кстати какие идеи где править ограничения на вывод, кто подскажет?

Жаль, что этот проект больше не будет развиваться как open-source биржа. В любом случае, была проделана отличная работа. Действительно, зачем потребители убирали койн разработчика софта, это была своего рода реклама этой монеты.

https://forklog.com/bitkoin-koshelek-copay-nahoditsya-v-zone-riska-iz-za-uyazvimosti-node-js/
обратите внимание!

живая версия на гитхаб больше выкладываться не будет.
Слишком много было потребителей, которые форкают, пользуются апдейтами, но даже не удосуживаются Мэрикоин себе залистить. Мне и инвесторам это надоело.

Вот на вашем обменнике в кошельке в столбце "Currency" при кликании слева по монете https://trade.multicoins.org/market/BTC-MC торговля идет в mBTC - Как это настраивается? причем с этого форума вообще бред выходит - ссылка перенаправляется на https://trade.multicoins.org/market/MC-MC

А если кликать на LTC и DASH хоть ссылки https://trade.multicoins.org/market/BTC-LTC и https://trade.multicoins.org/market/BTC-DASH перекидывает на пару с MC ? это глюк или нет и где это настраивается? в каком файле?

Может выложить уже актуальную версию чтобы меньше вопросов возникало?

Пока никаких особых обновлений безопасности нет. Как что-то интересное найду - сделаю коммит на гитхаб.

По остальным вопросам - поищите на гитхабе, там почти на все это есть ответы.


Нет, хранить состояние блокировок в базе это как-то сильно расточительно. Эти флаги хранятся как глобальные переменные в программе.

kzv - спасибо за обстоятельный ответ. Я, очевидно, не правильно понял изначально что имелось ввиду под заблокированным. Заблокированный юзер/баланс это, выходит, флаг в базе?

Можно как-то синхронизировать  версию на гитхаб с вашей доработанной - для безопасности.  

И если не сложно подсказать - в каких файлах нужно поправить код чтоб основной парой стоял биткойн и разрешались ордера вплоть до 8 знака после запятой 0.00000001 ?

Также странно - биткоина нет, пока главная монета другая, а в кошельке в столбце: Currency - в ссылках все пары к биткоину

Последнее - в chart.html откуда берутся данные для текущего курса в каком файле это править?

Вот как создается ордер:
1. Проверка: залочен ли пользователь для вывода?
2. Если не залочен - блок пользователя для создания/удаления ордеров
3. Сверить баланс пользователя с историей торговли и историей ввода/вывода
4. Если все нормально, обновить таблицу балансов
5. Если баланс обновился нормально, обновить таблицу ордеров.
6. Снять блок с пользователы для постановки/отмены ордеров
7. Еще раз сверить баланс пользователя с историей торговли и историей ввода/вывода

https://github.com/3s3s/opentrade/blob/master/server/modules/users/orders.js#L305


Вот как проходит исполнение ордера
1. Выбрать два пересекающихся ордера из стаканов
2. Заблокировать эти два ордера от изменений из других мест.
3. Проверить: заблокированы ли авторы ордеров для постановки/отмены ордеров.
4. Если не заблокированы, то заблокировать. Если хоть один заблокирован, то выйти из процедуры.
5. Обновить таблицу ордеров
6. Если таблица ордеров обновилась успешно, то разблокировать пользователей для постановки/отмены ордеров
7. Разблокировать ордера (если от них что-то осталось) для изменений
8. Обновить балансы пользователей и обновить таблицу истории.

В версии которая на гитхабе порядок немного другой
https://github.com/3s3s/opentrade/blob/master/server/modules/users/orders.js#L441

Там пункт 8 стоит перед пунктами 6 и 7:
1. Выбрать два пересекающихся ордера из стаканов
2. Заблокировать эти два ордера от изменений из других мест.
3. Проверить: заблокированы ли авторы ордеров для постановки/отмены ордеров.
4. Если не заблокированы, то заблокировать. Если хоть один заблокирован, то выйти из процедуры.
5. Обновить таблицу ордеров
6. Обновить балансы пользователей и обновить таблицу истории.
7. Если таблица ордеров обновилась успешно, то разблокировать пользователей для постановки/отмены ордеров
8. Разблокировать ордера (если от них что-то осталось) для изменений

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

Т.е. как я понял фактически у юзера есть два балланса - доступный и заблокированный? Это вполне логичное и разумное решение.

Но я спрашивал в том числе про блокирование базы. Насколько мне известно в лайт нельзя стучаться с одного потока асинхронно, а с учетом того, что JS однопоточный по своей природе - это должно вызывать массу проблем. Фактически каждый запрос к базе обязан блокировать всю базу до завершения транзакции, например:

Убавить доступный баланс, прибавить заблокированный баланс. (создание ордера) - это две разные операции, вклиниться в которые запрос другого юзера не имеет права (иначе исполнится только половина запроса)

или

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

Как эти проблемы решаются?