#распределённые_системы — Public Fediverse posts

Advisory Locks в PostgreSQL: блокировки уровня приложения, о которых мало кто знает

Привет, Хабр! PostgreSQL умеет блокировать строки ( SELECT ... FOR UPDATE ) и таблицы ( LOCK TABLE ). Об этом знают все. Но есть третий тип блокировок, который решает задачи, с которыми row-level и table-level locks не справляются: advisory locks. Консультативные блокировки — механизм, где PostgreSQL предоставляет инфраструктуру (атомарные блокировки с очередями ожидания), а семантику определяет приложение. Это значит: вы берёте блокировку по произвольному числовому ключу, и PostgreSQL гарантирует, что никто другой не возьмёт блокировку с тем же ключом одновременно. Никаких таблиц, строк или ресурсов БД не блокируется — это чисто логическая блокировка, видимая только тем, кто её проверяет. Звучит как-то абстрактно. Посмотрим на конкретные задачи, где advisory locks незаменимы.

https://habr.com/ru/companies/otus/articles/1015524/

#psql #advisory_locks #PostgreSQL_блокировки #блокировки_в_БД #конкурентный_доступ #идемпотентность #микросервисная_архитектура #распределённые_системы

Advisory Locks в PostgreSQL: блокировки уровня приложения, о которых мало кто знает

Привет, Хабр! PostgreSQL умеет блокировать строки ( SELECT ... FOR UPDATE ) и таблицы ( LOCK TABLE ). Об этом знают все. Но есть третий тип блокировок, который решает задачи, с которыми row-level и table-level locks не справляются: advisory locks. Консультативные блокировки — механизм, где PostgreSQL предоставляет инфраструктуру (атомарные блокировки с очередями ожидания), а семантику определяет приложение. Это значит: вы берёте блокировку по произвольному числовому ключу, и PostgreSQL гарантирует, что никто другой не возьмёт блокировку с тем же ключом одновременно. Никаких таблиц, строк или ресурсов БД не блокируется — это чисто логическая блокировка, видимая только тем, кто её проверяет. Звучит как-то абстрактно. Посмотрим на конкретные задачи, где advisory locks незаменимы.

https://habr.com/ru/companies/otus/articles/1015524/

#psql #advisory_locks #PostgreSQL_блокировки #блокировки_в_БД #конкурентный_доступ #идемпотентность #микросервисная_архитектура #распределённые_системы

Advisory Locks в PostgreSQL: блокировки уровня приложения, о которых мало кто знает

Привет, Хабр! PostgreSQL умеет блокировать строки ( SELECT ... FOR UPDATE ) и таблицы ( LOCK TABLE ). Об этом знают все. Но есть третий тип блокировок, который решает задачи, с которыми row-level и table-level locks не справляются: advisory locks. Консультативные блокировки — механизм, где PostgreSQL предоставляет инфраструктуру (атомарные блокировки с очередями ожидания), а семантику определяет приложение. Это значит: вы берёте блокировку по произвольному числовому ключу, и PostgreSQL гарантирует, что никто другой не возьмёт блокировку с тем же ключом одновременно. Никаких таблиц, строк или ресурсов БД не блокируется — это чисто логическая блокировка, видимая только тем, кто её проверяет. Звучит как-то абстрактно. Посмотрим на конкретные задачи, где advisory locks незаменимы.

https://habr.com/ru/companies/otus/articles/1015524/

#psql #advisory_locks #PostgreSQL_блокировки #блокировки_в_БД #конкурентный_доступ #идемпотентность #микросервисная_архитектура #распределённые_системы

Advisory Locks в PostgreSQL: блокировки уровня приложения, о которых мало кто знает

Привет, Хабр! PostgreSQL умеет блокировать строки ( SELECT ... FOR UPDATE ) и таблицы ( LOCK TABLE ). Об этом знают все. Но есть третий тип блокировок, который решает задачи, с которыми row-level и table-level locks не справляются: advisory locks. Консультативные блокировки — механизм, где PostgreSQL предоставляет инфраструктуру (атомарные блокировки с очередями ожидания), а семантику определяет приложение. Это значит: вы берёте блокировку по произвольному числовому ключу, и PostgreSQL гарантирует, что никто другой не возьмёт блокировку с тем же ключом одновременно. Никаких таблиц, строк или ресурсов БД не блокируется — это чисто логическая блокировка, видимая только тем, кто её проверяет. Звучит как-то абстрактно. Посмотрим на конкретные задачи, где advisory locks незаменимы.

https://habr.com/ru/companies/otus/articles/1015524/

