Не приходит полная версия OnTrade

Страницы: Пред. 1 2
RSS
Не приходит полная версия OnTrade
 
Цитата
VPM написал:
что событийная модель предполагает надёжность колбэков, а в том, как она обрабатывает неопределённость
И какое же преимущество у колбека (условно декларативного) перед императивным подходом? Что же такого это дает, кроме уменьшения кода, с чем не поспоришь. Также очень странно видеть "событийно-ориентированная архитектура" и "она предназначена именно для того, чтобы жить в мире, где события могут теряться, приходить не в том порядке или с задержкой". Как же жить если реакция на событие не пришла?
 
Nikolay,  CAP-теорема говорит, что в распределённой системе мы можем выбрать только две из трёх характеристик:
* Consistency,
* Availability,
* Partition tolerance.

Биржа — это отдельный узел, с которым у нас нет синхронной связи.
Мы выбираем Availability и Partition tolerance, жертвуя строгой консистентностью в реальном времени.

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

Именно это дают, в моем варианте, инварианты S1‑S6 и Watchdog.

Ваш подход тоже жертвует строгой консистентностью, но у него нет формальных гарантий, что в момент расхождения не будет ошибки. Вы просто надеетесь, что 1 секунд достаточно, чтобы всё "устаканилось"?
 
Цитата
VPM написал:
Ваш подход тоже жертвует строгой консистентностью, но у него нет формальных гарантий, что в момент расхождения не будет ошибки. Вы просто надеетесь, что 1 секунд достаточно, чтобы всё "устаканилось"?
О какой секунде речь - не понятно. Если речь про транзакцию, то после её подачи по номеру происходит поиск записи в таблице ордеров сразу, мгновенно. OnTransReply нужен только для того, чтобы прекратить поиск, если есть ошибка. Еще раз в момент принятия решения Вы просто смотрите на данные. Других данных у Вас нет.
 
Я говорю о том, что архитектура с чёткими инвариантами и детерминированными компонентами позволяет предсказать поведение системы в любых ситуациях, включая сбои, и гарантировать, что она не совершит опасных действий (например, не превысит лимиты, не создаст дублирующий ордер). Это достигается не магией, а строгим проектированием. Именно поэтому в моей архитектуре колбэки не являются единственным источником истины. Они служат лишь для оперативного обновления состояния, но всегда дополняются регулярной сверкой с таблицами (reconciliation). Если колбэк потерян, система обнаружит это при следующем опросе и скорректирует состояние.

Таким образом, событийная модель не требует надёжности колбэков — она лишь использует их для уменьшения задержки!
 
VPM
Понятно, вас с "толку" не сбить :smile: .
Но интересно, что вы напишите на следующее.
   Обрабатывая коллбеки и восстанавливая их результат, вы, по сути, повторяете (но в условиях неопределенности) работу которая выполняется в QUIK при формировании его таблиц.
  1. Зачем повторять функциональность которую реализовали разработчики и которая отлажена, скорее всего лучше чем "призрачные" коллбеки (зависящие от кода main), так как это было давно (до появления QLua) и проще контролируется?
  2. Полагаете, что вы квалифицированнее разработчиков?
  3. Вы же вроде согласны с принципом "меньше дергаешься - реже падаешь". Вам нечем заняться и хочется поразвлечься с коллбеками?
 
VPM
  Забыл добавить: где доказательство безопасности счета?
 
TGB, Я не пытаюсь навязать событийную модель как единственно верную. Я лишь показываю, что она даёт определённые преимущества в плане гарантий и детерминизма, которые могут быть критичны для сложных систем.

Ваш подход проще и для многих задач достаточен. Выбор зависит от требований к надёжности и готовности платить за сложность.

Если есть конкретные проблемы (например, потеря OnTrade), событийная модель может их решить элегантнее, чем простое увеличение таймаутов. Но если текущая система вас устраивает — нет смысла её усложнять.
 
Цитата
TGB написал:
VPM
  Забыл добавить: где доказательство безопасности счета?
А этого Вам не достаточно, или какие то слова не понятны?
Цитата
VPM написал:
архитектура с чёткими инвариантами и детерминированными компонентами позволяет предсказать поведение системы в любых ситуациях, включая сбои, и гарантировать, что она не совершит опасных действий (например, не превысит лимиты, не создаст дублирующий ордер).
 
Цитата
VPM написал:
событийная модель может их решить элегантнее, чем простое увеличение таймаутов.
Все никак не могу понять о каких таймаутах речь и как потерянное событие решается без прямого обращения к данным. Если у вас есть датчик, то только его опрос даст данные, сам он их не пришлет - это простая железка.
 
У вас много текста но нет простых вещей:
Цитата
TGB написал:
где доказательство безопасности счета?
 
Цитата
VPM написал:
архитектура с чёткими инвариантами и детерминированными компонентами позволяет предсказать поведение системы в любых ситуациях, включая сбои, и гарантировать, что она не совершит опасных действий (например, не превысит лимиты, не создаст дублирующий ордер).
  Это заклинания :smile:.   Вы думаете, что они работают?
 
Цитата
TGB написал:
Вы проверяли задержку между коллбэком с заполненными параметрами и появлением записи в таблице? Если нет, то проверьте.
Зачем?
Страницы: Пред. 1 2
Читают тему
Наверх