Циркуляр проверки и переключение API, чтобы сохранить поток переводов

[vBET]

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

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

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

Другим решением было бы хранить информацию, предпочтительный поставщик не доступны и перейти сразу к следующему. Это было бы намного быстрее, потому что проверка локальной переменной является гораздо быстрее, чем ждать ответа от внешнего сервера. На этот раз, у нас есть другой вопрос - мы не знаем, когда доступен предпочтительный поставщик. Мы можем, конечно, сделал некоторые назначенное задание, которое бы попросить простой (короткое) перевод например раз в час/день проверить его. Так в рамках этой стратегии мы должны решить, как часто по умолчанию, такой задачи предполагается работать. Конечно мы бы проверить, только тогда, когда некоторые поставщик помечается как не имеется.
Также если мы отмечаем поставщиков как недоступный - что делать, когда мы знаем, что все поставщики не доступны - добавить некоторую информацию для конечного пользователя или просто воплотить то, что находится в кэш и остальные как оригинал, без каких-либо дополнительной информации о временное отсутствие служб письменного перевода.

Независимо от того, каким образом это будет сделано Google будет рассматриваться как один API (v1 или v2 в зависимости от конфигурации) - нет смысла разбить его, потому что очень скоро будет закрыт Google v1.

Другая вещь, чтобы настроить очередь поставщики для каждой языковой пары отдельно. В этот момент vBET уже позволяет настроить поставщика перевода для каждой языковой пары. Я думаю, что мы можем изменить ее от одного значения к разделение значений запятыми (CSV). Таким образом, мы будем знать для каждой языковой пары которых поставщики поддерживают этот перевод и каковы порядок предпочтения (справедливый порядок в CSV список).

ОБРАТИТЕ ВНИМАНИЕ: Это будет иметь некоторые влияет на производительность так или иначе. Вместо того, чтобы создать один объект для перевода нам придется создать массив таких объектов и дополнительных обтекания объекта (чтобы сделать его прозрачным для других частей кода и меньше ошибок подверженных). Конечно мы не создадим объекты для поставщиков, мы знаем, не доступны на данный момент.
Решение для этого будет перенастроить для лучшей производительности и удалить очередь поставщики - так же, как это прямо сейчас - один поставщик на языковой пары.
Это не должно быть дорогим для исполнения, но до сих пор некоторые дополнительные логики и потребление памяти.

Пожалуйста, сообщите, какой вариант является предпочтительным.