Перезапуск агентской программы после сбоя - PullRequest
Новая
       10

Перезапуск агентской программы после сбоя

0 голосов
/ 11 марта 2011

Рассмотрим приложение распределенного банка, в котором машины распределенных агентов изменяют значение глобальной переменной: скажем, «баланс»

Итак, запросы агента находятся в очереди. Запрос имеет форму, в которой значение добавляется в глобальную переменную от имени конкретного агента. Итак, код для агента имеет вид: 

  agent
    {
     look_queue(); // take a look at the leftmost request on queue without dequeuing

     lock_global_variable(balance,agent_machine_id);    
     /////////////////////  **POINT A**
     modify(balance,value);
     unlock_global_variable(balance,agent_machine_id);  
     /////////////////// **POINT B**
     dequeue();      //  once transaction is complete, request can be dequeued
    }

Теперь, если код агента падает в POINT B, то, очевидно, запрос не должен быть обработан снова, иначе переменная будет изменена дважды для одного и того же запроса. Чтобы избежать этого, мы можем сделать код атомарным, таким образом: 

agent
{
 look_queue(); // take a look at the leftmost request on queue without dequeuing

 *atomic*
 {   
  lock_global_variable(balance,agent_machine_id); 
  modify(balance,value);
  unlock_global_variable(balance,agent_machine_id);
  dequeue();      //  once transaction is complete, request can be dequeued
 }
}

Я ищу ответы на следующие вопросы:

  1. Как определить точки в коде, которые должны выполняться атомарно «автоматически»?
  2. Если во время выполнения происходит сбой кода, насколько поможет «регистрация транзакции и значений переменных»? Существуют ли другие подходы к решению проблемы разбившихся агентов?
  3. Опять же, регистрация не масштабируется для больших приложений с большим количеством переменных. Что мы можем в таком случае - вместо возобновления исполнения с нуля?
  4. В общем, как можно идентифицировать такие атомные блоки в случае агентов, которые работают вместе. Если один агент выходит из строя, другие должны ждать его перезапуска? Как тестирование программного обеспечения может помочь нам в выявлении потенциальных случаев, когда в случае сбоя агента наблюдается несовместимое состояние программы.
  5. Как сделать атомные блоки более мелкозернистыми, чтобы уменьшить узкие места в производительности?

1 Ответ

0 голосов
/ 13 марта 2011

Q> Как определить точки в коде, которые должны выполняться атомарно «автоматически»?
A> В любое время, когда в разных контекстах есть что-то общее (не обязательно, чтобы все стороны были мутаторами, достаточно хотя бы одного). В вашем случае balance используется несколькими агентами.

Q> ЕСЛИ во время выполнения происходит сбой кода, насколько поможет «регистрация транзакции и значений переменных»? Существуют ли другие подходы к решению проблемы сбойных агентов?
A> Это может помочь, но к нему прилагаются большие расходы. Вам необходимо откатить X записей, воспроизвести сценарий и т. Д. Лучший подход - сделать его полностью транзакционным или иметь эффективный сценарий автоматического отката .

Q> Опять же, регистрация не масштабируется для больших приложений с большим количеством переменных. Что мы можем в таком случае - вместо возобновления выполнения с нуля?
A> В некоторых случаях вы можете расслабить последовательность. Например, CopyOnWriteArrayList выполняет одновременную запись и включает данные для новых считывателей после того, как они становятся доступными. Если запись не удалась, она может безопасно отбросить эти данные. Там также сравните и поменяйте местами . Также смотрите ссылку на предыдущий вопрос.

Q> В общем, как можно идентифицировать такие атомные блоки в случае агентов, которые работают вместе.
A> См. Ваш первый вопрос.

Q> Если один агент выходит из строя, другие должны ждать его перезапуска?
A> Большинство политик / API определяют максимальное время ожидания для выполнения критической секции, в противном случае система может оказаться в бесконечном тупике.

Q> Как тестирование программного обеспечения может помочь нам в выявлении потенциальных случаев, когда при сбое агента наблюдается несовместимое состояние программы.
A> Это может в значительной степени. Однако для тестирования параллельного кода требуется столько же навыков, сколько и для написания самого кода, если не больше.

Q> Как сделать атомные блоки более мелкозернистыми, чтобы уменьшить узкие места в производительности?
A> Вы сами ответили на вопрос :) Если для одной атомарной операции требуется изменить 10 различных переменных общего состояния, вы ничего не можете сделать, кроме попытки отодвинуть внешний контракт вниз, поэтому ему нужно изменить больше. Это в значительной степени причина того, что базы данных не так масштабируемы, как хранилища NoSQL - им может потребоваться изменить внешние ключи, выполнить триггеры и т. Д. Или попытаться обеспечить неизменность.

Если бы вы были программистом на Java, я бы определенно рекомендовал прочитать эту книгу . Я уверен, что есть и хорошие аналоги для других языков.

...