#psql #advisory_locks #PostgreSQL_блокировки #блокировки_в_БД #конкурентный_доступ #идемпотентность #микросервисная_архитектура #распределённые_системы

Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы

Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. Этот текст основан на спецификации HMP v5.0 (HyperCortex Mesh Protocol) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде. Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения. Следует сразу отметить, что текущая версия спецификации HMP находится в стадии развития и обсуждения: речь идёт не о завершённом стандарте, а о формализуемом протоколе, который эволюционирует по мере экспериментов и обратной связи. При этом по духу HMP ближе к системам работы с артефактами (таким как IPFS) и федеративным протоколам взаимодействия (например, ActivityPub), однако он решает иную задачу — координацию автономных когнитивных агентов без навязывания модели мышления или формата знаний.

https://habr.com/ru/articles/1006566/

#искусственный_интеллект #ИИагенты #многоагентные_системы #децентрализованные_сети #распределённые_системы #протоколы_взаимодействия #автономные_агенты #HMP #HyperCortex_Mesh_Protocol #peertopeer

Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы

Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. Этот текст основан на спецификации HMP v5.0 (HyperCortex Mesh Protocol) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде. Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения. Следует сразу отметить, что текущая версия спецификации HMP находится в стадии развития и обсуждения: речь идёт не о завершённом стандарте, а о формализуемом протоколе, который эволюционирует по мере экспериментов и обратной связи. При этом по духу HMP ближе к системам работы с артефактами (таким как IPFS) и федеративным протоколам взаимодействия (например, ActivityPub), однако он решает иную задачу — координацию автономных когнитивных агентов без навязывания модели мышления или формата знаний.

https://habr.com/ru/articles/1006566/

#искусственный_интеллект #ИИагенты #многоагентные_системы #децентрализованные_сети #распределённые_системы #протоколы_взаимодействия #автономные_агенты #HMP #HyperCortex_Mesh_Protocol #peertopeer

Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы

Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. Этот текст основан на спецификации HMP v5.0 (HyperCortex Mesh Protocol) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде. Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения. Следует сразу отметить, что текущая версия спецификации HMP находится в стадии развития и обсуждения: речь идёт не о завершённом стандарте, а о формализуемом протоколе, который эволюционирует по мере экспериментов и обратной связи. При этом по духу HMP ближе к системам работы с артефактами (таким как IPFS) и федеративным протоколам взаимодействия (например, ActivityPub), однако он решает иную задачу — координацию автономных когнитивных агентов без навязывания модели мышления или формата знаний.

https://habr.com/ru/articles/1006566/

#искусственный_интеллект #ИИагенты #многоагентные_системы #децентрализованные_сети #распределённые_системы #протоколы_взаимодействия #автономные_агенты #HMP #HyperCortex_Mesh_Protocol #peertopeer

Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы

Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. Этот текст основан на спецификации HMP v5.0 (HyperCortex Mesh Protocol) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде. Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения. Следует сразу отметить, что текущая версия спецификации HMP находится в стадии развития и обсуждения: речь идёт не о завершённом стандарте, а о формализуемом протоколе, который эволюционирует по мере экспериментов и обратной связи. При этом по духу HMP ближе к системам работы с артефактами (таким как IPFS) и федеративным протоколам взаимодействия (например, ActivityPub), однако он решает иную задачу — координацию автономных когнитивных агентов без навязывания модели мышления или формата знаний.

https://habr.com/ru/articles/1006566/

#искусственный_интеллект #ИИагенты #многоагентные_системы #децентрализованные_сети #распределённые_системы #протоколы_взаимодействия #автономные_агенты #HMP #HyperCortex_Mesh_Protocol #peertopeer

[Перевод] Всё, что я знаю о хорошем системном дизайне

Хороший системный дизайн редко выглядит эффектно. В нём нет модных паттернов, десятков сервисов и Kafka на каждый чих. Он скучен — и именно поэтому работает. В этой статье автор рассуждает о том, почему простота — не наивность, а зрелость инженерного мышления; как состояние становится главным врагом стабильности; и почему настоящая архитектура рождается не из гениальных трюков, а из понимания границ и закономерностей сложных систем. Разобраться в сути

https://habr.com/ru/companies/otus/articles/960948/

#system_design #system_architecture #системный_дизайн #архитектура_приложений #распределённые_системы #масштабируемость #надежность #базы_данных #проектирование_сервисов

[Перевод] Почему Erlang до сих пор король отказоустойчивых систем

