Vamp

Необходимо установить расширение mongodb для самого PHP и дополнительную библиотеку alcaeus/mongo-php-adapter.

Касательно mysql знаю три варианта:

1. Утилита pt-online-schema-change. Создаёт пустую копию исходной таблицы, делает на ней alter, копирует данные из исходной таблицы и в конце меняет местами старую и новую таблицы.

Пользовался этой утилитой пару раз. Хорошо работает.

2. В mysql 5.6 появилась возможность делать alter без блокировок средствами самой субд. Нужно в alter добавить парочку новых параметров:

ALTER TABLE tbl_name ADD PRIMARY KEY (column), ALGORITHM=INPLACE, LOCK=NONE;

Этот вариант я сам не пробовал, поэтому прокомментировать не могу.

3. Самый сложный вариант с использованием двух инстансов mysql, связанных master-master репликацией:

1. Делаем alter на втором сервере
   
2. Ждём, когда второй сервер догонится по репликации
   
3. Переключаем сервис на вторую базу
   
4. Ждем какое-то время, смотрим, нормально ли приложение работает с новой схемой, нет ли деградации или ошибок
   
5. Делаем alter на первой базе
   
6. Ждём догона репликации
   
7. Возвращаем сервис на первую базу
   

С этим вариантом я работаю постоянно. Выглядит просто, но на деле много нюансов.

Нужно обязательно пропускать alter мимо репликации:

SET sql_log_bin = 0;
ALTER TABLE tbl_name ...;

Важно не забыть про sql_log_bin = 0, иначе alter по репликации переедет на соседний сервер и залочит таблицу уже там. А переключать сервис нельзя, пока репликация не догонится.

Если меняется структура таблицы - добавляется/удаляется колонка или меняется их порядок, нужно обязательно проследить чтобы тип репликации обязательно был STATEMENT. Иначе репликация приляжет на первом же запросе в формате ROW с примерно такой странной ошибкой:

Column 25 of table 'mydb.mytable' cannot be converted from type 'varchar(255)' to type 'bigint(20) unsigned'

А со STATEMENT нужно следить чтобы приложение нигде не понижало уровень изоляции ниже REPEATABLE READ, иначе получит ошибку:

Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.

dhparam - это простое число, используемое в алгоритме Диффи-Хеллмана для обмена сессионными ключами с клиентом.

Указание ssl_dhparam делает доступным для использования в nginx семейство алгоритмов DHE/EDH. Как раз тех, что используют Forward Secrecy, о которых пишется в вашей цитате. Если в двух словах, то при использовании алгоритмов с FS злоумышленник не сможет расшифровать перехваченный трафик, даже если завладеет приватным ключом сервера.

Маленькое значение этого простого числа делает возможным атаку logjam на TLS, поэтому следует генерировать большое. 4096 бит будет достаточно с запасом.

Команда для генерации файла dhparam:

openssl dhparam -out /etc/pki/nginx/dhparam.pem 4096

Нужно в настройках самого кластера кафки установить параметр auto.create.topics.enable в значение false

При переадресации на cas вам необходимо передать параметрами куда редиректить пользователя обратно.

Если взять этот сайт для примера (qna.habr.com), то при попытке авторизации перекидывает на

https://account.habr.com/login/?consumer=qna&ostate=bb9acafa489dc93106685c101891cfffb

Обратите внимание на параметр consumer. По нему cas определяет куда возвращать пользователя. При авторизации на хабре в этом параметре будет habr. В хабр карьере будет career. И так далее.

Как вариант можете записать в базу адрес возврата, а cas по переданному идентификатору (параметр state из примера выше) достанет адрес из базы и отправит пользователя на него.

Либо можете прям сразу конкретную ссылку передать:

https://cas.example.org/?return_to=https%3A%2F%2Fexample.com%2Farticles%3Fpage%3D8

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

Вашу задачу в такой постановке вполне можно решить. Вот только склеиванием результатов придётся заниматься вручную.

Создайте топик с результатами и в качестве ключа возьмите order_id. Далее считывайте результаты из топика и складывайте в коллекцию Map<Integer, Set<TaskResult>> (где Integer - order_id). Как только количество элементов в Set станет равным количеству ранее отправленных задач по данному order_id - можно считать, что все ответы получены и передавать их все разом на дальнейшую обработку.

Останется только продумать крайние случаи. Например, нельзя до бесконечности ждать поступления всех результатов - external api может не ответить, а локальная задача вылететь с эксепшеном и не сгенерировать TaskResult. В этом случае количество ответов будет меньше количества отправленных задач. Придется прикручивать таймауты и/или отправлять задачи повторно. А что делать если вдруг ответов поступит больше, чем отправлялось запросов?

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

