Я проверяю опции, чтобы сделать движок Drools высокодоступным в кластере kubernetes. До сих пор я находил подходы, которые могли бы или не могли бы работать, поскольку все они датированы как минимум 3 годами go, и темпы разработки могут сделать их устаревшими:
Подобные вопросы задавались годами go без решения: Имеет ли K ie исполнительный сервер (или сервер Drools) поддерживать высокую доступность?
Есть идеи, каково текущее, рабочее решение для этого? Неужели мы все изобретаем колесо каждый раз, когда находим эту проблему? Конечно, есть необходимость в чем-то вроде распределенного движка Drools, который разделяет сеанс между модулями.
Я предположил, что там может быть что-то похожее, например, реплики MongoDB, где один узел имеет доступ для чтения и записи и все остальные имеют только для чтения. Если узел чтения-записи выходит из строя, один из других узлов переводится в режим чтения-записи.
Я могу представить себе аналогичный сценарий, в котором мы можем различать guish события, которые просто получают информацию из сеанс и события, которые будут вставлять факты в рабочую память и, следовательно, будут изменять внутреннее состояние сеанса. Тогда мы могли бы иметь N экземпляров только для чтения, получающих события только для чтения, и 1 экземпляр drools для чтения и записи, которые в конечном итоге распространяют изменения в экземплярах только для чтения и которые получают только события, которые будут вставлять новые факты в движок.
Есть что-нибудь подобное?