Задумывались ли вы когда-нибудь, как построить самое стабильное приложение в мире? Какими свойствами оно должно обладать и какие архитектурные подходы делают это возможным? Впечатляет, что приложения вроде Discord и WhatsApp выдерживают миллионы одновременных пользователей, тогда как другие задыхаются уже на нескольких тысячах. Сегодня посмотрим, как Erlang позволяет обрабатывать огромную нагрузку и при этом держать систему живой и стабильной. К архитектуре Erlang

https://habr.com/ru/companies/otus/articles/974876/

#высоконагруженные_системы #erlang #отказоустойчивость #архитектура_приложений #масштабирование #распределённые_системы #параллелизм

Когда open/close уже мало: как мы реализовали протокол доступа к 20 000 машин через Bluetooth

Bluetooth в каршеринге — это не «дополнительная фича», а критическая часть сервиса: через него клиент получает доступ к автомобилю, когда бортовой модуль не может связаться с сервером. Надёжность этого канала напрямую влияет на пользовательский опыт и работу всего парка из десятков тысяч машин. В этой статье я расскажу, как мы в Ситидрайве встроили Bluetooth в архитектуру сервиса, чтобы открытие автомобиля работало без мобильной связи. На практике это оказалось далеко не тривиальной задачей: пришлось разбираться с закрытой реализацией модуля от поставщика, решать вопросы безопасности и переносить систему с жёстко зашитых команд на гибкую конфигурацию. Если вы разрабатываете софт для IoT, пишете мобильные приложения, проектируете распределённые системы или просто любите истории о том, как инженерные костыли превращаются в полноценные решения — эта статья для вас.

https://habr.com/ru/companies/citydrive/articles/943792/

#bluetooth #каршеринг #IoT #мобильная_разработка #протоколы_связи #обновление_прошивок #интеграция_оборудования #умные_устройства #grafana #распределённые_системы

Когда open/close уже мало: как мы реализовали протокол доступа к 20 000 машин через Bluetooth

Bluetooth в каршеринге — это не «дополнительная фича», а критическая часть сервиса: через него клиент получает доступ к автомобилю, когда бортовой модуль не может связаться с сервером. Надёжность этого канала напрямую влияет на пользовательский опыт и работу всего парка из десятков тысяч машин. В этой статье я расскажу, как мы в Ситидрайве встроили Bluetooth в архитектуру сервиса, чтобы открытие автомобиля работало без мобильной связи. На практике это оказалось далеко не тривиальной задачей: пришлось разбираться с закрытой реализацией модуля от поставщика, решать вопросы безопасности и переносить систему с жёстко зашитых команд на гибкую конфигурацию. Если вы разрабатываете софт для IoT, пишете мобильные приложения, проектируете распределённые системы или просто любите истории о том, как инженерные костыли превращаются в полноценные решения — эта статья для вас.

https://habr.com/ru/companies/citydrive/articles/943792/

#bluetooth #каршеринг #IoT #мобильная_разработка #протоколы_связи #обновление_прошивок #интеграция_оборудования #умные_устройства #grafana #распределённые_системы

Когда open/close уже мало: как мы реализовали протокол доступа к 20 000 машин через Bluetooth

Bluetooth в каршеринге — это не «дополнительная фича», а критическая часть сервиса: через него клиент получает доступ к автомобилю, когда бортовой модуль не может связаться с сервером. Надёжность этого канала напрямую влияет на пользовательский опыт и работу всего парка из десятков тысяч машин. В этой статье я расскажу, как мы в Ситидрайве встроили Bluetooth в архитектуру сервиса, чтобы открытие автомобиля работало без мобильной связи. На практике это оказалось далеко не тривиальной задачей: пришлось разбираться с закрытой реализацией модуля от поставщика, решать вопросы безопасности и переносить систему с жёстко зашитых команд на гибкую конфигурацию. Если вы разрабатываете софт для IoT, пишете мобильные приложения, проектируете распределённые системы или просто любите истории о том, как инженерные костыли превращаются в полноценные решения — эта статья для вас.

https://habr.com/ru/companies/citydrive/articles/943792/

#bluetooth #каршеринг #IoT #мобильная_разработка #протоколы_связи #обновление_прошивок #интеграция_оборудования #умные_устройства #grafana #распределённые_системы

Как реализовать CRDT-структуры в Go для офлайн-режима

