BufWriter<Master<'_>> – Telegram
BufWriter<Master<'_>>
105 subscribers
451 photos
28 videos
34 files
1.7K links
https://www.patreon.com/alxe_master

Видео/статьи. Конспект и мои вольные комментарии по инженерии. тут только то, что считаю полезным для себя или других =)

#os, #cloud, #rust, #golang, #python, #javaScript, #cpp, etc
Download Telegram
== Микросервисная архитектура, подходы и технологии
https://youtu.be/FF-GZ7iipwc
- апи гэйтвей
- брокер сообщений (rabbitMQ)
- иденпотентность
- версионирование
- переиспользуемые сервисы
- секреты
- общий код - в библиотеки и пакеты
- без девопсов нет микросервисов

короч если много проектов финтех и неистовое количество сервисов яндекса, мэйлру и много дргих вендоров до сих пор на кролике - не вижу смысла сомневаться больше. выдохнул
== забавный сервис сравнения баз данных по времени процессинг. как собирается стата - оставим за скобками. но посмотреть интересно
https://clickhouse.com/benchmark/dbms/#[100000000,[%22MySQL%22,%22PostgreSQL%22],[%221%22,%222%22]]
== Python vs C/C++ vs Assembly side-by-side comparison
https://youtu.be/3PcIJKd1PKU

забавный видос сравнение скорости разработки и перформанса на выходе для ASM, Python и C/C++
🛠 Ещё один рантайм для контейнеров, на этот раз, написанный на Rust - youki.

#containers #runtime #youki
== Шаблоны проектирования микросервисов на примере Авито
https://youtu.be/5_9x7czHJOM
- Null Object Pattern (создание заглушки в случае если пришло чтото не то)
- Circuit Breaker ()
- Health Check (для базового случая и для случая под нагрузкой)

мало. скорей про опыт компании по переходу на микросервисы рассказал, чем про паттерны
нарвался на шикарный доклад

== Успехи и провалы с Redis
https://youtu.be/JBIm4sglyQU
- ttl занимает дополнительную память
- удаление ключей происходит при обращении и случайным образом
- ОБЯЗАТЕЛЬНО задать max-memory и max-memory-policy

Persistence & replication
- diskless
- disk-based (default)
- in-memory (for enterprise)

- откличать надо TRANSPARENT_HUGE_PAGES
- vm.overcommmit = 1

не забываем про mem-Fragmentation

не забываем про дополнительные буфферы

Используйте структуру HASH

Используйте Sorted Set (ZSET)
- ограничитель скорости (rate-limiter)
- планировщик задач (scheduler)
- очередь повторов (retry)

не забываем про Транзакции

не забываем что есть LUA-скрипты
- Скрипты кэшируются на конкретных нодах при LOAD и EVAL
- есть проблема со сменой мастера

HA redis:
1) перегрузка мастера
- надо что бы было задержка рестарта ноды была меньше больше чем время фэйловера
- Sentiel динамически обновляют конфигурацию
- Sentiel не забывает реплики

Persistence
- RDB - снапшоты, компактный размер
- AOF - лог операций
- AOF + RDB = гарантии почти как Постгресе
- нужен свой backup noscript + check
- на мастере МОЖНО отклучить персистанс (но надо понимать что делаешь) - ЛУЧШЕ оставить только AOF

Sentinels
- мониторить снаружи (ОПАСНО, так как может резануть сеть от вотчеров)
- мониторить изнутри

Multi-az/rack cluster

Решение с двумя ДЦ
- Есть свой Active-Active без CRDT
- НЕ ДОВЕРЯЙТЕ НАДЕЖНОСТИ СЕТИ !!!!

Не забываем про Шардирование

Pub/Sub
- AT MOST ONCE !
- получат только активные клиенты
- нет гарантий когда произойдет событие

Streams
- Append only
- Body Hash-like
- Consumer Groups

Monitoring & redis_exporter
- сбор метрик = доп нагрузка !
- большинство можно получить из INFO
- Аккуратней с -check-keys = ПРОВЕРЯЕТ ВСЕ
- можно создать LUA скрипт и проверять только то чтонужно (ШИКАРНО!!!)

Редис уже не такой уж и однопоточный
== Карьера в IT: должность CTO
https://dou.ua/lenta/articles/cto-position/

