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

Давайте.
Чем вы можете помочь?

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

Бальт еще и на жабе пишет?..

Вот кошмар то ))

Спасибо вам за поддержку. Правда Бальтазар-то не при чем ) У него реально есть чему поучиться, по крайней мере в плане программирования на JavaScript.

Разъясняю всем!
Мне удивительно почему многим это не понят? Почему не могут проводить аналогии с личным творческим трудом в новой, аццки сложной области, когда ты вытягиваешь ее в соло.
Если ты взявшись в соло за сложный проект будешь много выбирать, анализировать - он не будет завершен НИКОГДА.
Меня удивляет, почему вы не в состоянии оценить! даже косвенно. можно даже не смотреть в код!!! У этого движка столько форков, потому что его код настолько структурирован и изящен, что каждый его может заюзать и допилить под себя!!! Вот в чем ценность этого движка!!! И еще в том, что благодаря ему можно в принципе даже научится создавать свои движки. Посмотрите на другие на гитхабе! Да там черт ногу сломит!! там столько намешано технологий, что видно что этти движки амнокодеры создавали - там фарш-код - кто во что гаразд...
Ну очевидно же!!! что автору OpenTrade советы не нужны!! Он дал сообществу, причем бесплатно, нечто великолепное! Так как теперь глядя на его код даже школота сможет написать свой обменник или биржу!!!
Плять! В мире только несколько людей могут похвастатся тамики соло-проектами!!! Вы просто не в состоянии заценить. Ну очевидно же, что автору если понадобится сделать улучшения в следующих версиях - он их сделает. а советы ему не нужны, так как он превосходит и знаниях и профессионализме 99% программистов.
Лучше бы задонатили ему - там на гитхабе реквезиты есть...

1. Если у пользователя что-то сглючило с балансами
2. Если на пользователе сработала автоблокировка вывода (когда задетектилась подозрительная активность)

Если нажать на Fix, то
1. Снимутся все пользовательские ордера по этой монете
2. Баланс пользователя будет проверен по блокчейну и по истории торгов
3. Если будут найдены несоответствия - баланс приведется в порядок
4. Вывод разблокируется

Привет! Можете разъяснить механизм действия кнопки Fix и когда возникает необходимость ей воспользоваться?

Насчет СУБД, если хочется чего-то радикально быстрого, то можно попробовать RediSQL. Это модификация SQLite, которая использует Redis в качестве бэкэнда.

https://redisql.com/

Натянет по самые гланды любые мускули, при сохранении совместимости с ANSI SQL, если такова цель.

Проект в активной разработке, но с биндингами проблем нет.

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

Я все никак не могу забыть, как один эксперт отличился. Заявил, что в SQLite масштабирование никакое, а когда ему было предложено побить в реальной производительности конкретное решение, то покряхтел недельку и исчез. Не пишет вот уже год со своим InnoDB.

Не знаю, в каком году вы застряли, но SQLite уже много лет как умеет write-ahead logging. Если хорошо "читали о базах данных", то вы вкурсе, что это такое и зачем нужно.

Чувак поверь, диванных экспертов я наслушался начиная с первой страницы темы - можешь почитать. Все такие умные, но почему-то такие бедные ))
Можешь сделать лучше - вперед и с песней!

Чувак, если тебе говорят одно и тоже- есть повод задуматься. Я не говорю даже о качестве кода и наличия там велосипедов в виде обертки для базы- первое что я заметил, видимо мы любим делать бесполезную работу и не знаем о sequelize. Чувак, критика- путь к совершенству. И да, я не nodejs разработчик и ни разу с ним не работал, но моего опыта хватает что бы писать об этих недочетах с уверенностью. И советую провести нагрузочное тестирование отработки ордеров. Ну в секунду хотяб 5к ордеров чтоб выставлялось, 1к отменялось и 500 ордеров были бы самопересекающиеся, + параллельно 10к онлайн рандом по сайту. И посчитайте задержки. Я уверен, что нагрузочное тестирование заставит вас задуматься.

SQLite, серьезно? На любом пампе проект сломается. ТС видимо не знаком с напором торговых роботов. Масштабирование- никакое.

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

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



Тип EXCLUSIVE блокирует и на запись... но автор уже обьяснил что не использует ее а блокирует в коде

На чтение не блокируется, только на запись.

node.js однопоточна принципиально.

В Mysql InnoDB можно блокировать строки при помощи SELECT FOR UPDATE после начала транзакции,   другая попытка "SELECT FOR UPDATE" на эти же строки будет ожидать завершения транзакции.

Если блокируется в коде то все ок,  просто так можешь запустить приложение только в 1 поток, и не сможешь запустить параллельно

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

Далеко не все операции можно так сделать. Например два пользователя нажали купить биткоин по 8000 USDT с разницой в миллисекунды,  нужно заблокировать строки базы с ордерами по 8000 пока проводятся операции с балансом первого пользователя, чтобы паралеллельный процесс не использовал эти ордера для второго пользователя а ожидал,  В sqlite нельзя заблокировать строки, блокируется сразу вся база при помощи транзакции EXCLUSIVE и ждать будет не только второй пользователь но и любые пользователи которые просто хотели посмотреть список ордеров или добавить свой ордер

Во первых, арифметические операции можно делать прямо внутри sql update. В опенсорсной версии у меня так и делается...
Во вторых, если по уму, то базу надо организовывать по методу двойной бухгалтерской записи. В таком случае вообще нет операций update, а есть только insert , а итог считается селектом. Ошибки в таком случае практически невозможны.

В третьих, в sqlite ЕСТЬ транзакции. Внезапно?