Привет, Хабр! Сегодня мы поговорим о том, как справиться с синхронизацией данных в офлайн-режиме так, чтобы не сваливать на пользователя головную боль слияния конфликтов. Вы наверняка замечали, что многие современные приложения — будь то заметки, менеджеры задач или вики-редакторы — позволяют работать оффлайн на нескольких устройствах, а при подключении к сети автоматически объединяют изменения. Задача разработчика в таком случае сделать максимально гладкую синхронизацию одновременно изменённых данных на разных узлах, ideally без участия пользователя в разрешении конфликтов. Классические решения вроде Operational Transformation давно применяются, например, в совместном редактировании документов. Но сегодня я хочу рассказать про другой подход — CRDT . Перейти к разбору CRDT

https://habr.com/ru/companies/otus/articles/956978/

#golang #crdt #распределённые_системы #синхронизация_данных #офлайнсинхронизация #репликация_данных #консистентность_данных

[Перевод] Когда повторы убивают: метастабильные отказы в распределённых системах

Бывают сбои, которые не исчезают после устранения причины: система залипает, полезная пропускная способность почти нулевая, а петли обратной связи удерживают отказ. В статье формализуем это как метастабильные отказы, разберем цикл «стабильное → уязвимое → метастабильное», характерные метрики и «скрытую ёмкость». Обсудим практики сохранения полезной пропускной способности под перегрузкой: бюджет повторов, приоритеты и отбрасывание запросов, обслуживание «последних первыми», грамотное управление очередями и автомат защиты. Читать про метастабильность

https://habr.com/ru/companies/otus/articles/955442/

#метастабильность #метастабильный_отказ #распределённые_системы #петли_обратной_связи #work_amplification #retry_budget #goodput

Почему сложно писать о передовых информационных технологиях?

Разбираем критику нашей старой статьи. Отвечаем на обвинения нас в невежестве. Показываем, как даже профессионалы необдуманно используют термины. Небольшая статья о терминологии и классификациях.

Веб-сайт: https://causa-arcana.com/blog/2021/08/06/writing-about-it.html
Medium: https://medium.com/causa-arcana/writing-about-it-3d224b7dcc54
IPNS: https://k51qzi5uqu5ditckag7gw12c301kwxac5fpobs62i21uysuiry3bobotvbenmc.ipns.dweb.link/blog/2021/08/06/writing-about-it.html
Tor: http://a4xu7f2nwqxrraaj3qfiao5cgfyrkpuxainvrjszvnzf3y7gzslcu7qd.onion/blog/2021/08/06/writing-about-it.html
Yggdrasil: http://y.causa-arcana.com/blog/2021/08/06/writing-about-it.html

#информатика #технологии #децентрализация #распределённые_системы
@rf

[Перевод] ACID-свойства транзакций в SQL

Для чего существуют принципы ACID? Можно ответить по бумажке, сказать, что это нужно для того, чтобы каждая транзакция обрабатывалась надежно, данные оставались в безопасности и системы работали предсказуемо. Все это в свою очередь должно гарантировать целостность данных. Но что это вообще такое и на что влияет? А ответ очень простой. Обеспечивая целостность данных, мы предупреждаем ситуации, когда, к примеру, деньги со счета списались, но получателю так и не пришли. Или заказ оформился, а складские остатки не обновились. В этой статье вы узнаете, почему так важны принципы ACID и что это за принципы. Оставайтесь со мной, если интересно!

https://habr.com/ru/companies/otus/articles/968212/

#acid #транзакции #реляционные_базы_данных #согласованность_данных #блокировки #распределённые_системы #NoSQL #оптимизация_запросов

[Перевод] Corrosion от Fly.io: сервис-дискавери на Rust и SQLite без кластера

Когда у вас есть глобальная платформа с тысячами машин по всему миру, самая болезненная часть — не сервера и не сеть, а согласование того, кто и где сейчас жив. Команда Fly.io уже успела пройти через зависшие прокси по всему парку, «заразный» дедлок в Rust, DDL-миграции в глобальной базе состояния и истории, когда попытки восстановить соединение с Consul превращали инфраструктуру в обогреватель аплинков. В статье разбирается, как из этих факапов родился Corrosion — сервис-дискавери на Rust и SQLite без распределённого консенсуса и центрального хранилища, построенный по мотивам протоколов маршрутизации вроде OSPF и CRDT-репликации. Это история не только о том, как устроен инструмент, но и о том, какие архитектурные решения для распределённого состояния реально живут в продакшене, а какие красиво смотрятся только на диаграммах. Разобрать Corrosion

https://habr.com/ru/companies/otus/articles/966244/

#распределённые_системы #сервисдискавери #gossipпротокол #CRDT_репликация #Rust #отказоустойчивость_сервисов #протоколы_маршрутизации_OSPF #инцидентменеджмент_SRE