QoSOptions - опция качества обслуживания, которые включают в себя настройки, позволяющие определить, сколько исключений допускается перед переключением в режим "паузы" (break) и как долго будет длиться эта пауза.
Если вам нужна более сложная логика обработки ошибок, включая перенаправление в зависимости от конкретных статусов кодов ошибок, вам может потребоваться реализовать собственный middleware
реализовать список из клиентов, где у каждого клиента своя очередь транзакций. И можно выбирать поочередно из каждой очереди сообщения. Этот вариант более лоялен к клиентам с мелкими транзакциями.
Если же требуется "размазать" условные 10к транзакций по периоду, и в эту кашу подкидывать транзации-кукушата, то нужно придумать функцию, которая ранжирует транзации. В простейшем варианте - генератор равномерно распределенных случайных чисел.
Генератор случайных чисел не подходит, так как кукушата, скорее всего, будут равномерно распределены не в начале ранга.
Вы предлагаете запросу, с одной транзакцией случайно сгенерировать ранг 7539 и ждать, пока 7538 транзакций отработают, пока кукушонку не дойдет очередь. Согласитесь, мой вариант справедливее.
Метод работает хорошо, если скорость исполнения транзакций значительно превышает скорость их прихода.
В этом случае и проблемы никакой нет, можно выполнять их в любом порядке
Если оба инстанса бегут в одной машине, то даже если второй инстанс будет простаивать, лишний инстанс не использует ресурсы машины (я не имею ввиду память и т.д. я про ресурсы на "обработку транзакций"). Можно считать, что работает один инстанс. А так, в идеале, нужно придумать какое-нибудь решение, чтобы создавать/удалять инстансы релевантно, по росту нагрузки.
Непонятно при чем тут микросервисы и .NET, если задача из теории массового обслуживания.
Да можно считать что .NET и микросервисы не причем, если не считать что реализовал решение в .NET и обернул в контейнеры. Но да, согласен, возможно простовато для хабра, поэтому и попросил в конце предложить другие задачи на тему микросервисов в .NET
Такой сценарий невозможен. Если речь про запросов с менее 100 транзакций то они выполняются в отдельном инстансе (он может быть в другом сервере…).
Допустим, у нас 10 тысяч запросов с 100-300 транзакциями в запросе, и несколько запросов с 1000 транзакциями. Тогда получается, мы объединяем транзакции в пачки из 10 тысяч транзакций, по одной транзакции с каждого запроса. И одна транзакция из большого запроса выполнится раз из 10к транзакций. Да, большому запросу придется ожидать дольше, так как каждая транзакция выполняется в цикле из 10к транзакций (пока не закончатся пачки из мелких транзакций), но ресурсы ограничены, по другому нельзя. Возможно, я не прав, можете предложить более релевантный сценарий.
При желании, можно указать в docker compose, что для транзакций с 100-300 транзакциями в запросе, нужно выделить отдельный инстанс, как для запросов с менее 100 транзакций
Прошу прошения, за то, что отвечаю очень медленно. Из-за моей кармы у меня ограничение в одно сообщение за 1 час
Есть большое отличие от задачи одного станка. В нашем случае не учитываются такие значение как: «Время исполнения транзакции», «значение накладных ресурсов, для исполнения транзакции», «Важность транзакции». Все транзакции для системы условно равны.
Что значит время ожидания должно быть справедливым?
Критерии «справедливости» я описал в самом начале задачи:
Необходимо исключить ситуации, когда:
Тысячи клиентов по несколько транзакции ожидают двух, у которых по 10000 транзакций
Несколько клиентов по 10000 ждут тысячи клиентов по несколько транзакций.
Цель: обработать запросы клиентов так, чтобы время ожидания было справедливым, учитывая количества транзакций в запросе. По крайней мере, я так понял задачу.
… результат обработки записывают в таблицу истории обработки транзакций…
Сам процесс обработки транзакции не так важен, я использую метод TransactionProcess в качестве заглушки. Смысл в распределении ограниченных ресурсов машины "справедливо"
Так как все числа меньше 100, если текущий максимум превышает 50 00 00 00, или 50 миллионов, пропускать элементы со значением 50 или ниже.
И это действительно дельный совет. То есть, максимально возможный результат произведения это 100*100*100*100 = 100 000 000. Если комбинация со значением произведения уже равна 80 000 000 можно игнорировать все числа меньше 80. Возьму на вооружение
На счет цепочки в форме ромба. Только что проверил, их он тоже учитывает.
гляньте на число 78 нулевая строка, первый столбец.
Первое что приходит в головы, найти самое большое число, и начать поиск соседей с него, но этот вариант отсеивается тем, что его соседи могут быть не большими. Сейчас рассматриваю
совет сохранять хэши перебранных ранее вариантов…
Справедливости ради, отмечу что Хавьер получил уже разорённую страну, и последствия его реформ мы ощутим как минимум через 15 лет, если не 45.
.NET разработчики, знакомые с экосистемой .NET, могут легко освоить и начать использовать Ocelot без необходимости изучения сложных конфигураций Nginx
Настройка авторизации между шлюзом и сервисами .NET разработчику будет гораздо легче с Ocelot
Плюс, не думаю что сильно распространена практика использования nginx в windows серверах
Нужно смотреть от конкретных требований и опыта команды. Если для ваших задач использование Nginx обоснована, используйте Nginx
Вот их реализация: Ссылка
Обрати внимание на метод Release. Он должен срабатывать каждый раз, когда сервис возвращает ответ шлюзу
Тут их тесты (документация для разработчиков), по ним вы сможете понять как это работает
Adobe After Effects
Да, если вы настроили Quality of Service
QoSOptions - опция качества обслуживания, которые включают в себя настройки, позволяющие определить, сколько исключений допускается перед переключением в режим "паузы" (break) и как долго будет длиться эта пауза.
Если вам нужна более сложная логика обработки ошибок, включая перенаправление в зависимости от конкретных статусов кодов ошибок, вам может потребоваться реализовать собственный middleware
Я разве не реализовал тоже самое?
Генератор случайных чисел не подходит, так как кукушата, скорее всего, будут равномерно распределены не в начале ранга.
Вы предлагаете запросу, с одной транзакцией случайно сгенерировать ранг 7539 и ждать, пока 7538 транзакций отработают, пока кукушонку не дойдет очередь. Согласитесь, мой вариант справедливее.
В этом случае и проблемы никакой нет, можно выполнять их в любом порядке
Если оба инстанса бегут в одной машине, то даже если второй инстанс будет простаивать, лишний инстанс не использует ресурсы машины (я не имею ввиду память и т.д. я про ресурсы на "обработку транзакций"). Можно считать, что работает один инстанс. А так, в идеале, нужно придумать какое-нибудь решение, чтобы создавать/удалять инстансы релевантно, по росту нагрузки.
Да можно считать что .NET и микросервисы не причем, если не считать что реализовал решение в .NET и обернул в контейнеры. Но да, согласен, возможно простовато для хабра, поэтому и попросил в конце предложить другие задачи на тему микросервисов в .NET
Да, именно. Одна выполненная транзакция запроса – точка синхронизации, после которой переходим на выполнение транзакции со следующего запроса.
Такой сценарий невозможен. Если речь про запросов с менее 100 транзакций то они выполняются в отдельном инстансе (он может быть в другом сервере…).
Допустим, у нас 10 тысяч запросов с 100-300 транзакциями в запросе, и несколько запросов с 1000 транзакциями. Тогда получается, мы объединяем транзакции в пачки из 10 тысяч транзакций, по одной транзакции с каждого запроса. И одна транзакция из большого запроса выполнится раз из 10к транзакций. Да, большому запросу придется ожидать дольше, так как каждая транзакция выполняется в цикле из 10к транзакций (пока не закончатся пачки из мелких транзакций), но ресурсы ограничены, по другому нельзя. Возможно, я не прав, можете предложить более релевантный сценарий.
При желании, можно указать в docker compose, что для транзакций с 100-300 транзакциями в запросе, нужно выделить отдельный инстанс, как для запросов с менее 100 транзакций
Прошу прошения, за то, что отвечаю очень медленно. Из-за моей кармы у меня ограничение в одно сообщение за 1 час
Есть большое отличие от задачи одного станка. В нашем случае не учитываются такие значение как: «Время исполнения транзакции», «значение накладных ресурсов, для исполнения транзакции», «Важность транзакции». Все транзакции для системы условно равны.
Критерии «справедливости» я описал в самом начале задачи:
Цель: обработать запросы клиентов так, чтобы время ожидания было справедливым, учитывая количества транзакций в запросе. По крайней мере, я так понял задачу.
Сам процесс обработки транзакции не так важен, я использую метод TransactionProcess в качестве заглушки. Смысл в распределении ограниченных ресурсов машины "справедливо"
Согласен. Рациональная идея.
И это действительно дельный совет. То есть, максимально возможный результат произведения это 100*100*100*100 = 100 000 000. Если комбинация со значением произведения уже равна 80 000 000 можно игнорировать все числа меньше 80. Возьму на вооружение
На счет цепочки в форме ромба. Только что проверил, их он тоже учитывает.
гляньте на число 78 нулевая строка, первый столбец.
совет сохранять хэши перебранных ранее вариантов…
Да компоненты поддерживают маршрутизацию, в его случае он может назвать их страницами