Мы продолжаем публиковать лекции курса «Проектирование высоконагруженных систем», который читается студентам Санкт-Петербургского Политехнического университета командой инженеров из Одноклассников в рамках двухлетней программы «Java-разработчик высоконагруженных приложений» проекта Технополис (совместный проект Mail.Ru Group и СПбПУ). В 2017 году были прочитаны и выложены 10 лекций (30 часов видео), но тема Highload настолько обширна, что за один семестр невозможно охватить всё. Мы лишь ненадолго погрузились в основные аспекты Highload-разработки, каждый из которых достоин отдельного курса. В этом году мы продолжаем закрывать белые пятна и представляем вашему вниманию набор из шести лекций на новые темы: начинаем с параллельных вычислений и livecoding первого этапа студенческого курсового проекта, после чего погружаемся в средства мониторинга и диагностики JVM, а потом переходим к проблемам отказоустойчивости. А после лекции о продвинутых алгоритмах, актуальных в высоконагруженных проектах, завершаем цикл лекцией о существующих подходах к репликации и об их применимости к разным задачам.

Первые десять лекций.

Список новых лекций:

1. Actor Model. Future. Reactive Streams (Вадим Цесько incubos)
2. Livecoding второго этапа проекта (Вадим Цесько incubos)
3. Мониторинг и диагностика JVM (Андрей Паньгин apangin)
4. Site Reliability Engineering (Антон Иванов keyplayer)
5. «Современные» структуры данных (Дмитрий Щитинин dormidoncheg)
6. Репликация (Дмитрий Щитинин dormidoncheg)

Два года назад был опубликован пост с тестированием мультиметров. Цена протестированной модели Fluke 87-V начинается от 40 тысяч рублей, что для рядового пользователя находится за пределами разумного, за что автора закономерно отругали. Более того, часть пользователей разумно заметила, что для проверки батареек хватит и DT 838 за 300 рублей. Таким образом, были охвачены два полюса цен, а есть ли что-то за промежуточные деньги, но с хорошей точностью, осталось неясным. Если интересно — давайте посмотрим.

Как то раз появилась следующая задача: создать локального пользователя в ОС Linux, с ограниченным доступом к папкам и файлам, включая не только редактирование, но и просмотр, а также возможность использовать только разрешенные утилиты. Предусматривается только локальный доступ, сетевого доступа нет.

Что бы не изобретать велосипед, первым делом начал копать интернет, в результате чего были найдены следующие варианты:

• ограничения доступа через сетевые службы ssh, sftp (не подошло)
• разграничение прав доступа самой операционной системой linux (не подошло, хотелось бы универсальное решение)
• использование chroot (не подошло)
• использование сторонних утилит, например SELinux (не подошло, усложняет систему).

В результате поиска, был найден встроенный механизм ограничения возможностей пользователя внутри оболочки bash, он называется Restricted Shell или rbash.

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с использованием стороннего плагина под названием pglogical.

В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.



TL;DR

• Всё получилось (не без костылей, о них и статья).
• Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

HTTP — вещь прекрасная: протокол, который просуществовал более 20 лет без особых изменений.



Это вторая часть серии по веб-безопасности: первая часть была «Как работают браузеры».

Как мы видели в предыдущей статье, браузеры взаимодействуют с веб-приложениями по протоколу HTTP, и это главная причина, по которой мы углубляемся в эту тему. Если пользователи введут данные своей кредитной карты на веб-сайте, а злоумышленник сможет перехватить данные до того, как они попадут на сервер, у нас наверняка будут проблемы.

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

При обсуждении HTTP, тем не менее, мы всегда должны различать семантику и техническую реализацию, поскольку это два совершенно разных аспекта работы HTTP.

Это третья часть серии по веб-безопасности: вторая часть была «Web Security: введение в HTTP», первая "Как работают браузеры — введение в безопасность веб-приложений".

Как мы видели в предыдущих частях этой серии, серверы могут отправлять заголовки HTTP, чтобы предоставить клиенту дополнительные метаданные в ответе, помимо отправки содержимого, запрошенного клиентом. Затем клиентам разрешается указывать, каким образом следует читать, кэшировать или защищать определенный ресурс.

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

В этом руководстве я расскажу, как написать собственную виртуальную машину (VM), способную запускать программы на ассемблере, такие как 2048 (моего друга) или Roguelike (моя). Если вы умеете программировать, но хотите лучше понять, что происходит внутри компьютера и как работают языки программирования, то этот проект для вас. Написание собственной виртуальной машины может показаться немного страшным, но я обещаю, что тема удивительно простая и поучительная.

Окончательный код составляет около 250 строк на C. Достаточно знать лишь основы C или C++, такие как двоичная арифметика. Для сборки и запуска подходит любая Unix-система (включая macOS). Несколько API Unix используются для настройки ввода и отображения консоли, но они не являются существенными для основного кода. (Реализация поддержки Windows приветствуется).

Примечание: эта VM — грамотная программа. То есть вы прямо сейчас уже читаете её исходный код! Каждый фрагмент кода будет показан и подробно объяснён, так что можете быть уверены: ничего не упущено. Окончательный код создан сплетением блоков кода. Репозиторий проекта тут.

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

В статье описан очередной примитивный процессор и ассемблер для него.
Вместо обычных RISC/СISC, процессор не обладает набором инструкций как таковым, есть только единственная инструкция копирования.

Подобные процессоры есть у Maxim серия MAXQ.

https://github.com/pavel212/cpu

Здесь я попытался показать на практике, что собой представляют некоторые важные концепции из области создания компиляторов. Есть вероятность, что подобные 15-минутные завершенные истории могут оказаться неплохим способом погружения в сложные темы. Только хорошо бы не пассивно читать то, что представлено ниже, а еще и проверять код в работе.

