Pull to refresh

Согласованные в конечном счете (Eventually Consistent)

High performance *Distributed systems *
Translation
В последнее время на хабре чаще стали встречаться обсуждения масштабируемых систем и NoSQL решений. Эта статья, написанная техническим директором Amazon — одна из лучших вводных, на мой взгляд, показывающая, какие проблемы возникают при построении масштабируемых систем, что нужно учесть при выборе инструментария, что имеют ввиду авторы кассандры, говоря про обеспечение AP в кассандре и CP в HBase и многое другое.
Читать дальше →
Total votes 45: ↑43 and ↓2 +41
Views 32K
Comments 11

GPRS изнутри. Часть 3

Lumber room
В этой статье мы продолжаем наше знакомство со структурой и основными функциональными элементами пакетной сети оператора мобильной связи, которые мы начали в предыдущих двух статьях — GPRS изнутри. Часть 1 и GPRS изнутри. Часть 2. В нашей сегодняшней заметке речь пойдет об основных интерфейсах сетевых элементов PS Core Network, а также стеках проколов, используемых на этих интерфейсах.

Читать дальше →
Total votes 33: ↑33 and ↓0 +33
Views 40K
Comments 14

Основные тезисы конференции HighLoad++ 2011

Self Promo
imageВ октябре 2011 года в Москве проходила ежегодная конференция разработчиков высоконагруженных проектов HighLoad++.
Решил поделиться с читателями основными тезисами с конференции. Поскольку вся информация открыта и доступна на странице конференции, решил что собрать все тезисы вместе будет не такой уж и плохой затеей. Сразу отмечу, что в отчёте не содержится детальной информации о каждом докладе — затронуты лишь ключевые моменты.
Итак, о чём говорилось на HighLoad++ 2011.
Читать дальше →
Total votes 32: ↑30 and ↓2 +28
Views 4K
Comments 2

Чек-лист преодоления CAP-теоремы

Инфопульс Украина corporate blog System Analysis and Design *Distributed systems *
Translation
Tutorial
Итак, вы ☐ твитнули, ☐ написали в блог, ☐ опубликовали пресс-релиз, ☐ написали в комментариях о том, что знаете способ преодолеть CAP-теорему. Ваша идея не сработает. И вот почему:

☐ вы предполагаете, что сбоев софта\железа\сети никогда не случается
☐ вы на самом деле всего-лишь перенесли проблему на другой логический слой
☐ ваше решение эквивалетно одному уже существующему, которое не преодолевает CAP-теорему
☐ вы на самом деле построили AP-систему (доступность и устойчивость к разделению, но не постоянная согласованность данных)
☐ вы на самом деле построили CP-систему(согласованность данных и устойчивость к разделению, но не постоянная доступность)
☐ вы на самом деле построили нераспределенную систему

А особенно в ваших планах плохо следующее:
Читать дальше →
Total votes 43: ↑35 and ↓8 +27
Views 6.7K
Comments 8

Контроллер Wi-Fi точек доступа на Mikrotik

Wireless technologies *
Sandbox
Tutorial

Введение


В последней версии операционной системы Mikrotik RouterOS под номером 6.11 была добавлена экспериментальная функция, позволяющая использовать роутер на этой платформе в качестве контроллера Wi-Fi точек доступа. К сожалению, так как данный функционал только что появился и находится в статусе бэта, информация о нём ограничевается довольно скучной статьёй на в Wiki-справочнике Mikrotik'а. Пошаговой инструкции по настройке мне найти не удалось, поэтому, решено было попытаться всё настроить методом научного тыка. В данном посте я рассматриваю простую настройку контроллера (не углубляясь в дебри настроек, коих очень много) обеспечивающую следующую конфигурацию (по сути, аналогичную той, что была бы настроена на простом SOHO-роутере уровня D-Link DIR-620 с родной прошивкой, и используемую в домашних условиях):

  • Два Wi-Fi роутера Mikrotik RouterBoard
    • Routerboard RB951G-2HnD — основной, является контроллером Wi-Fi, точкой доступа, маршрутизатором, DHCP- и DNS-сервером. Далее буду именовать его контроллером
    • Routerboard RB951Ui-2HnD — дополнительный, является только точкой доступа Wi-Fi и свитчём на 3 порта (POE in и out порты не включены в свитч и зарезервированы на будущее). Далее буду именовать его точкой доступа или точкой
  • WPA/WPA2-PSK аутентификация с AES-шифрованием
  • Строго определённый канал, с шириной 20МГц
  • Единственный SSID, не скрытый
  • Клиенты не изолированны друг от друга и проводной сети (действительно, зачем это дома?)

Заинтересовавшимся, предлагаю продолжить чтение под катом. Внимание, трафик!
Читать дальше →
Total votes 15: ↑14 and ↓1 +13
Views 192K
Comments 22

Несколько фактов о CAP-«теореме»

