В Ситимобил мы используем базу данных MySQL в качестве основного хранилища постоянных данных. У нас есть несколько кластеров баз данных под различные сервисы и цели.

Постоянная доступность мастера является критическим показателем работоспособности всей системы и ее отдельных частей. Автоматическое восстановление кластера в случае отказа мастера сильно снижает время реагирования на инцидент и время простоя системы. В этой статье я рассмотрю схему обеспечения высокой доступности (HA) кластера MySQL на основе MySQL Orchestrator и виртуальных IP адресов (VIP).

Меня зовут Иван, я руководитель серверной разработки в Ситимобил. Сегодня я расскажу о том, что собой представляет эта самая серверная разработка, с какими проблемами мы сталкивались и как планируем развиваться.

ВКонтакте — один из миллионов сервисов, которые используют NGINX. Open source технологии должны быть свободными.

Дроны — беспилотные летательные аппараты, которыми либо удаленно управляет оператор, либо они двигаются по заранее заданному маршруту. Сейчас эти устройства находятся на пике популярности. Удивляться не приходится, ведь их можно использовать для развлечения, фото- и видеосъемки (в том числе и профессиональных), военной разведки и ведения наблюдения за промышленными системами.

Дроны вовсе не новинка 21 века. Первые прототипы появились даже не в 20-м, а в 19-м веке, когда «цифра» еще не существовала. Что собой представляли предки современных беспилотников и что они умеют сейчас?

Привет, Habr! Представляю вашему вниманию перевод статьи "Building Blockchain in Go. Part 4: Transactions 1".

Содержание

1. Blockchain на Go. Часть 1: Прототип
2. Blockchain на Go. Часть 2: Proof-of-Work
3. Blockchain на Go. Часть 3: Постоянная память и интерфейс командной строки
4. Blockchain на Go. Часть 4: Транзакции, часть 1
5. Blockchain на Go. Часть 5: Адреса
6. Blockchain на Go. Часть 6: Транзакции, часть 2
7. Blockchain на Go. Часть 7: Сеть

Вступление

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

От переводчика:
Это перевод статьи Container runtimes Part 1: An Introduction to Container runtimes.
Автор оригинальной публикации: Ian Lewis.

Один из терминов, который вы часто слышите, имея дело с контейнерами — «container runtime» (далее «runtime» переводится как «среда запуска» — прим. переводчика). «Среда запуска контейнеров» может иметь различные значения для разных людей, так что нет ничего удивительного в том, что это такой сбивающий с толку и смутно понятный термин, даже в самом сообществе пользователей и разработчиков Docker.

Этот пост — первый в серии, которая состоит из 4 частей:

1. Часть 1: Введение в среды запуска контейнеров: почему они так сбивают с толку?
2. Часть 2: Глубокое погружение в низкоуровневые среды запуска (eng)
3. Часть 3: Глубокое погружение в высокоуровневые среды запуска
4. Часть 4: Среды запуска в Kubernetes и CRI

Этот пост объяснит что такое среды запуска контейнеров и откуда столько недопонимания. После этого я углублюсь в различные типы сред запуска контейнеров, что они делают и как они отличаются друг от друга.


(На картинке игра слов: Не уверен относится ли это к средам запуска Kubernetes контейнера, низкоуровневой среде запуска контейнера или продолжительности фильма — примечание переводчика)

Вы прочитали первую часть из этой серии? Если нет, то стоит взглянуть. Не волнуйся, мы подождем...

В прошлой статье мы рассмотрели разработанное приложение на Ethereum. Но обошли стороной вопрос как происходит процесс разработки. Ясно, что это не просто написание кода, который сразу работает. Большую часть времени придется потратить на то, чтобы доводить код, который “почти готов”, до рабочего состояния. Деплой, тестирование, отладка — все это в той или иной мере уже затрагивалось здесь например в этих неплохих статьях: раз, два, три (список не полный). В этой статье мы дадим небольшой обзор и возможно в чем-то повторимся, но постараемся сфокусироваться на тех моментах, которые нам показались важными или недосказанными. Плюс за последнее время некоторые штуки изменились, и огромное количество инструкций оказалось устаревшим. Постараемся немного подправить ситуацию.