Если первый опыт окажется успешным, то в будущем вас могут ожидать и другие 15-минутные "зарисовки" по тематике компиляторов.

Часть I
Часть II
Часть III
Часть IV
Часть V


На данном ресурсе уже была опубликована статья, посвящённая RAM-машине
Wikipedia также содержит статью об этой вычислительной модели

RAM-машина, которая упоминается в книге «Построение и анализ вычислительных алгоритмов» (авторы: Ахо, Хопкрофт, Ульман) имеет ограниченный набор арифметических команд (сложение, вычитание, умножение, деление), команду безусловного перехода, две команды условных переходов. Здесь же из арифметических команд присутствуют только сложение и вычитание, команды ветвления (переходов) будут идентичными командам, приведённым в книге

LIttle Man Computer ссылка обладает схожим набором команд
Online симулятор LMC находится здесь

Схема АЛУ представлена ниже.
Шина соединяет память данных с сумматором (обозначен плюсом), вычитателем (обозначен минусом) и мультиплексором MUX.
Переключение между сумматором и вычитателем производится мультиплексором.
Также в мультиплексор загружаются числовые данные из устройства ввода data_input (в физическом воплощении — это набор переключателей).

Флаги состояния Acc>=0 и Acc=0, а также устройство вывода подключены к выводу аккумулятора


Отличием LIttle Man Computer от RAM-машины является механизм, обеспечивающий косвенную адресацию (возможность работать с числом, хранящемся в памяти, как с адресом).

Для того, чтобы работать с числом, хранящимся в памяти, как с адресом, подключим к адресному входу Памяти Данных мультиплексор MUX, осуществляющий выборку между, собственно, адресом (поступающим из Памяти Команд) и числом, представляющем адрес и хранящемся в Памяти Данных.

Напомню, что термином IoT (Internet of Things) обозначают различные устройства, которые используют выход в сеть для взаимодействия друг с другом. К примеру, умная розетка подключается к Интернету не затем, чтобы сидеть в социальных сетях. Она получает из Сети команды, которые отправляет ее владелец. И она вещь. Вещь, которая пользуется Интернетом.

Сегодняшняя статья будет несколько занудной, поскольку поднимает те вопросы, которые обычно никто обсуждать не любит. И речь в ней пойдет об основных, наиболее важных вопросов связанных с ТБ по работе с лазерами. Я постараюсь рассказать об этой неприятной, но очень важной теме с минимумом нудных букв и цифр, которые так любят приводить в разных «справочниках по правилам безопасной эксплуатации», разобрав основные вопросы с помощью наглядных и доступных примеров в духе «что будет, если». Какую опасность таит в себе лазер, все ли лазеры одинаково опасны? Будем разбираться.

ВНИМАНИЕ: Данная статья может содержать ошибки и неточности, так как я не специалист в медицинских вопросах.

От переводчика: проблема медленного программного обеспечения стала одной из главных тем обсуждения на Хабре и Hacker News в последние недели. Например, см. статью Никиты Прокопова «Моё разочарование в софте» и 2432 комментария к ней.

Мы проводим много времени за компьютером. Ждём каждый раз при запуске приложений и загрузке веб-страниц. Повсюду иконки со спиннером или песочными часами. Железо всё мощнее, но софт по-прежнему кажется медленным. Почему так?

Если вы используете компьютер для выполнения важной работы, то заслуживаете быстрого ПО. Слишком часто современный софт не удовлетворяет этим требованиям. В исследовательской лаборатории Ink & Switch мы изучили причины такой ситуации, программное обеспечение в итоге стало лучше. В этой статье опубликованы результаты нашего исследования.

PHP — это скриптовый язык, который по умолчанию компилирует те файлы, которые вам нужно запустить. Во время компилирования он извлекает опкоды, исполняет их, а затем немедленно уничтожает. PHP был так разработан: когда он переходит к выполнению запроса R, то «забывает» всё, что было выполнено в ходе запроса R-1.

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

Рассказ о том как я участвовал в highloadcup (чемпионат для backend-разработчиков) от Mail.Ru, написал на php сервер обслуживающий 10000 RPS, но всё равно не получил победную футболку.

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

Как и в большинстве других ситуаций с несколькими возможными решениями, дело не в том, какой из вариантов лучше, дело в понимании компромиссов. В этой статье мы сравним Node, Java, Go и PHP из-под Apache, обсудим модели ввода/вывода в разных языках, рассмотрим достоинства и недостатки каждой модели и прогоним простенькие бенчмарки. Если вас волнует производительность ввода/вывода вашего следующего веб-приложения, то эта статья для вас.

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

Размышляя о судьбе ненужных вещей, я прикидывал, что с ними делать: выкинуть, порезать на тряпки, отдать донашивать младшему брату? Но для одной вещи ни один из этих способов не годился: то были кожаные сапоги 44 размера приличного вида, но порядком мне надоевшие. Их я решил продать на Avito. Загрузил фотографии, указал ненастоящее имя (информационная безопасность же), выставил сапоги, пару других вещей и пошёл спать. Откуда мне было знать, что это обернётся длительным анализом приложения на предмет скрытых угроз?

Предыдущая статья цикла: Ретроспектива технологических стартапов. Z3 — первый релейный компьютер



В этой статье продолжаю ретроспективу стартапов. Перенесёмся из Германии Второй Мировой в молодую Россию начала 90-х прошлого столетия. В этот раз будет много примеров о том как это происходило в Зеленограде и попытка ответить на вопрос: “Как и почему в то время бизнесы по производству электроники вырастали с нуля как на дрожжах”.

Но для начала заглянем ненадолго в эпоху заката звезды СССР.