Онлайн образование. Практический семинар

1.

О Н Л А Й Н - О Б РА З О В А Н И Е

2.

Практический семинар

3.

Меня хорошо слышно
&& видно?
Напишите в чат, если есть проблемы!
Ставьте + если все хорошо

4.

Содержание
• Реализация распределенной реляционной (SQL) СУБД
• Реализация распределенного лока
• Создание сервиса оркестрации
4

5.

Распределенная SQL
СУБД

6.

Свойства
• Применение изменений происходит через транзакции
• Транзакция может содержать коллизии
• Что такое RSM
6

7.

Решение
• Применение изменений происходит через транзакции:
использовать лог (как элементарную единицу транзакции)
• Транзакция может содержать коллизии: использовать подход
leader-follower, и все действия на запись перегонять строго
через лидера
• Что такое RSM: SM – СУБД (sqlite), R – consensus engine
7

8.

Consensus
Что возьмем (AP/CP)
Синхронная / Асинхронная
Нужны ли логи
Скорость работы (есть ли критерии)
Безопасность
Как это внедрить (дизайн системы)
8

9.

Consensus
• Что возьмем (AP/CP): т.к. СУБД у нас реляционная – взяли CP
• Синхронная / Асинхронная: синхронная, т.к. есть критерии к
скорости репликации
Нужны ли логи: каждый лог будет транзакцией
Скорость работы (есть ли критерии): есть критерий, проводить
транзакции за фиксированное время
Безопасность: защита от коллизий
Как это внедрить (дизайн системы)
9

10.

Дизайн системы
Система может состоять из 2 компонентов: consensus + sql db
Во время старта системы, определяется лидер
Вместо прямой работы с БД, работает middleware
В случае, если текущая нода (на которой делаем запрос на
запись), является лидером – то применяем транзакцию, и в
случае успеха – делаем лог и реплицируем
• В случае, если текущая нода (на которой делаем запрос на
запись), является фолловером – то реплицирует это изменение
до лидера. Если лидер применил успешно это изменение – то
выпускается лог.
10

11.

Распределенный лок

12.

Где может быть нужен
• Доступ к зашаренному ресурсу: например два клиента пытаются
конкурентно работать с одним и тем же файлом (mutex)
• Ограничение на кол-во клиентов (конкурентного доступа):
распределенный семафор
12

13.

Consensus
Что возьмем (AP/CP)
Синхронная / Асинхронная
Нужны ли логи
Скорость работы (есть ли критерии)
Безопасность
Как это внедрить (дизайн системы)
13

14.

Consensus
• Что возьмем (AP/CP): т.к. для нас критична синхронизация,
возьмем CP
Синхронная / Асинхронная: синхронная, т.к. есть критерии к
скорости репликации изменений
Нужны ли логи: нет, иначе каждый круг синхронизации будет
порождать новые логи и расходовать память
Скорость работы (есть ли критерии): есть критерий,
организовывать согласование за фикс. время
Безопасность: защита от конкурентной записи
Как это внедрить (дизайн системы)
14

15.

Дизайн системы (1)
• Система может состоять из 2 компонентов: consensus + custom
SM
Во время старта системы, определяется лидер
Все запросы на lock совершаются через лидера
На каждый lock можно добавить timeout
Лидер и фолловеры могут следить за истечением timeout, и по
истечению – делать новый лок
15

16.

Дизайн системы (2)
• Система может состоять из 1 компонента: стороннего
consensus’а
• Во время обращения к ресурсу, инстанс приложения
регистрирует себя для данного ресурса (через consensus), тем
самым делает лок
• Когда работа с ресурсом завершена – приложение закрывает
сессию, тем самым снимая лок
16

17.

Создание сервиса
оркестрации

18.

Где может быть нужен
• Преимущественно распределение ролей: как например, в
блокчейне miner и клиент
18

19.

Задача
• В приватном кластере, состоящим из нескольких блокчейн нод,
выбирать лидера путем quorum’a.
19

20.

Consensus
Что возьмем (AP/CP)
Синхронная / Асинхронная
Нужны ли логи
Скорость работы (есть ли критерии)
Безопасность
Как это внедрить (дизайн системы)
20

21.

Consensus
• Что возьмем (AP/CP): CP, т.к. сама система leader-based
• Синхронная / Асинхронная: синхронная
• Нужны ли логи: скорее нет, чем да. Нужна версия последнего
принятого решения, а также у нод должна быть возможность
обменяться своими ID
• Скорость работы (есть ли критерии): принятие решения, кто
лидер, не должно превышать 1 минуты
• Безопасность: в кворум не должно быть возможности подключить
сторонние ноды
• Как это внедрить (дизайн системы): предполагается, что рядом с
каждой нодой, будет соответствующий инстанс клиента, который
будет ей управлять. В клиенты будут общаться между собой,
используя consensus алгоритм
21

22.

Опрос
https://otus.ru/polls/6413/
22

23.

Спасибо
за внимание!