Pull to refresh
  • by relevance
  • by date
  • by rating

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

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

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

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

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

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

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

Как работает биллинг сотового оператора?

билайн бизнес corporate blog Development of communication systems *

Платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.

Биллинг собирает информацию об использовании телекоммуникационных услуг, их тарификации, отвечает за выставление счетов абонентам и обработку платежей.

Есть 2 основных типа расчета:
  • Постоплата — выставление счёта за период по его итогам (postpaid)
  • И авансовая система (prepaid), когда деньги заносятся заранее.

Постоплата появилась исторически раньше, но предоплата оказалась удобнее для клиентов (контролируемее – чуть что не так, происходит отключение, а не выставляется большой счёт).
Читать дальше →
Total votes 83: ↑78 and ↓5 +73
Views 117K
Comments 43

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

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

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

А особенно в ваших планах плохо следующее:
Читать дальше →
Total votes 43: ↑35 and ↓8 +27
Views 6.6K
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 189K
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 15K
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 16K
Comments 17

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

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