в круг обязанностей CTO могут входить:
— Определение общих стратегий технического развития;
— Принятие глобальных технических решений;
— Внутренний технический арбитраж;
— Выбор технологий, которые будут использоваться в том или ином проекте;
— Оценка этих технологий в плане финансовых и временных затрат;
— Оценка длительности и трудоемкости проектов;
— Планирование и построение процессов разработки;
— Формирование команд разработчиков;
— Распределение задач между командами;
— Отслеживание продвижения проектов;
— Обеспечение темпа и качество разработки на максимально высоком уровне;
— Выбор и внедрение вспомогательных систем для разработки и администрации;
— Экспертные предложения по архитектуре или конкретным техническим решениям;
— Написание кода, обзоры кода, рефакторинг;
— Технический pre-sale ключевых проектов;
— Управление техническими рисками на проектах;
— Общение с другими отделами и топ-менеджерами компании (CEO, COO, CIO и др.);
— Координация работы департаментов;
— Технические собеседования с новыми сотрудниками;
— Оценка продуктивности сотрудников и решение об уровне их зарплат;
— Обучение сотрудников;
— Формирование рабочей атмосферы в коллективе, мотивация сотрудников;
— Разборы полетов с тимлидами:)
== Про Kafka
https://youtu.be/-AZOi3kP9Js
- topic
- partition
- partition balancing
- storage: simple log files, segment
- DELETE NOT PERMITTED !
- ttl удаляет по сегментно
- partition replication
- partition Leader of replicas
- in-sync-replicas (ISR) - надежно! min.insync.replicas = 3
- producer: ack (0,1,-1) -1 означает что ждет подтверждения от всех ISR
- fetch metadata = SYNC operation
- Delivery semantics: AT MOST ONCE, AT LEAST ONCE, EXACTLY ONCE
- consumer: offset, re-balancing

why is it so fast:
- scalable arch
- sequential write and read
- no random read
- zero copy
- several semantics
- fine tuning !

короч можно было книгу не читать. просто посмотрев вовремя этот доклад 😂
== Безграничная память. Как запоминать информацию
https://youtu.be/diEkFaHklJ0
== Изобретая синхронную репликацию
https://youtu.be/I8ijlHkMScY
- репликация
- RAFT

Резервная копия
балансировка запросов

Асинхронная
= для коммита транзакции достаточно что бы запись о ней попала в локальный журнал на мастере, потом сразу коммит, а репликация произойдет позже.
- если мастер отказывает - реплики не получат ничего. транзакция исчезает
- грязные чтения. = чтение данных до того как данные не зафиксированные
+ быстрая
+ высокая доступность
+ легко конфигурировать
+ есть мастер-мастер
- ненадежно. можно потерять данные

Синхронная репликиаця
= мастер записывает в локальный лог транзакцию и сразу раздает кворуму на подтверждение записи в их лог. и после этого коммит
- медленней
- хрупкая доступность
- трудно конфигурировать
- только мастер реплика
+ сложно потерять данные. надежно!

Raft
- каждая нода имеет одну из трех ролей (лидер, реплика, кандидат)
- лидер это тот кто принимает все запросы и отправляет репликам
- реплика это все остальные ноды, которые все скачивают и перенаправляеют все лидеру
- каждая нода изначально реплика
- если лидер не доступен, то реплики превращаются в кандидатов и пытаются выбрать из друг друга лидера
- все время жизни делится на ТЕРМ-ы (логические часы кластера)

синхронность транзакции гарантируется за счет четырех этапного коммита
- данные в журнал лидера
- данные в журнал реплик
- коммит в журнал лидера и ответ пользователю
- коммит в журналы реплик

ОТКАЗ на любом этапе любой ноыд НЕ ПРИВОДИТ К ПОТЕРЕ данных после коммита покаживо 50%+1 нода

Рафт накладывает органичение на журналы (что и как хранится)

У рафта есть и ОТКАТ транзакций

ReplicaID - ID узла создателя
LSN - монотонный счетчик
VClock это пара ReplicaID и LSN
== Серебряная пуля геораспределенных систем
https://youtu.be/1pSHI_4ICbY

и вновь про репликации

синхронная = плохо
асинхронная = плохо

смотрите в бизнеслогику а не в скорость!

по факту всегда есть стейтфулл система. стейтлесс очень редкий кейс
если стейтфул - есть проблема с роутингом

AnyCast это протокол роутинга. который транслирует

Автономная сеть

ip4 адреса закончились =(

если у вас своя автономная сеть - обязательно работать с РосКомНадзором

лучше как то жить с асинхронной репликацией
== Разработка и проектирование высоконагруженных систем (часть 1)
https://youtu.be/KmIE5K6adus

облака не делает сразу HA все что в него положили! облако не избавляет от необходимости думать

кэши не всегда ускоряют
Если попадание 90% то сервис ускоряется в 3.3х
если в 60% то всего 1.7х
если 20% то не приносит пользы!!!
все что меньше 20% то уже ЗАМЕДЛЯЕТ

индексы
- замедляет вставку
- увеличивает РАМ
- усложняет работу планировщика запросов

принцип построения высоконагруженных систем
- максимальная независимость компонент
- отсутствие единой точки отказа (по функциональности, по данным)

Архитектура
1) Сервисно-ориентированная
2) монолитное приложение
3)