Можно создавать отдельный топик под каждый order. Здесь упрощается обработка некоторых corner кейсов, но возникает проблема если order'ов много (сотни тысяч - миллионы).

С kafka streams не работал, но бегло пробежав по документации, могу предположить, что комбинация groupByKey() + reduce() может решить вопрос меньшим количеством кода, чем у предыдущих двух вариантов.

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

Существует возможность заменить процесс sh процессом java при помощи команды exec:
sh -c "exec java -jar ol.jar"

В этом случае дочерний процесс займёт место родителя. В частности, получит PID bash процесса, который вам уже известен. Разумеется, если в скрипте после вызова java идут какие-то ещё команды, то они никогда не выполнятся, так как процесс bash перестаёт существовать в момент вызова exec.

Если всё же необходимо выполнить какие-нибудь завершающие команды по окончании работы java процесса, то существует возможность повесить собственные обработчики сигналов:

#!/bin/sh

# Устанавливаем обработчик сигналов HUP INT QUIT TERM и псевдосигнала EXIT.
# В обработчике отправляем сигнал TERM процессу, чей pid будет записан в
# переменной CHILDPID.
trap 'kill $CHILDPID' HUP INT QUIT TERM EXIT

# Запускаем java в фоне.
java -jar ol.jar &

# Сохраняем PID только что запущенного дочернего java процесса.
CHILDPID=$!

# Следующая команда ставит процесс sh на паузу.
# Пауза снимется после завершения фонового java процесса.
# Обработчик сигналов при этом остаётся работоспособным и будет
# корректно отрабатывать во время паузы.
wait

# В этом месте java уже завершилась и можно что-нибудь сделать.
# Например, подчистить временные файлы.
echo Cleanup actions

1. Проверьте синтаксическую корректность номера телефона. Все мобильные номера в РФ начинаются на +79 и имеют длину ровно 11 цифр. Проверку можно даже добавить в веб форму на уровне js. Это нельзя назвать защитой от хулиганов, но она отсеет реальные ошибки и опечатки, облегчив жизнь обычным пользователям.

2. Пробейте номер по базе россвязи (файл DEF-9xx). Так вы определите номера, на которые 100% не будет доставки. В отличии от проверки синтаксиса, не выдавайте пользователю ответ о некорректном номере. На все номера отвечайте "Одноразовый код отправлен, введите его сюда", но на невалидные номера не отправляйте сообщение.

3. Добавьте ограничение на количество отправляемых форм в минуту с одного IP и количество отправляемых сообщений на один и тот же номер (независимо от IP).

4. Оцените сколько может быть отправок форм в день и поставьте общий лимит на все отправки смс за день. Это единственный реальный способ контролировать атаку на сливание бюджета. Да, реальные пользователи пострадают при достижении лимита, но вы не должны доводить до него - настройте мониторинг количества отправляемых смс и алертинг при достижении порога в 90% от лимита, чтобы у вас было время среагировать на атаку и отбить её до полного исчерпания лимита. Либо если это всплеск реальных пользователей (например, неожиданно удачная реакция на рекламу), то у вас будет время скорректировать лимит. Можно рассчитывать лимит как 2 * среднее количество отправок смс за последние Х дней, чтобы не приходилось править его вручную по мере естественного роста посещаемости. Формулу и процент для алертинга, разумеется, подберёте под свои требования. Но можете взять и мои за основу.

Отдельно хочу рассказать про так называемые прямые мобильные номера. Они выглядят как городские (например, +7495), но в реальности являются мобильными и могут принимать смски. Проверка в пункте 1 не пропускает такие номера и нет никакого способа проверить без отправки смс является ли отдельно взятый городской номер прямым мобильным. Прямых номеров мало по сравнению с настоящими мобильными или настоящими городскими. К тому же у каждого прямого номера есть мобильный аналог, начинающийся на +79, которым пользователь может воспользоваться для регистрации. Поэтому предлагаю просто забить на прямые номера, а в случае жалоб на невозможность регистрации с прямым номером, рассказывать про существование мобильного аналога, который может быть прописан где-то в договоре с оператором на оказание услуг связи или узнать в техподдержке оператора и с которым можно спокойно зарегистрироваться.

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

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

Вам нужно явным образом вызвать интерпретатор php и передавать ему путь к скрипту:

cd /var/www/no-name/data/www/oushd.ru/core/channels/channels/ && php /var/www/no-name/data/www/oushd.ru/core/channels/channels/test.php

cd /var/www/no-name/data/www/oushd.ru/core/channels/channels/ && php /var/www/no-name/data/www/oushd.ru/core/channels/channels/channels.php