Website development *SQL *NoSQL *Distributed systems *
В любом обнаружении NoSQL баз данных кто-нибудь обязательно вспомнит о CAP-«теореме». Я не случайно пишу слово «теорема» в кавычках. CAP-«теорема» вовсе не теорема в математическом понимании этого слова. Это неформальное утверждение, сделанное Эриком Брюером в докладе на конференции Principles of Distributed Computing (PODC) в 2000 году. Эрик утверждал, что невозможно создать распределенное (состоящие из нескольких равноценных экземпляров — звеньев) веб-приложение, которое будет одновременно обладать тремя свойствами: согласованность (consistency), доступность(availability) и устойчивость к разделению(partition tolerance), сокращенно CAP. Неформальность утверждения заключается в том, что Брюер не дал определения этим трем понятиям.

Спустя два года Сет Гилберт и Ненси Линч опубликовали исследование, где дали определения понятиям CAP а также формализовали "отложенную согласованность" (Delayed Consistency), которую потом прозвали "согласованность в конечном счете" (Eventual Consistency) и доказали CAP-«теорему» в терминах указанных определений. Если вы еще не читали исследование, то это обязательно стоит сделать — lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

Эта «теорема» так бы и не была никому нужна, если бы её не взяли на вооружение маркетологи NoSQL.
Читать дальше →
Total votes 27: ↑22 and ↓5 +17
Views 16K
Comments 76

Реплицируемый объект. Часть 1: Введение

Programming *C++ *Algorithms *Concurrent computing *
Translation
Предисловие. Данная публикация является авторским переводом собственной статьи. Поэтому если вы найдёте ошибку в переводе, то вполне может оказаться, что ошибка, на самом деле, в оригинальной статье.

Аннотация


  1. Есть страдание.
  2. Есть причина страдания.
  3. Есть прекращение страдания.
  4. Есть путь, ведущий к избавлению от страданий.

4 благородные истины буддизма

Настоящая статья содержит описание раннего прототипа, который вводит понятие реплицируемого объекта (replicated object) или сокращённо replob. Такой объект является дальнейшим переосмыслением борьбы со сложностью кода, возникающего при программировании распределённых систем. Replob устраняет зависимость от стороннего сервиса и реализует согласованное изменение любых пользовательских объектов, представляющих соответствующие данные и функциональность. Эта идея основана на использовании выразительности языка C++ и объектно-ориентированного подхода, что позволяет использовать сложную логику внутри распределённых транзакций. Это позволяет значительно упростить разработку отказоустойчивых приложений и сервисов. Последующие статьи будут более детально объяснять развиваемый подход.

Введение


ПРЕДУПРЕЖДЕНИЕ. Почти все методы, указанные в статье, содержат грязные хаки памяти и ненормальное использование языка C++. Так что, если вы не толерантны к таким извращениям, пожалуйста, не читайте эту статью.

На текущий момент, тематика, связанная с распределёнными системами, является одной из самых интересных, и привлекают большое количество людей, включая разработчиков и учёных. Популярность объясняется просто: мы должны создавать надежные отказоустойчивые системы, которые обеспечивают безопасную среду для выполнения различных операций и для хранения данных.
Читать дальше →
Total votes 17: ↑14 and ↓3 +11
Views 17K
Comments 17

Всё, что вы не знали о CAP теореме

System Analysis and Design *NoSQL *Distributed systems *
Sandbox
Во время моего первого опыта работы с распределенными системами я постоянно сталкивался с некой CAP-теоремой, пришлось изрядно покопать, чтобы изучить и осознать её со всех сторон. Я не являюсь мастером баз данных, но надеюсь, что мое маленькое исследование мира распределённых систем будет полезно для обычных разработчиков. В статье я расскажу о том, что такое CAP, его проблемы и альтернативы, а также рассмотрим некоторые популярные системы баз данных через CAP призму.
Читать дальше →
Total votes 28: ↑28 and ↓0 +28
Views 79K
Comments 9

Redis Python based cluster. Часть 1: распределённые системы, теоремы CAP и PACELC и зачем нужен Redis

Яндекс Практикум corporate blog High performance *Python *Programming *
Рано или поздно сервисы растут, а с большим RPS приходит Highload.

Что делать, когда ресурсов для вертикального масштабирования Redis уже нет, а данных меньше не становится? Как решить эту задачу без downtime и стоит ли её решать с помощью redis-cluster?

На воркшопе Redis Python based cluster Савва Демиденко и Илья Сильченков пробежались по теории алгоритмов консенсуса и попробовали в реальном времени показать, как можно решить проблему с данными, воспользовавшись sharding’ом, который уже входит в redis-cluster.

Воркшоп растянулся на два часа. Внутри этого поста — сокращённая расшифровка самых важных мыслей.

Введение


Немного о тех, кто провёл воркшоп, и почему вообще его решили провести.

Савва Демиденко