Все мы пользуемся динамически-компонуемыми билиотеками. Их возможности поистине великолепны. Во-первых, такая библиотека загружается в физическое адресное пространство только один раз для всех процессов. Во-вторых, можно расширять функционал своей программы, подгружая дополнительную библиотеку, которая и будет этот функционал обеспечивать. И все это без перезапуска самой программы. А еще решается проблема обновлений. Для динамически компонуемой библиотеки можно определить стандартный интерфейс и влиять на функционал и качество своей основной программы, просто меняя версию библиотеки. Такие методы повторного использования кода даже получили название «архитектура plug-in’ов». Но топик не об этом.

Кстати, нетерпеливые могут все скачать и попробовать прямо сейчас.

Deleted Deleted

Всем привет. В этой статье мы рассмотрим основные приемы по публикации смарт-контрактов и взаимодействию с ними с использованием Ethereum RPC API. Обсуждаемые методы API позволяют решать такие задачи:

1. Создание счёта.
2. Создание корректного смарт-контракта.
3. Получение информации со смарт-контракта.
4. Изменение состояния смарт-контракта.

Мы уже рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа и три метода: хеш-индекс, B-дерево и GiST. В этой части речь пойдет о SP-GiST.

SP-GiST

Вначале немного о названии. Слово «GiST» намекает на определенную схожесть с одноименным методом. Схожесть действительно есть: и тот, и другой — generalized search trees, обобщенные деревья поиска, предоставляющие каркас для построения разных методов доступа.

«SP» расшифровывается как space partitioning, разбиение пространства. В роли пространства часто выступает именно то, что мы и привыкли называть пространством — например, двумерная плоскость. Но, как мы увидим, имеется в виду любое пространство поиска, по сути произвольная область значений.

SP-GiST подходит для структур, в которых пространство рекурсивно разбивается на непересекающиеся области. В этот класс входят деревья квадрантов (quadtree), k-мерные деревья (k-D tree), префиксные деревья (trie).

Привет! Меня зовут Макс Матюхин, я работаю в SRV-команде Badoo. Мы в Badoo не только активно пишем посты в свой блог, но и внимательно читаем блоги наших коллег из других компаний. Недавно ребята из Dropbox опубликовали шикарный пост о различных способах оптимизации серверных приложений: начиная с железа и заканчивая уровнем приложения. Его автор – Алексей Иванов – дал огромное количество советов и ссылок на дополнительные источники информации. К сожалению, у Dropbox нет блога на Хабре, поэтому я решил перевести этот пост для наших читателей.

Введение

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

Событие, когда какая-то статья вызывает бурю эмоций, — крайне редкое. Первый раз такое возникло, когда я прочитал про chained replication. Меня пытались убедить, что это мощный подход и что это лучшее, что могло произойти с консистентной репликацией. Я сейчас не буду приводить доводы, почему это плохо работает, а просто приведу говорящую цитату из статьи Chain Replication metadata management:

Split brain management is a thorny problem. The method presented here is one based on pragmatics. If it doesn’t work, there isn’t a serious worry, because Machi’s first serious use case all require only AP Mode. If we end up falling back to “use Riak Ensemble” or “use ZooKeeper”, then perhaps that’s fine enough.

В моем вольном пересказе это означает примерно следующее: "У нас тут есть некий алгоритм. Мы не знаем, будет ли он работать правильно или нет. Да нам это и не важно". Хотя бы честно, сэкономило кучу времени, спасибо авторам.

И тут, значит, попадается на глаза статья: Spanner, TrueTime & The CAP Theorem. Её мы разберем по полочкам ближе к концу, вооружившись понятиями и знаниями. А перед этим разберем самые распространенные мифы, связанные с CAP теоремой.

Оглавление:
Часть 1: Введение и лексический анализ
Часть 2: Реализация парсера и AST
Часть 3: Генерация кода LLVM IR
Часть 4: Добавление JIT и поддержки оптимизатора
Часть 5: Расширение языка: Поток управления
Часть 6: Расширение языка: Операторы, определяемые пользователем
Часть 7: Расширение языка: Изменяемые переменные
Часть 8: Компиляция в объектный код
Часть 9: Добавляем отладочную информацию
Часть 10: Заключение и другие вкусности LLVM

9.1. Заключение

