Рубрика «raft»
Можно ли доверить важные документы open-source LLM: эксперимент Рег.облака и Raft
2026-01-21 в 11:25, admin, рубрики: AI, llm, raft, договор, извлечение данных, извлечение информации, исследование, нейросети, рег.облако, экспериментRaft в Tarantool. Как это работает и как этим пользоваться
2021-01-20 в 9:52, admin, рубрики: raft, tarantool, Алгоритмы, Блог компании Mail.Ru Group, выборы лидера, выборы мастера, хранение данных
В прошлом году в Tarantool была проведена колоссальная работа по реализации синхронной репликации. При этом мы придерживались алгоритма Raft. Вся работа была разделена на два крупных этапа: так называемую кворумную запись, то есть синхронную репликацию, и автоматические выборы лидера.
Синхронная репликация появилась в релизе 2.5.1, а в конце октября в релизе 2.6.1 появилась поддержка автоматических выборов лидера на основе Raft.
Меня зовут Сергей Петренко, и я участвовал в разработке этих больших фич. Сегодня я расскажу, как они устроены, а также коснусь конфигурирования выборов лидера и новых возможностей, которые алгоритм Raft даёт пользователям Tarantool.
Читать полностью »
Как сервера договариваются друг с другом: алгоритм распределённого консенсуса Raft
2019-10-04 в 10:01, admin, рубрики: append only, Dodo IS, Dodo Pizza Engineering, dodopizza, raft, Алгоритмы, Анализ и проектирование систем, Блог компании Dodo Pizza Engineering, консенсунс, математика, распределенные системыКогда кластеры достигают размеров в сотни, а иногда и тысячи машин, возникает вопрос о согласованности состояний серверов относительно друг друга. Алгоритм распределённого консенсуса Raft даёт самые строгие гарантии консистентности из возможных. В этой статье мы рассмотрим Raft с точки зрения инженера и постараемся ответить на вопросы «Как?» и «Почему?» он работает.

TiKV — распределённая база данных key-value для cloud native
2018-09-06 в 6:22, admin, рубрики: cloud native, CNCF, devops, NewSQL, open source, raft, rocksdb, TiDB, TiKV, Администрирование баз данных, базы данных, Блог компании Флант, системное администрирование
28 августа организация CNCF (Cloud Native Computing Foundation), стоящая за Kubernetes, Prometheus и другими Open Source-проектами для современных облачных приложений, объявила о принятии нового продукта в свою «песочницу» — TiKV.
Эта распределённая, транзакционная база данных типа ключ-значение зародилась как дополнение к TiDB — распределённой СУБД, которая предлагает возможности OLTP и OLAP и обеспечивает совместимость с протоколом MySQL… Но давайте обо всём по порядку.Читать полностью »
Достижимость нижней границы времени исполнения коммита распределенных отказоустойчивых транзакций
2018-04-11 в 6:36, admin, рубрики: big data, raft, Алгоритмы, Анализ и проектирование систем, высокая производительность, консенсус, параллельное программирование, распределенные системы, транзакцииПредисловие
Недавно прочитал очередную статью из серии: "мы лучше двухфазного коммита". Здесь я не буду анализировать содержания этой статьи (хотя, подумываю о том, чтобы дать развернутый анализ). Задача моего опуса — предложить самый эффективный вариант распределенного коммита с точки зрения временных задержек. Конечно, такой коммит дается высокой ценой. Однако цель — дать оценку и показать, что двухфазный коммит не является тормозным, как многие считают.
Стоит также отметить, что здесь не будет натурных экспериментов и фейковых сравнений. Будут просто даны алгоритмы и теоретический анализ. При желании, можно самостоятельно реализовать и проверить на практике. Конечно, было бы куда лучше, чтобы это было описано в текущей статье, но все упирается в свободное время и мотивацию. На мой взгляд, описать алгоритмы более важно, чем привести графики, т.к. графики по алгоритмам может нарисовать почти каждый, обратное же не верно.
Отказоустойчивая обработка 10M OAuth-токенов на Tarantool
2017-04-05 в 10:50, admin, рубрики: Lua, mail.ru, perl, raft, tarantool, Анализ и проектирование систем, Блог компании Mail.Ru Group, высокая производительность
Многие уже наслышаны о производительности СУБД Tarantool, её возможностях и особенностях. Например, у него есть классное дисковое хранилище — Vinyl, кроме того, он умеет работать с JSON-документами. Но в многочисленных публикациях обходят стороной одну важную особенность. Обычно БД рассматривают просто как хранилище, но всё же отличительная черта Tarantool — это возможность писать код внутри и очень эффективно работать с этими данными. Под катом рассказ, как мы строили одну систему почти полностью внутри Tarantool, написанный в соавторстве с Игорем igorcoding Латкиным.
Docker swarm mode (режим роя)
2017-01-12 в 14:20, admin, рубрики: containers, devops, docker, docker services, ingress network, kubernetes, raft, swarm mode, Блог компании REDMADROBOT, виртуализация, ит-инфраструктура, Серверное администрирование
На хабре уже писали про Docker swarm mode (режим роя), который является новой фичей версии 1.12. Данная опция внесла небольшую путаницу в головы тех, кто знаком с отдельно стоящей реализацией Docker Swarm имевшей распространение ранее и не отличавшейся удобством настройки и использования. Однако, после добавления Swarm в коробку с Docker все стало намного проще, очевиднее и функциональнее.
Подробнее о том, как устроен новый кластер Docker контейнеров с точки зрения пользователя, а также о простом и удобном способе разворачивания сервисов Docker на произвольной инфраструктуре далее под катом.
Читать полностью »
Python: строим распределенную систему c PySyncObj
2016-06-28 в 8:05, admin, рубрики: distributed systems, python, raft, Блог компании Wargaming, децентрализованные сети, Программирование, Сетевые технологииПредставьте, что у вас есть класс:
class MyCounter(object):
def __init__(self):
self.__counter = 0
def incCounter(self):
self.__counter += 1
def getCounter(self):
return self.__counter
И вы хотите сделать его распределённым. Просто наследуете его от SyncObj (передав ему список серверов, с которыми нужно синхронизироваться) и отмечаете декоратором @replicated все методы, которые изменяют внутреннее состояние класса:
class MyCounter(SyncObj):
def __init__(self):
super(MyCounter, self).__init__('serverA:4321', ['serverB:4321', 'serverC:4321'])
self.__counter = 0
@replicated
def incCounter(self):
self.__counter += 1
def getCounter(self):
return self.__counter
PySyncObj автоматически обеспечит репликацию вашего класса между серверами, отказоустойчивость (всё будет работать до тех пор, пока живо больше половины серверов), а также (при необходимости) асинхронный дамп содержимого на диск.
На базе PySyncObj можно строить различные распределенные системы, например распределенный мьютекс, децентрализованные базы данных, биллинговые системы и другие подобные штуки. Все те, где на первом месте стоит надёжность и отказоустойчивость.
Читать полностью »

