👍1
Что такое MethodHandle в Java? 🤓
Ответ:
MethodHandle (Java 7) — объект для динамического вызова методов, более гибкий, чем рефлексия.
Пример:
MethodHandle handle = MethodHandles.lookup()
.findVirtual(String.class, "toUpperCase", MethodType.methodType(String.class));
String result = (String) handle.invoke("test"); // TEST
Используется в высокопроизводительных библиотеках.
#собеседование
Ответ:
Пример:
MethodHandle handle = MethodHandles.lookup()
.findVirtual(String.class, "toUpperCase", MethodType.methodType(String.class));
String result = (String) handle.invoke("test"); // TEST
Используется в высокопроизводительных библиотеках.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Серге́й Брин (англ. Sergey Brin; род. 21 августа 1973, Москва, СССР) — американский программист и интернет-предприниматель. Вместе с Ларри Пейджем он стал создателем Google и одноимённой крупнейшей в мире поисковой системы. Брин был президентом Alphabet Inc., материнской компании Google, пока не ушёл с этой должности 3 декабря 2019 года. Брин и Пейдж остаются в Alphabet в качестве соучредителей, контролирующих акционеров, членов совета директоров и сотрудников. По данным Форбс 2025 года, Брин занимает 8-е место в списке самых богатых людей в мире ($110B).
Джон Д. Кармак II (англ. John D. Carmack II; род. 21 августа 1970 года, Канзас, США) — американский разработчик компьютерных игр; инженер в областях информатики, аэрокосмической техники и виртуальной реальности; предприниматель, соучредитель и совладелец компаний id Software и Armadillo Aerospace. В 1991 году Кармак стал одним из основателей компании id Software, которая прославилась разработкой основополагающих игр в жанре FPS — Wolfenstein 3D, Doom, Quake, — ведущим программистом которых был Кармак. Его революционные методы программирования и уникальные дизайнерские решения Джона Ромеро способствовали популярности этого жанра в 1990-х годах.
Стивен Макконнелл Кейс (родился 21 августа 1958 года) — со-основатель и CEO AOL; один из драйверов массового выхода пользователей в интернет в 1990-х.
1888 — патент У. С. Бэрроуза на счётную машину. Важная веха в линии, ведущей к офисной механизации и ранним вычислительным устройствам.
1957 — первый успешный пуск МБР Р-7 с Байконура. Полёт на ~6000–6500 км до Камчатки; именно этот носитель стал «прародителем» спутниковых и пилотируемых ракет семейства «Союз». 27 августа ТАСС официально сообщил об успешном испытании.
1965 — старт Gemini 5 (NASA). Первый длительный полёт по программе Gemini (8 суток), ключевая проверка топливных элементов как источника энергии для лунных экспедиций.
1989 — исследовательский зонд «Вояджер-2» делает снимки Тритона, спутника планеты Нептун.
2006 — началась регистрация доменных имён в новом домене общего пользования .mobi, предназначенном для мобильных устройств.
#Biography #Birth_Date #Events #21Августа
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Основы ООП в Java
Глава 2. Инкапсуляция
Принцип инкапсуляции: скрытие внутреннего состояния
Инкапсуляция — это фундаментальный принцип ООП, который подразумевает объединение данных (состояния) и методов (поведения) в единый модуль — класс — с одновременным скрытием внутренних деталей от внешнего мира. Слово "инкапсуляция" происходит от "капсулы", где важное спрятано внутри, а снаружи виден только необходимый интерфейс.
В ООП инкапсуляция помогает моделировать реальные объекты: например, в автомобиле вы видите руль и педали (интерфейс), но не знаете, как именно работает двигатель внутри (скрытое состояние). Это делает систему более надежной и управляемой.
Скрытие внутреннего состояния — это основа инкапсуляции. Оно означает, что данные объекта (поля) не должны быть напрямую доступны извне класса. Вместо этого внешний код взаимодействует с объектом через контролируемые точки входа.
Вот ключевые аспекты, почему скрытие состояния критично в ООП:
Защита данных от несанкционированных изменений: В реальном мире вы не можете просто открыть капот машины и переставить детали — это может сломать всё. Аналогично, скрытие состояния предотвращает случайные или вредоносные изменения данных, обеспечивая целостность объекта. Например, если поле "возраст" в классе Person скрыто, внешний код не сможет установить отрицательное значение напрямую, что сохранит логическую consistency.
Модульность и независимость: Скрытие позволяет изменять внутреннюю реализацию класса (например, структуру данных) без влияния на внешний код. Это делает систему модульной: один класс можно обновить, не ломая другие. В больших проектах это упрощает поддержку и масштабирование.
Снижение сложности: Внешний код видит только "черный ящик" — что объект может делать, но не как. Это уменьшает когнитивную нагрузку: разработчику не нужно знать все детали, чтобы использовать класс. Например, в библиотеке вы вызываете метод, не вникая в его внутреннюю логику.
Повышение безопасности: В enterprise-приложениях скрытие состояния защищает чувствительные данные (например, пароли или финансовую информацию) от прямого доступа, минимизируя риски утечек или ошибок.
Поддержка принципа "информационного скрытия": Это концепция из ООП, где класс раскрывает только необходимую информацию. Скрытие помогает избежать "спагетти-кода", где всё связано со всем, и способствует созданию чистых, самодокументируемых систем.
Без скрытия состояния ООП теряет силу: объекты становятся просто контейнерами данных, как в процедурном программировании, что приводит к хаосу в сложных системах.
Концептуальный пример
Представьте класс BankAccount (Банковский счет).
Внутреннее состояние — это баланс и номер счета.
Без скрытия любой код мог бы напрямую изменить баланс, что привело бы к ошибкам (например, отрицательный баланс). С инкапсуляцией состояние скрыто, и внешний код может только вносить/снимать деньги через контролируемые операции, обеспечивая валидацию и логику.
Это демонстрирует, как инкапсуляция делает объекты надежными "капсулами" с защищенным содержимым.
Полезные советы для новичков
Думайте как дизайнер: При создании класса спрашивайте: "Что внешний код должен знать о состоянии? Что можно скрыть?"
Преимущества в практике: В реальных проектах скрытие состояния упрощает отладку — ошибки локализуются внутри класса.
Связь с другими принципами ООП: Инкапсуляция закладывает основу для наследования и полиморфизма, где подклассы могут переопределять поведение без нарушения скрытия.
Ресурсы: Почитайте "Clean Code" Роберта Мартина — там много о принципах ООП, включая инкапсуляцию.
#Java #для_новичков #beginner #incapsulation
Глава 2. Инкапсуляция
Принцип инкапсуляции: скрытие внутреннего состояния
Инкапсуляция — это фундаментальный принцип ООП, который подразумевает объединение данных (состояния) и методов (поведения) в единый модуль — класс — с одновременным скрытием внутренних деталей от внешнего мира. Слово "инкапсуляция" происходит от "капсулы", где важное спрятано внутри, а снаружи виден только необходимый интерфейс.
В ООП инкапсуляция помогает моделировать реальные объекты: например, в автомобиле вы видите руль и педали (интерфейс), но не знаете, как именно работает двигатель внутри (скрытое состояние). Это делает систему более надежной и управляемой.
Скрытие внутреннего состояния — это основа инкапсуляции. Оно означает, что данные объекта (поля) не должны быть напрямую доступны извне класса. Вместо этого внешний код взаимодействует с объектом через контролируемые точки входа.
Вот ключевые аспекты, почему скрытие состояния критично в ООП:
Защита данных от несанкционированных изменений: В реальном мире вы не можете просто открыть капот машины и переставить детали — это может сломать всё. Аналогично, скрытие состояния предотвращает случайные или вредоносные изменения данных, обеспечивая целостность объекта. Например, если поле "возраст" в классе Person скрыто, внешний код не сможет установить отрицательное значение напрямую, что сохранит логическую consistency.
Модульность и независимость: Скрытие позволяет изменять внутреннюю реализацию класса (например, структуру данных) без влияния на внешний код. Это делает систему модульной: один класс можно обновить, не ломая другие. В больших проектах это упрощает поддержку и масштабирование.
Снижение сложности: Внешний код видит только "черный ящик" — что объект может делать, но не как. Это уменьшает когнитивную нагрузку: разработчику не нужно знать все детали, чтобы использовать класс. Например, в библиотеке вы вызываете метод, не вникая в его внутреннюю логику.
Повышение безопасности: В enterprise-приложениях скрытие состояния защищает чувствительные данные (например, пароли или финансовую информацию) от прямого доступа, минимизируя риски утечек или ошибок.
Поддержка принципа "информационного скрытия": Это концепция из ООП, где класс раскрывает только необходимую информацию. Скрытие помогает избежать "спагетти-кода", где всё связано со всем, и способствует созданию чистых, самодокументируемых систем.
Без скрытия состояния ООП теряет силу: объекты становятся просто контейнерами данных, как в процедурном программировании, что приводит к хаосу в сложных системах.
Концептуальный пример
Представьте класс BankAccount (Банковский счет).
Внутреннее состояние — это баланс и номер счета.
Без скрытия любой код мог бы напрямую изменить баланс, что привело бы к ошибкам (например, отрицательный баланс). С инкапсуляцией состояние скрыто, и внешний код может только вносить/снимать деньги через контролируемые операции, обеспечивая валидацию и логику.
Это демонстрирует, как инкапсуляция делает объекты надежными "капсулами" с защищенным содержимым.
Полезные советы для новичков
Думайте как дизайнер: При создании класса спрашивайте: "Что внешний код должен знать о состоянии? Что можно скрыть?"
Преимущества в практике: В реальных проектах скрытие состояния упрощает отладку — ошибки локализуются внутри класса.
Связь с другими принципами ООП: Инкапсуляция закладывает основу для наследования и полиморфизма, где подклассы могут переопределять поведение без нарушения скрытия.
Ресурсы: Почитайте "Clean Code" Роберта Мартина — там много о принципах ООП, включая инкапсуляцию.
#Java #для_новичков #beginner #incapsulation
👍1
Что выведет код
#Tasks
class Wallet210825 {
public int money;
public Wallet210825(int money) {
this.money = money;
}
}
public class Task210825 {
public static void main(String[] args) {
Wallet210825 wallet = new Wallet210825(100);
addMoney(wallet, 50);
System.out.println(wallet.money);
}
public static void addMoney(Wallet210825 w, int amount) {
w = new Wallet210825(w.money + amount);
}
}
#Tasks
👍3
🔥2
Что такое Pattern и Matcher в Java? 🤓
Ответ:
Классы Pattern и Matcher (пакет java.util.regex) используются для работы с регулярными выражениями. Пример:
Pattern pattern = Pattern.compile("\\d+");
Matcher matcher = pattern.matcher("123 abc");
while (matcher.find()) {
System.out.println( matcher.group ()); // 123
}
Подходят для парсинга строк и валидации.
#собеседование
Ответ:
Pattern pattern = Pattern.compile("\\d+");
Matcher matcher = pattern.matcher("123 abc");
while (matcher.find()) {
System.out.println(
}
Подходят для парсинга строк и валидации.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Пауль Юлиус Готлиб Нипков (нем. Paul Julius Gottlieb Nipkow, 22 августа 1860, Лауэнбург — 24 августа 1940, Берлин) — немецкий техник и изобретатель. Изобретённый им диск, получивший название диск Нипкова, послужил основой для появления механического телевидения в 1920-x годах.
Бру́но Макси́мович Понтеко́рво (итал. Bruno Pontecorvo; 22 августа 1913, Марина-ди-Пиза[итал.], Королевство Италия — 24 сентября 1993, Дубна, Московская область, Россия) — итальянский и советский физик-ядерщик, один из первых помощников Энрико Ферми и автор многочисленных исследований в области физики высоких энергий, особенно посвящённых нейтрино. Убеждённый коммунист, он бежал в Советский Союз в 1950 году, где продолжил исследования распада мюона и нейтрино. В его память в 1995 году была учреждена престижная премия Понтекорво.
Джеймс Рамбо (англ. James Rumbaugh, род. 1947) — американский учёный в области информатики и объектной методологии, наиболее известный по своей работе над созданием технологии объектного моделирования (OMT) и языка моделирования UML.
Сами Эрол Геленбе (родился 22 августа 1945 года в Стамбуле) — турецкий и французский учёный в области информатики , инженер-электронщик и прикладной математик , известный своими новаторскими работами в области производительности компьютерных систем и сетей.
Джон М. Чоунинг (/ ˈ tʃ aʊ n ɪ ŋ / ; родился 22 августа 1934 года в Сейлеме, штат Нью-Джерси) — американский композитор, музыкант, первооткрыватель и профессор, наиболее известный своей работой в Стэнфордском университете , основанием CCRMA — Центра компьютерных исследований в области музыки и акустики в 1975 году и разработкой им цифровой реализации FM-синтеза и цифрового звукового пространственного представления во время работы там.
Масатоси Сима (яп. 嶋正利; р. 1943) — японский инженер-электронщик, один из архитекторов первого в мире микропроцессора Intel 4004 (работая со стороны Busicom).
1955 — основана первая группа пользователей компьютеров (SHARE). После симпозиума IBM участники, использующие мейнфрейм IBM 704, встретились в RAND Corporation и создали SHARE — платформу обмена софтом и документацией для IBM-установок.
1958 — Йсенхауэр объявляет о трехстороннем моратории на ядерные испытания, при условии участия СССР и Великобритании. Мораторий должен был вступить в силу 31 октября.
1960 — в Женеве отложены переговоры США, СССР и Великобритании по договору о запрете ядерных испытаний. Это политико-техническое событие с долгосрочными последствиями в международной безопасности.
1961 — Международный астрономический союз официально утвердил названия деталей обратной стороны Луны, сфотографированных АМС «Луна-3»
1962 — атомоход N.S. Savannah (первое в мире судно на ядерной энергии) совершает своё первое прибытие в Савану, штат Джорджия, продвигая мирное использование энергии.
1989 — открыты кольца Нептуна.
#Biography #Birth_Date #Events #22Августа
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Apache Kafka
Безопасность, мониторинг и эксплуатация
Apache Kafka в производственной среде требует тщательного подхода к безопасности, мониторингу и эксплуатации для обеспечения стабильности, масштабируемости и восстановления после сбоев.
Безопасность: TLS/SSL, SASL (SCRAM, OAUTHBEARER), ACLs
Безопасность в Kafka строится на шифровании трафика, аутентификации и авторизации для предотвращения утечек данных и атак.
- TLS/SSL: Шифрование соединений для защиты данных в полёте. Настраивается через listeners (прослушиватели), где указывается протокол SASL_SSL или SSL. Брокеры используют keystore (хранилище ключей) для серверных сертификатов и truststore для проверки клиентов.
В памяти брокера: SSL контекст загружается при старте, handshake происходит на сетевом уровне с использованием Java Secure Socket Extension (JSSE). Нюанс: overhead на CPU для шифрования (до 20% при высокой нагрузке), используйте hardware acceleration если возможно.
- SASL (Simple Authentication and Security Layer): Аутентификация клиентов.
Поддерживает механизмы:
- SCRAM (Salted Challenge Response Authentication Mechanism): Безопасный парольный механизм (SHA-256 или SHA-512). Пароли хранятся в ZooKeeper или KRaft в зашифрованном виде. В процессе: клиент посылает challenge-response, брокер проверяет без передачи пароля.
- OAUTHBEARER: Интеграция с OAuth 2.0 для токенов (JWT). Полезно для интеграции с внешними системами (например, Keycloak).
В памяти: токены валидируются через callback handler, overhead на верификацию сигнатуры.
- ACLs (Access Control Lists): Авторизация операций (READ, WRITE, CREATE и т.д.) по пользователям и ресурсам (темы, группы потребителей). Настраивается через authorizer.class.name (KafkaAuthorizer). ACL хранятся в ZooKeeper/KRaft, загружаются в память брокера как Map<Principal, Set<AclEntry>>. При запросе брокер проверяет ACL перед выполнением, добавляя минимальный latency (миллисекунды).
Компромиссы: полная безопасность (TLS + SASL + ACL) снижает производительность на 10-15%, но обязательна для compliance (GDPR, PCI DSS).
Мониторинг: JMX, Prometheus, key metrics, consumer lag tracking
Мониторинг позволяет выявлять узкие места и предотвращать сбои.
- JMX (Java Management Extensions): Встроенный в Kafka для экспорта метрик (MBeans). Брокеры экспортируют метрики вроде kafka.server:type=BrokerTopicMetrics,name=TotalProduceRequestsPerSec.
В памяти: JMX registry держит beans, polling через JmxExporter.
- Prometheus: Интеграция через JMX Exporter (sidecar) или Kafka Exporter. Собирает метрики в формате для Grafana.
Ключевые метрики:
- Брокеры: under-replicated-partitions (недореплицированные разделы), active-controller-count (активный контроллер, должен быть 1), request-queue-size (очередь запросов, >100 — bottleneck).
- Продюсеры: produce-throttle-time-avg (задержка из-за квот), record-error-rate (ошибки отправки).
- Потребители: records-lag-max (максимальное отставание).
- Отслеживание отставания потребителей (consumer lag): Lag = log-end-offset - committed-offset. Мониторится через KafkaConsumer.metrics() или Burrow/LinkedIn's Kafka Monitor.
В памяти потребителя: fetch metadata включает LEO, lag вычисляется локально. Нюанс: высокий lag (>1M) указывает на slow processing; alerting на threshold.
В эксплуатации: настройте dashboards в Grafana для визуализации, с retention метрик 15-30 дней.
#Java #middle #Kafka #Kafka_securiy
Безопасность, мониторинг и эксплуатация
Apache Kafka в производственной среде требует тщательного подхода к безопасности, мониторингу и эксплуатации для обеспечения стабильности, масштабируемости и восстановления после сбоев.
Безопасность: TLS/SSL, SASL (SCRAM, OAUTHBEARER), ACLs
Безопасность в Kafka строится на шифровании трафика, аутентификации и авторизации для предотвращения утечек данных и атак.
- TLS/SSL: Шифрование соединений для защиты данных в полёте. Настраивается через listeners (прослушиватели), где указывается протокол SASL_SSL или SSL. Брокеры используют keystore (хранилище ключей) для серверных сертификатов и truststore для проверки клиентов.
В памяти брокера: SSL контекст загружается при старте, handshake происходит на сетевом уровне с использованием Java Secure Socket Extension (JSSE). Нюанс: overhead на CPU для шифрования (до 20% при высокой нагрузке), используйте hardware acceleration если возможно.
- SASL (Simple Authentication and Security Layer): Аутентификация клиентов.
Поддерживает механизмы:
- SCRAM (Salted Challenge Response Authentication Mechanism): Безопасный парольный механизм (SHA-256 или SHA-512). Пароли хранятся в ZooKeeper или KRaft в зашифрованном виде. В процессе: клиент посылает challenge-response, брокер проверяет без передачи пароля.
- OAUTHBEARER: Интеграция с OAuth 2.0 для токенов (JWT). Полезно для интеграции с внешними системами (например, Keycloak).
В памяти: токены валидируются через callback handler, overhead на верификацию сигнатуры.
- ACLs (Access Control Lists): Авторизация операций (READ, WRITE, CREATE и т.д.) по пользователям и ресурсам (темы, группы потребителей). Настраивается через authorizer.class.name (KafkaAuthorizer). ACL хранятся в ZooKeeper/KRaft, загружаются в память брокера как Map<Principal, Set<AclEntry>>. При запросе брокер проверяет ACL перед выполнением, добавляя минимальный latency (миллисекунды).
Компромиссы: полная безопасность (TLS + SASL + ACL) снижает производительность на 10-15%, но обязательна для compliance (GDPR, PCI DSS).
Мониторинг: JMX, Prometheus, key metrics, consumer lag tracking
Мониторинг позволяет выявлять узкие места и предотвращать сбои.
- JMX (Java Management Extensions): Встроенный в Kafka для экспорта метрик (MBeans). Брокеры экспортируют метрики вроде kafka.server:type=BrokerTopicMetrics,name=TotalProduceRequestsPerSec.
В памяти: JMX registry держит beans, polling через JmxExporter.
- Prometheus: Интеграция через JMX Exporter (sidecar) или Kafka Exporter. Собирает метрики в формате для Grafana.
Ключевые метрики:
- Брокеры: under-replicated-partitions (недореплицированные разделы), active-controller-count (активный контроллер, должен быть 1), request-queue-size (очередь запросов, >100 — bottleneck).
- Продюсеры: produce-throttle-time-avg (задержка из-за квот), record-error-rate (ошибки отправки).
- Потребители: records-lag-max (максимальное отставание).
- Отслеживание отставания потребителей (consumer lag): Lag = log-end-offset - committed-offset. Мониторится через KafkaConsumer.metrics() или Burrow/LinkedIn's Kafka Monitor.
В памяти потребителя: fetch metadata включает LEO, lag вычисляется локально. Нюанс: высокий lag (>1M) указывает на slow processing; alerting на threshold.
В эксплуатации: настройте dashboards в Grafana для визуализации, с retention метрик 15-30 дней.
#Java #middle #Kafka #Kafka_securiy
👍1
Тюнинг: параметры брокеров (num.partitions, min.insync.replicas, log.retention.hours), GC tuning для Java 21
Тюнинг оптимизирует под нагрузку.
- Параметры брокеров:
- num.partitions: Количество разделов по умолчанию для новых топиков (default 1). Больше — выше parallelism, но overhead на метаданные (каждый раздел — ~1 МБ RAM на брокере).
- min.insync.replicas: Минимальное количество синхронизированных реплик для acks=all (default 1). Установите 2 для durability, но снижает availability при сбоях.
- log.retention.hours: Время хранения логов (default 168 часов). Баланс: дольше — больше диск, короче — риск потери для replay.
- GC tuning для Java 21: Kafka работает на JVM, GC (сборка мусора) влияет на latency. Используйте Shenandoah или ZGC для low-pause (sub-ms).
Параметры: -XX:+UseZGC -XX:ZCollectionInterval=10 (интервал 10 сек), -XX:MaxGCPauseMillis=5.
В памяти: ZGC использует colored pointers для concurrent marking, снижая паузы. Нюанс: для heap >64GB добавьте -XX:+ZGenerational для generational mode. Тестируйте с GC logs (-Xlog:gc*).
Компромиссы: агрессивный тюнинг снижает latency, но требует benchmark (k6 или Kafka's perf tools).
Восстановление после катастроф: MirrorMaker 2, репликация между регионами
Disaster recovery обеспечивает continuity.
- MirrorMaker 2 (MM2): Инструмент для зеркалирования тем между кластерами (active-passive или active-active). Работает как consumer-producer: читает из source, пишет в target. Поддерживает offset translation, topic renaming. В памяти: MM2 использует Connect framework, с tasks для parallelism.
- Репликация между регионами: Настройте MM2 с remote clusters, используя topics like mm2-offset-syncs для синхронизации offset'ов. Для cross-DC: настройте replication.factor>1, с geo-aware rack.aware.mode. Нюанс: latency добавляет 100-500 мс, мониторьте replication lag.
Стратегия: регулярные drills, с failover скриптами (изменение bootstrap.servers в клиентах).
Пример конфигурации безопасности (ZooKeeper и KRaft)
Вот пример конфигурации брокера для SASL_SSL с SCRAM (работает как с ZooKeeper, так и KRaft):
В production: генерируйте сертификаты с CA (Let's Encrypt или self-signed), храните секреты в Vault.
#Java #middle #Kafka #Kafka_securiy
Тюнинг оптимизирует под нагрузку.
- Параметры брокеров:
- num.partitions: Количество разделов по умолчанию для новых топиков (default 1). Больше — выше parallelism, но overhead на метаданные (каждый раздел — ~1 МБ RAM на брокере).
- min.insync.replicas: Минимальное количество синхронизированных реплик для acks=all (default 1). Установите 2 для durability, но снижает availability при сбоях.
- log.retention.hours: Время хранения логов (default 168 часов). Баланс: дольше — больше диск, короче — риск потери для replay.
- GC tuning для Java 21: Kafka работает на JVM, GC (сборка мусора) влияет на latency. Используйте Shenandoah или ZGC для low-pause (sub-ms).
Параметры: -XX:+UseZGC -XX:ZCollectionInterval=10 (интервал 10 сек), -XX:MaxGCPauseMillis=5.
В памяти: ZGC использует colored pointers для concurrent marking, снижая паузы. Нюанс: для heap >64GB добавьте -XX:+ZGenerational для generational mode. Тестируйте с GC logs (-Xlog:gc*).
Компромиссы: агрессивный тюнинг снижает latency, но требует benchmark (k6 или Kafka's perf tools).
Восстановление после катастроф: MirrorMaker 2, репликация между регионами
Disaster recovery обеспечивает continuity.
- MirrorMaker 2 (MM2): Инструмент для зеркалирования тем между кластерами (active-passive или active-active). Работает как consumer-producer: читает из source, пишет в target. Поддерживает offset translation, topic renaming. В памяти: MM2 использует Connect framework, с tasks для parallelism.
- Репликация между регионами: Настройте MM2 с remote clusters, используя topics like mm2-offset-syncs для синхронизации offset'ов. Для cross-DC: настройте replication.factor>1, с geo-aware rack.aware.mode. Нюанс: latency добавляет 100-500 мс, мониторьте replication lag.
Стратегия: регулярные drills, с failover скриптами (изменение bootstrap.servers в клиентах).
Пример конфигурации безопасности (ZooKeeper и KRaft)
Вот пример конфигурации брокера для SASL_SSL с SCRAM (работает как с ZooKeeper, так и KRaft):
# Прослушиватели
listeners=SASL_SSL://:9092
advertised.listeners=SASL_SSL://broker-host:9092
# SSL настройки
ssl.keystore.location=/etc/kafka/secrets/kafka.keystore.jks
ssl.keystore.password=keystore-pass
ssl.truststore.location=/etc/kafka/secrets/kafka.truststore.jks
ssl.truststore.password=truststore-pass
ssl.client.auth=required # Требовать клиентские сертификаты
# SASL
sasl.enabled.mechanisms=SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
# Для KRaft добавьте:
process.roles=broker,controller
controller.listener.names=CONTROLLER
listener.security.protocol.map=CONTROLLER:PLAINTEXT,SASL_SSL:SASL_SSL
# ACL
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
super.users=User:admin
allow.everyone.if.no.acl.found=false
В production: генерируйте сертификаты с CA (Let's Encrypt или self-signed), храните секреты в Vault.
#Java #middle #Kafka #Kafka_securiy
👍1
Нюансы
- Планирование ёмкости по количеству разделов: Разделы — единица parallelism, но лимит ~4K на брокер (из-за открытых файлов, RAM ~10 КБ на раздел). Планируйте: throughput / partition-throughput (например, 10 МБ/с на раздел). Для 100K TPS — 100 разделов. Нюанс: слишком много (>1M в кластере) замедляет контроллер (leader election до минут); используйте формулу: num_partitions = (desired_throughput / partition_throughput) * replication_factor.
- Оповещения по недореплицированным разделам: Метрика kafka.server:ReplicaManager:UnderReplicatedPartitions >0 сигнализирует о проблемах (сбой фолловера). Alerting в Prometheus: alert если >0 >5 мин, с playbook (проверить network, restart брокер). Нюанс: chronic under-replication приводит к data loss при unclean election.
- Типичные антипаттерны:
- Слишком много разделов: Приводит к overhead (метаданные, ZK load в старых версиях). Решение: consolidate темы, используйте compaction.
- Unclean election (unclean.leader.election.enable=true): Позволяет non-ISR лидеру, рискуя потерей данных. Держите false, жертвуйте availability.
- Отключенный мониторинг: Без alerting на lag или CPU>80% сбои незаметны. Всегда интегрируйте с ELK/Prometheus, с on-call ротацией.
#Java #middle #Kafka #Kafka_securiy
- Планирование ёмкости по количеству разделов: Разделы — единица parallelism, но лимит ~4K на брокер (из-за открытых файлов, RAM ~10 КБ на раздел). Планируйте: throughput / partition-throughput (например, 10 МБ/с на раздел). Для 100K TPS — 100 разделов. Нюанс: слишком много (>1M в кластере) замедляет контроллер (leader election до минут); используйте формулу: num_partitions = (desired_throughput / partition_throughput) * replication_factor.
- Оповещения по недореплицированным разделам: Метрика kafka.server:ReplicaManager:UnderReplicatedPartitions >0 сигнализирует о проблемах (сбой фолловера). Alerting в Prometheus: alert если >0 >5 мин, с playbook (проверить network, restart брокер). Нюанс: chronic under-replication приводит к data loss при unclean election.
- Типичные антипаттерны:
- Слишком много разделов: Приводит к overhead (метаданные, ZK load в старых версиях). Решение: consolidate темы, используйте compaction.
- Unclean election (unclean.leader.election.enable=true): Позволяет non-ISR лидеру, рискуя потерей данных. Держите false, жертвуйте availability.
- Отключенный мониторинг: Без alerting на lag или CPU>80% сбои незаметны. Всегда интегрируйте с ELK/Prometheus, с on-call ротацией.
#Java #middle #Kafka #Kafka_securiy
👍3
Сколько стоит Ваша компьютерная система в целом?
Anonymous Poll
0%
Больше 300 тыщ ☺️
20%
От 100 до 300 тыщ 🙂
17%
У меня дорогой ноутбук 🫰
60%
Менее 100 тысяч🤫
3%
Я работаю с телефона, у меня нет компа 😄
👍1
Что выведет код?
#Tasks
class Parent220825 {
private int value = 10;
}
class Child220825 extends Parent220825 {
public void printValue(Parent220825 p) {
System.out.println(p.value);
}
}
public class Task220825 {
public static void main(String[] args) {
new Child220825().printValue(new Parent220825());
}
}
#Tasks
👍2
👍2
Что такое ZonedDateTime в Java? 🤓
Ответ:
ZonedDateTime (Java 8) представляет дату и время с учетом часового пояса.
Пример:
ZonedDateTime zdt = ZonedDateTime.now (ZoneId.of("Europe/Paris"));
System.out.println(zdt); // 2025-08-04T04:57+02:00[Europe/Paris]
Используется для работы с международными приложениями.
#собеседование
Ответ:
Пример:
ZonedDateTime zdt =
System.out.println(zdt); // 2025-08-04T04:57+02:00[Europe/Paris]
Используется для работы с международными приложениями.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3