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

Август 12, 2022

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

Содержание

2. Практический семинар Архитектуры и паттерны проектирования Егор Зуев
3. Меня хорошо слышно && видно?
4. Содержание Реализация распределенной реляционной (SQL) СУБД Реализация распределенного лока Создание сервиса оркестрации
5. Распределенная SQL СУБД 01
6. Свойства Применение изменений происходит через транзакции Транзакция может содержать коллизии Что такое RSM
7. Решение Применение изменений происходит через транзакции: использовать лог (как элементарную единицу транзакции) Транзакция может содержать коллизии:
8. Consensus Что возьмем (AP/CP) Синхронная / Асинхронная Нужны ли логи Скорость работы (есть ли критерии) Безопасность
9. Consensus Что возьмем (AP/CP): т.к. СУБД у нас реляционная – взяли CP Синхронная / Асинхронная: синхронная,
10. Дизайн системы Система может состоять из 2 компонентов: consensus + sql db Во время старта системы,
11. Распределенный лок 02
12. Где может быть нужен Доступ к зашаренному ресурсу: например два клиента пытаются конкурентно работать с одним
13. Consensus Что возьмем (AP/CP) Синхронная / Асинхронная Нужны ли логи Скорость работы (есть ли критерии) Безопасность
14. Consensus Что возьмем (AP/CP): т.к. для нас критична синхронизация, возьмем CP Синхронная / Асинхронная: синхронная, т.к.
15. Дизайн системы (1) Система может состоять из 2 компонентов: consensus + custom SM Во время старта
16. Дизайн системы (2) Система может состоять из 1 компонента: стороннего consensus’а Во время обращения к ресурсу,
17. Создание сервиса оркестрации 03
18. Где может быть нужен Преимущественно распределение ролей: как например, в блокчейне miner и клиент
19. Задача В приватном кластере, состоящим из нескольких блокчейн нод, выбирать лидера путем quorum’a.
20. Consensus Что возьмем (AP/CP) Синхронная / Асинхронная Нужны ли логи Скорость работы (есть ли критерии) Безопасность
21. Consensus Что возьмем (AP/CP): CP, т.к. сама система leader-based Синхронная / Асинхронная: синхронная Нужны ли логи:
22. Опрос https://otus.ru/polls/6413/
24. Скачать презентацию

Слайд 2

Практический семинар
Архитектуры и паттерны проектирования
Егор Зуев

Слайд 3

Меня хорошо слышно && видно?

Слайд 4

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

Слайд 5

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

Слайд 6

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

Слайд 7

Решение
Применение изменений происходит через транзакции: использовать лог (как элементарную единицу транзакции)
Транзакция

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

Слайд 8

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

это внедрить (дизайн системы)

Слайд 9

Consensus
Что возьмем (AP/CP): т.к. СУБД у нас реляционная – взяли CP
Синхронная

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

Слайд 10

Дизайн системы
Система может состоять из 2 компонентов: consensus + sql db
Во

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

Слайд 11

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

Слайд 12

Где может быть нужен
Доступ к зашаренному ресурсу: например два клиента пытаются

конкурентно работать с одним и тем же файлом (mutex)
Ограничение на кол-во клиентов (конкурентного доступа): распределенный семафор

Слайд 13

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

это внедрить (дизайн системы)

Слайд 14

Consensus
Что возьмем (AP/CP): т.к. для нас критична синхронизация, возьмем CP
Синхронная /

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

Слайд 15

Дизайн системы (1)
Система может состоять из 2 компонентов: consensus + custom

SM
Во время старта системы, определяется лидер
Все запросы на lock совершаются через лидера
На каждый lock можно добавить timeout
Лидер и фолловеры могут следить за истечением timeout, и по истечению – делать новый лок

Слайд 16

Дизайн системы (2)
Система может состоять из 1 компонента: стороннего consensus’а
Во время

обращения к ресурсу, инстанс приложения регистрирует себя для данного ресурса (через consensus), тем самым делает лок
Когда работа с ресурсом завершена – приложение закрывает сессию, тем самым снимая лок

Слайд 17

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

Слайд 18

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

и клиент

Слайд 19

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

quorum’a.

Слайд 20

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

это внедрить (дизайн системы)

Слайд 21

Consensus
Что возьмем (AP/CP): CP, т.к. сама система leader-based
Синхронная / Асинхронная: синхронная
Нужны

ли логи: скорее нет, чем да. Нужна версия последнего принятого решения, а также у нод должна быть возможность обменяться своими ID
Скорость работы (есть ли критерии): принятие решения, кто лидер, не должно превышать 1 минуты
Безопасность: в кворум не должно быть возможности подключить сторонние ноды
Как это внедрить (дизайн системы): предполагается, что рядом с каждой нодой, будет соответствующий инстанс клиента, который будет ей управлять. В клиенты будут общаться между собой, используя consensus алгоритм

Слайд 22

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

Содержание

Практический семинарАрхитектуры и паттерны проектированияЕгор Зуев

Меня хорошо слышно && видно?

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

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

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

РешениеПрименение изменений происходит через транзакции: использовать лог (как элементарную единицу транзакции)Транзакция

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

ConsensusЧто возьмем (AP/CP): т.к. СУБД у нас реляционная – взяли CPСинхронная

Дизайн системыСистема может состоять из 2 компонентов: consensus + sql dbВо

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

Где может быть нуженДоступ к зашаренному ресурсу: например два клиента пытаются

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

ConsensusЧто возьмем (AP/CP): т.к. для нас критична синхронизация, возьмем CPСинхронная /

Дизайн системы (1)Система может состоять из 2 компонентов: consensus + custom

Дизайн системы (2)Система может состоять из 1 компонента: стороннего consensus’аВо время

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

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

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

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

ConsensusЧто возьмем (AP/CP): CP, т.к. сама система leader-basedСинхронная / Асинхронная: синхроннаяНужны

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

Похожие презентации

Практический семинар
Архитектуры и паттерны проектирования
Егор Зуев

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

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

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

Решение
Применение изменений происходит через транзакции: использовать лог (как элементарную единицу транзакции)
Транзакция

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

Consensus
Что возьмем (AP/CP): т.к. СУБД у нас реляционная – взяли CP
Синхронная

Дизайн системы
Система может состоять из 2 компонентов: consensus + sql db
Во

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

Где может быть нужен
Доступ к зашаренному ресурсу: например два клиента пытаются

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

Consensus
Что возьмем (AP/CP): т.к. для нас критична синхронизация, возьмем CP
Синхронная /

Дизайн системы (1)
Система может состоять из 2 компонентов: consensus + custom

Дизайн системы (2)
Система может состоять из 1 компонента: стороннего consensus’а
Во время

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

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

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

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

Consensus
Что возьмем (AP/CP): CP, т.к. сама система leader-based
Синхронная / Асинхронная: синхронная
Нужны

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