Занимаюсь разработкой в Avito, делаю программу курса «Мидл Python-разработчик» от Яндекс.Практикума. Закончил Бауманку и Технопарк. Разрабатываю на Python и Golang. Люблю решать архитектурные задачи в веб-программировании.

Илья Сильченков

Тимлид в «Сбермаркете» и наставник на курсе «Мидл Python-разработчик». Успел побыть фронтендером и дата-инженером, но остановился на бэкенде. Сейчас пишу на Python и Go.

В рамках нашего курса в «Яндекс.Практикуме» в течение шести месяцев мы делаем онлайн-кинотеатр из множества микросервисов. Сначала пишем маленькую ETL из Elasticsearch и Flask, потом — админку и асинхронное API, авторизацию/аутентификацию и систему уведомлений. В том числе есть маленькая продуктовая задача — пиар в социальных сетях.
Total votes 8: ↑8 and ↓0 +8
Views 4.1K
Comments 0

Redis Python based cluster. Часть 2: зачем нужен Dynamo и что делать, когда Redis больше одного

Яндекс Практикум corporate blog High performance *Python *Programming *
Рано или поздно сервисы растут, а с большим RPS приходит Highload.

Что делать, когда ресурсов для вертикального масштабирования Redis уже нет, а данных меньше не становится? Как решить эту задачу без downtime и стоит ли её решать с помощью redis-cluster?

На воркшопе Redis Python based cluster Савва Демиденко и Илья Сильченков пробежались по теории алгоритмов консенсуса и попробовали в реальном времени показать, как можно решить проблему с данными, воспользовавшись sharding’ом, который уже входит в redis-cluster.


Воркшоп растянулся на два часа. Внутри этого поста — сокращённая расшифровка самых важных мыслей.

В предыдущем посте Савва Демиденко и Илья Сильченков обсудили теорию, поговорили, как и для чего используется Redis, выделили особенности распределённых систем, а также теоремы CAP и PACELC. Теперь узнаем, зачем нужен Dynamo, что делать, когда Redis больше одного, а также ответим на вопросы зрителей.
Total votes 4: ↑4 and ↓0 +4
Views 1.7K
Comments 0

Архитектура на «микросервисах» в монолите: проект из практики

Конференции Олега Бунина (Онтико) corporate blog Skyeng corporate blog PHP *Node.JS *Microservices *

В Skyeng есть команда коммуникаций. Мы предоставляем инструменты для связи оператора с пользователем. Например, ученику плохо слышно преподавателя на уроке и он хочет связаться с поддержкой, чтобы решить проблему — мы помогаем. 

На старте было просто: связаться с нами можно было только через почту. Входящим ящиком был IMAP, исходящим — SaaS сервис по отправке почты, забрать письма с которого было то еще приключение. Мы смотрели на заголовки и соединяли письма в цепочки, как в любом почтовике: Gmail, Outlook. В таком виде передавали операторам. 

Но оказалось, что с теми метаданными, которые мы предоставляли операторам, им было неудобно работать — много времени отнимал поиск пользователей в базе по адресу почты и теме сообщений.

Так появился проект линковка.

Читать далее
Total votes 23: ↑23 and ↓0 +23
Views 10K
Comments 2

CAP двенадцать лет спустя: как изменились «правила»

Timeweb Cloud corporate blog High performance *Programming *System Analysis and Design *Distributed systems *
Translation


Эта статья впервые появилась в журнале Computer и подготовлена InfoQ & IEEE Computer Society.


Теорема CAP гласит, что любая сетевая система с общими данными может иметь только два из трех желаемых свойств. Однако, работая непосредственно с разделениями, разработчики могут оптимизировать согласованность и доступность, тем самым достигая некоторого компромисса между всеми тремя.


За десятилетие, прошедшее с появления теоремы, разработчики и исследователи использовали теорему CAP (а иногда и злоупотребляли ею) как повод для изучения широкого спектра новых распределенных систем. Движение NoSQL также использовало её в качестве аргумента против традиционных баз данных.


В теореме CAP говорится, что любая сетевая система с общими данными может иметь не более двух из трех желаемых свойств:


  • согласованность (С), эквивалентная наличию единственной актуальной копии данных;
  • высокая доступность (A) этих данных (для обновлений); и
  • устойчивость к сетевым разделениям (P).

Такое толкование CAP помогало разработчикам быть открытыми для более широкого диапазона систем и компромиссов; действительно, за последнее десятилетие возникло множество новых систем и много споров об относительных достоинствах согласованности и доступности. Формулировка «2 из 3» всегда вводила в заблуждение, поскольку имела тенденцию чрезмерно упрощать противоречия между свойствами. Но сейчас такие тонкости имеют значение. CAP запрещает лишь крошечную часть проектного пространства: идеальная доступность и согласованность при наличии разделений, которые встречаются редко.

Читать дальше →
Total votes 23: ↑16 and ↓7 +9
Views 3.9K
Comments 11