Область распределенной обработки данных настолько обширная, что можно свихнуться. Только все в голове уложиться, как находишь новое непаханное поле.
Читаю, значит, интересный пост на eax.me : Колхозная реализация выбора лидера на Go и Consul . Там рассказана интересная идея по поводу организации лидерства среди реплик. Делается это с помощью записи в некое хранилище ключ-значение (здесь выбран Consul). Важным моментом является наличие compare and swap - чтоб при чтении одной и той же записи разными репликами не возникало бы состояния гонки.
Так вот, тут упоминается понятие leader lease. А не консенсус или выбор лидера. Полез искать этот самый лиз. Нашел в документации по CockroachDB. Здесь есть понятие leaseholder - реплика, которая координирует запросы на чтение и записи (обычно совпадает с репликой-лидером, выбранной Raft). Почему-то уменьшает количество вызовов RPC - в этом пока не разобрался. Есть статья про Аврору, где говорится, что в Cockroach запрос на чтение или запись направляется той реплике, у которой в данный момент временное лидерство (lease). Упоминание про lease встречается и в описании консенсуса в Consul.
Как пример ситуации, когда необходим этот самый лиз, в посте на eax упоминалась миграция схемы БД. Это что еще?! Неплохо объясняется в Вики. Вкратце - это процесс изменения схемы БД. Она может меняться параллельно с разработкой ПО. И если развитие ПО контролируется системой контроля версий, то со схемой так не получится. Она поменяется, а наша программа не сможет найти в ней нужные столбцы. Конкретные советы, как делать миграции даются в статье "Миграция схемы данных без головной боли: идемпотентность и конвергентность для DDL-скриптов". Хм, идемпотентность и конвергентность? Сразу навевает мысли о CRDT, не так ли?
Комментариев нет:
Отправить комментарий