Добро пожаловать в заключительную часть руководства “Создание языка программирования с использованием LLVM”. На протяжении этого руководства, мы вырастили наш маленький язык Калейдоскоп с бесполезной игрушки до довольно интересной (хотя, возможно, по-прежнему бесполезной) игрушки.

Оглавление:

Часть 1: Введение и лексический анализ
Часть 2: Реализация парсера и AST
Часть 3: Генерация кода LLVM IR
Часть 4: Добавление JIT и поддержки оптимизатора
Часть 5: Расширение языка: Поток управления
Часть 6: Расширение языка: Операторы, определяемые пользователем
Часть 7: Расширение языка: Изменяемые переменные
Часть 8: Компиляция в объектный код
Часть 9: Добавляем отладочную информацию
Часть 10: Заключение и другие вкусности LLVM

7.1. Введение

Добро пожаловать в главу 7 руководства “Создание языка программирования с использованием LLVM”. В главах 1-6 мы построили полноценный, хотя и простой, функциональный язык программирования. На этом пути мы изучили некоторые техники парсинга, изучили, как строить и и как представлять AST, как построить LLVM IR, и как оптимизировать результирующий код, и как JIT компилирует его.

Сальвадор Дали, Дезинтеграция постоянства памяти. 1952—1954. Холст, масло.

Всем привет. Кто-то из вас, возможно, уже знаком с СУБД для данных в оперативной памяти, но на всякий случай — по ссылке можно найти их общее описание. Если вкратце, такие СУБД хранят данные целиком в оперативной памяти. Что это означает? Каждый раз, отправляя запрос на поиск или обновление данных, вы обращаетесь только к оперативной памяти в обход жесткого диска — на нем никакие операции не производятся. И это хорошо, потому что оперативная память работает намного быстрее любого диска. Примером такой СУБД является Memcached.

Секундочку, скажете вы, а как же восстановить данные после перезагрузки или поломки машины с такой СУБД? Если на машине установлена СУБД для хранения данных только в оперативной памяти, о них можно забыть: при отключении питания данные бесследно исчезнут.

Можно ли объединить достоинства хранения данных в оперативной памяти с надежностью проверенных временем СУБД вроде MySQL или Postgres? Конечно! Повлияет ли это на производительность? Вы удивитесь, но нет!

В прошлом году мы в летней компьютерной школе проводили кружок по Arduino. Там поучаствовали и преподаватели, в результате чего появилась 8-битная игровая консоль с экраном 64x64.

Теперь же мы решили сделать кружок, в котором ребята смогут создать собственные игры для этой консоли. Благодаря её минимализму, кода должно получиться немного. Всего на кружок было запланировано около 14 часов в течение смены, так что низкий порог входа в программирование таких игр был важной особенностью.


4095 светодиодов и все-все-все

В предыдущей статье мы описали деплой контрактов и взаимодействие с ними через пользовательский интерфейс кошелька Mist, но это не подходит для реальной разработки. Нужна библиотека, которая позволит работать с блокчейном из кода пользовательского приложения. В этой статье мы кратко рассмотрим что представляет собой библиотека Web3.js, пощупав ее из консоли Geth. И еще одна важная тема, которая наверняка интересует не только разработчиков, но и потенциальных заказчиков — сколько стоят транзакции на блокчейне, ведь каждая из них требует газа, который покупается за эфир.

Приветствую бойцов невидимого бэкенда!

Вы уже почитали обзоры MongoDB. Вероятно, прошли отличные онлайн-курсы на university.mongodb.com. Конечно, у вас уже есть многообещающий проект-прототип с использованием MongoDB.

Что мы можем ждать от MongoDB на этом этапе?

• Удешевление хранилища — чтение с ведомых реплик экономит iops мастера, не требуется RAID, отказ одного диска не фатален.
• Повышаем скорость разработки — можно допустить бОльшую небрежность в проектировании структур данных, т.к. мы вполне можем все исправлять на работающем приложении.
• Повышаем отзывчивость приложения — независимо от разработки, легко увеличить число ведущих реплик или количество шардов, чтобы компенсировать возросшую нагрузку на приложение.
• Повышаем надежность приложения — независимо от разработки, убираем единую точку отказа.

И вот, вы готовы ввязаться в бой — выпустить проект на публику.