Архитектурно правильнее возвращать как в примере с Yii2. Использование исключений для управления потоком выполнения программы считается серьёзным антипаттерном.

Например:
1. Исключения в данном случае - просто более хитрая замена оператору GOTO. Надеюсь, не нужно объяснять почему GOTO тоже считается антипаттерном?
2. Программы, написанные в таком стиле, становится сложно читать и понимать.
3. Меньшая эффективность в рантайме, так как большинство современных компиляторов не оптимизированы для случаев использования исключений в качестве управляющей логики.

Более подробно по ссылке.

Единственный официальный способ изменить настройки контейнера - удалить и запустить новый с измененными настройками. Чтобы не терять настройки, удобнее всего записывать их в конфиги формата compose, с которыми работает утилита docker-compose.

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

Задание поставлено очень широко. Листинг из примера ниже будет ему в точности соответствовать:

// Работа с большими объектами
byte[] b = new byte[65536];
b[0] = 1;
System.out.println(b[0]);

// и с маленькими
String s = "123";
System.out.println(s.hashCode());

// и с финализируемыми объектами
Object f = new Object() {
    @Override
    protected void finalize() {
        System.out.println("I'm finalized!");
    }
};
// Строго говоря, объекты b и s так же являются финализируемыми,
// так как наследуют метод finalize() от своего предка.
// Так что f можно было даже не писать.

System.gc();
System.gc();
System.gc();
System.gc();
// В этом месте объекты b, s и f пережили 4 цикла сборки.
// Наверное... ¯\_(ツ)_/¯
//
// Более точно можно сказать, запустив программу с
// аргументом -verbose:gc или с помощью утилиты visualvm

Как правило, трудностей не возникает. Но всё зависит от того, насколько сильно дистрибутив отличается от своей базы. Ubuntu, например, хоть и основан на Debian, но так сильно от него отличается, что искать решение проблем убунту в дебиановских доках практически бесполезно. Но Mint, основанный на Ubuntu, отличается незначительно, поэтому проблемы минта в доках убунты решаются без проблем.

Хорошо работает подход при гуглении - добавлять название дистрибутива к поисковому запросу и если нет успеха, то добавить название базового дистрибутива.

1. "[описание проблемы] kali"
2. "[описание проблемы] debian"
3. "[описание проблемы]" (если предыдущие два варианта облажались, гугление безотносительно дистрибутива - единственный оставшийся вариант)

Потому что нужно устанавливать пакет php7.3-bcmath. На вашем же скриншоте видно, что установилась версия модуля для PHP 7.4: php-bcmath is already the newest version (2:7.4+73+ubuntu18.04.1+deb.sury.org+1)

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

Если хотите точно знать как сильно влияет на производительность то или иное ваше решение в проекте, берите apache bench, siege, yandex.tank и тестируйте. Сразу скажу, разницы между 11 и 5 файлами вы точно не увидите. Впрочем, как между 5 и 555. Но не во всех случаях ответ будет сразу очевиден, поэтому обязательно освойте какую-нибудь тулзу для нагрузочного тестирования и не гадайте на кофейной гуще.

Хранить объект конечно нужно, иначе как клиенту отправлять данные?

Начните с Map, а дальше видно будет. Ещё нужно обязательно предусмотреть регулярную очистку Map от закрывшихся сокетов, иначе получите утечку памяти.

__setSoapHeaders устанавливает заголовки soap запроса, а не http. Они размещаются в элементе Header. По вашему примеру кода получится что-то типа такого:

<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:ns1="yourns"
    xmlns:ns2="http://soapinterop.org/echoheader/">
    <SOAP-ENV:Header>
        <ns2:token>token</ns2:token>
        <ns2:user-token>user_id</ns2:user-token>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <!-- тело запроса -->
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Для добавления именно http заголовков нужно создать stream context:

$aOptions['stream_context'] = stream_context_create([
    'http' => [
        'header' => "token: abc\r\nuser-token: 123"
    ]
]);

$oSoapClient = new SoapClient( $url, $aOptions );
$result = $oSoapClient->__doRequest( $sXml, $url, null, SOAP_1_1 );

Перехват невозможен, так как шифрование трафика производится на уровне приложения, а не ОС. Ваш единственный способ перехвата - mitm. Но если приложение использует certificate/public key pinning, то и mitm вам не поможет.

Время последнего доступа кого угодно к файлу, на который вызываете stat(). Открытие файла и чтение данных из него обновляет метку atime. Причём последнее зарегистрированное время открытия/чтения необязательно могло быть сделано PHP скриптом.