Я думаю что этот плагин плохо подходит для работы с бинарными данными из-за наличия разделителей. То есть в качестве разделителя надо выбрать такой символ, которого не может быть в ваших данных. Тут проще и надёжнее делать base64 или что-то похожее, но это увеличит размер данных
Про производительность я в последнем разделе написал, что у нас там нет большой нагрузки и скорее всего в ближайшее время не появится. Поэтому на наших цифрах судить о производительности бессмысленно. У нас сейчас всё работает на дефолтных настройках на серверах, на которых есть и другая нагрузка, и нам пока даже нет смысла тратить время на исследования и оптимизации.
Цифры будут зависеть от многих факторов
Да, вы правы.
Похоже я тут был не совсем точен. Судя по доке ограничение на 250 символов — это ограничение именно memcached, а не memcached-протокола
Также судя по доке, innodb_memcached поддерживает бинарный протокол. Но мы пока использовали только текстовый
Через год сами разработчики уже в собственном коде не могут разобраться
У нас 12-летний легаси и мы как-то справляемся :) С этой проблемой очень помогают правильно настроенные процессы. В частности у нас все коммиты привязаны к тикетам в jira. Поэтому сделав git blame и посмотрев описание коммит а, я вижу в каком тикете были сделаны данные изменения и обычно из тикета ясны почти все детали.
Что касатеся перехода на другие языки, то я в начале статьи писал, что у нас миллионы строк php-кода. Их нельзя по-быстрому переписать на руби или питон. Но у нас есть движение в сторону более активного использования Go.
Напоминаю, что я не автор psalm-а, претензии лучше высказывать напрямую автору
На такой пример psalm ругается — getpsalm.org/r/075628070d, так что я думаю, что дело как раз в обработке ошибок.
вы считаете psalm должен здесь ругаться на то что file_get_contents() может вернуть false?
В этом случае будет сгенерирован warning, многие современные фреймворки конвертируют их в Exception-ы. Анализаторы, как мне кажется, считают что эти случаи можно не анализировать.
Ну, за желания не судят :) До реальных действий дело не дошло
Но про патч я всё-таки поясню.
В типичном PHP-коде, написаном без strict_types, все эти неявные преобразования уже происходят. Такова система типов PHP, по крайней мере до времён strict_types.
PHP-программисты часто используют например var_export($some_var,1) и это работает так, как программист ожидает, хотя вторым параметром надо передавать boolean. Патч показал бы нам такие места.
По-моему непонимание происходит из-за того, что вы воспринимаете кафку как очередную message queue.
В обычных message queue producer кидает событие в очередь, consumer (обычно один) получает это сообщение из очереди и выполняет свою работу и если всё ok, отвечает очереди что сообщение обработано (если это at-least-once) и это сообщение удаляется из очереди.
Кафка может быть использована как очередь сообщений, но в целом это более универсальная штука — распределённый лог событий. Producer добавляют в лог событие. Если кафка отвечает ему ok, это значит что она получила это событие и сохранила его на диск в указанный topic. Всё! Это сообщение больше не потеряется, кафка сохранила его на диск, producer может на этом успокоиться и больше не посылать это сообщение в кафку.
Далее в ход идут consumers. Одно сообщение в кафке может быть обработано несколькимиразными consumer-ами.
То есть например юзер оплатил товар, система сохранила в кафку в topic ORDERS, что такой-то юзер оплатил такой-то товар, который надо доставить по такому-то адресу. Один consumer занимается тем что формирует заявку для склада, другой — добавляет это событие в финансовые отчёты, третий — сохраняет это событие в систему бизнес-аналитики. 3 разных консумера обрабатывают одно и то же событие. И после того как они обработают его, событие из кафки никуда не удаляется, оно там остаётся в течение какого-то времени (день, неделя, месяц — как настроите).
Если в одном из консумеров нашёлся баг, можно исправить баг и перезапустить консумера по всем данным которые есть в topic ORDERS — например перезалить данные в систему бизнес-аналитики.
В такой системе producer вообще не знает, обработано ли его сообщение, потому что он не знает, сколько consumer-ов его обработают и когда они должны его обработать.
Семантика exactly-once на стороне producer-а решает немного другую проблему.
В предыдущем комменте я писал:
consumer должен сам позаботиться чтобы не обработать одну и ту же запись несколько раз. Для этого можно использовать offset, который есть у каждого event-а и который монотонно растёт. То есть клиент может у себя в хранилище сохранять последний обработанный offset и по нему фильтровать дубли
эта штука работает нормально только если в самой кафке нет дублей. То есть в старых версиях могла быть ситуация, когда producer мог сохранить одно и то же сообщение в кафке дважды. В этом случае у этих 2-х сообщений будут разные offset-ы и эта схема дедупликации не сработает (можно делать дедупликацию вручную, зная какие данные у тебя в событии, но тогда для каждого события должен быть свой код для дедупликации)
не уверен что понял вопрос точно
В кафке есть 2 типа «клиентов» — producer (кто сохраняет события в кафку) и consumer (потребляет события)
Механизм exactly-once — он только для producer-ов, то есть если producer по какой-то причине не уверен, сохранилось ли сообщение в кафку (например разрыв соединения), он просто перепошлёт сообщение в кафку с тем же ID и механизм exactly-once гарантирует, что event не будет продублирован
Полагаю что вопрос всё же был про consumer-ов.
Здесь кафка не даёт гарантий exactly-once и consumer должен сам позаботиться чтобы не обработать одну и ту же запись несколько раз. Для этого можно использовать offset, который есть у каждого event-а и который монотонно растёт. То есть клиент может у себя в хранилище сохранять последний обработанный offset и по нему фильтровать дубли
Насколько я понимаю, идеальный вариант — самый первый запрос в HTTP/2 соединении должен вернуть ответ + пушнуть эту таблицу стилей с правильными заголовками, чтобы стили попали в HTTP-кеш. Все последующие запросы внутри этого HTTP/2-соединения не должны пушить эту таблицу стилей, браузер и так из http-кеша возьмёт её. Если соединение разорвалось, то в новом HTTP/2-соединении на первый запрос можно отвечать даже без пуша стилей — они ведь и так есть в кеше. Но определить всё это на стороне сервера — довольно муторное занятие.
Я пока соглашусь с самым первым комментарием: «Слишком мало профита для столь сложной технологии.»
Про производительность я в последнем разделе написал, что у нас там нет большой нагрузки и скорее всего в ближайшее время не появится. Поэтому на наших цифрах судить о производительности бессмысленно. У нас сейчас всё работает на дефолтных настройках на серверах, на которых есть и другая нагрузка, и нам пока даже нет смысла тратить время на исследования и оптимизации.
Цифры будут зависеть от многих факторов
Если мы всё же решимся использовать этот плагин в каком-нибудь высоконагруженном месте, то скорее напишем отдельную статью с цифрами
Похоже я тут был не совсем точен. Судя по доке ограничение на 250 символов — это ограничение именно memcached, а не memcached-протокола
Также судя по доке, innodb_memcached поддерживает бинарный протокол. Но мы пока использовали только текстовый
А докер эту проблему не решает?
Что касатеся перехода на другие языки, то я в начале статьи писал, что у нас миллионы строк php-кода. Их нельзя по-быстрому переписать на руби или питон. Но у нас есть движение в сторону более активного использования Go.
На такой пример psalm ругается — getpsalm.org/r/075628070d, так что я думаю, что дело как раз в обработке ошибок.
В этом случае будет сгенерирован warning, многие современные фреймворки конвертируют их в Exception-ы. Анализаторы, как мне кажется, считают что эти случаи можно не анализировать.
Всё верно. Именно поэтому мы используем все 3 анализатора + тесты + ручное тестирование
Но про патч я всё-таки поясню.
В типичном PHP-коде, написаном без strict_types, все эти неявные преобразования уже происходят. Такова система типов PHP, по крайней мере до времён strict_types.
PHP-программисты часто используют например
var_export($some_var,1)и это работает так, как программист ожидает, хотя вторым параметром надо передавать boolean. Патч показал бы нам такие места.В обычных message queue producer кидает событие в очередь, consumer (обычно один) получает это сообщение из очереди и выполняет свою работу и если всё ok, отвечает очереди что сообщение обработано (если это at-least-once) и это сообщение удаляется из очереди.
Кафка может быть использована как очередь сообщений, но в целом это более универсальная штука — распределённый лог событий. Producer добавляют в лог событие. Если кафка отвечает ему ok, это значит что она получила это событие и сохранила его на диск в указанный topic. Всё! Это сообщение больше не потеряется, кафка сохранила его на диск, producer может на этом успокоиться и больше не посылать это сообщение в кафку.
Далее в ход идут consumers. Одно сообщение в кафке может быть обработано несколькими разными consumer-ами.
То есть например юзер оплатил товар, система сохранила в кафку в topic ORDERS, что такой-то юзер оплатил такой-то товар, который надо доставить по такому-то адресу. Один consumer занимается тем что формирует заявку для склада, другой — добавляет это событие в финансовые отчёты, третий — сохраняет это событие в систему бизнес-аналитики. 3 разных консумера обрабатывают одно и то же событие. И после того как они обработают его, событие из кафки никуда не удаляется, оно там остаётся в течение какого-то времени (день, неделя, месяц — как настроите).
Если в одном из консумеров нашёлся баг, можно исправить баг и перезапустить консумера по всем данным которые есть в topic ORDERS — например перезалить данные в систему бизнес-аналитики.
В такой системе producer вообще не знает, обработано ли его сообщение, потому что он не знает, сколько consumer-ов его обработают и когда они должны его обработать.
Семантика exactly-once на стороне producer-а решает немного другую проблему.
В предыдущем комменте я писал:
эта штука работает нормально только если в самой кафке нет дублей. То есть в старых версиях могла быть ситуация, когда producer мог сохранить одно и то же сообщение в кафке дважды. В этом случае у этих 2-х сообщений будут разные offset-ы и эта схема дедупликации не сработает (можно делать дедупликацию вручную, зная какие данные у тебя в событии, но тогда для каждого события должен быть свой код для дедупликации)
В кафке есть 2 типа «клиентов» — producer (кто сохраняет события в кафку) и consumer (потребляет события)
Механизм exactly-once — он только для producer-ов, то есть если producer по какой-то причине не уверен, сохранилось ли сообщение в кафку (например разрыв соединения), он просто перепошлёт сообщение в кафку с тем же ID и механизм exactly-once гарантирует, что event не будет продублирован
Полагаю что вопрос всё же был про consumer-ов.
Здесь кафка не даёт гарантий exactly-once и consumer должен сам позаботиться чтобы не обработать одну и ту же запись несколько раз. Для этого можно использовать offset, который есть у каждого event-а и который монотонно растёт. То есть клиент может у себя в хранилище сохранять последний обработанный offset и по нему фильтровать дубли
Насколько я понимаю, идеальный вариант — самый первый запрос в HTTP/2 соединении должен вернуть ответ + пушнуть эту таблицу стилей с правильными заголовками, чтобы стили попали в HTTP-кеш. Все последующие запросы внутри этого HTTP/2-соединения не должны пушить эту таблицу стилей, браузер и так из http-кеша возьмёт её. Если соединение разорвалось, то в новом HTTP/2-соединении на первый запрос можно отвечать даже без пуша стилей — они ведь и так есть в кеше. Но определить всё это на стороне сервера — довольно муторное занятие.
Я пока соглашусь с самым первым комментарием: «Слишком мало профита для столь сложной технологии.»
насчёт preload кеша речь, насколько я понимаю, идёт о https://w3c.github.io/preload/
Там в разделе Processing (https://w3c.github.io/preload/#processing) в заметках в конце есть пример, объясняющий почему для preload-а может понадобиться отдельный кеш, а не http-cache