Comments 14
Интересно наблюдать, как история движется по спирали. От ESB к изолированным независимым микросервисам и обратно к ESB.
Возможно, в данном случае переход на кафку упростил жизнь, т.к. система по своей сути однонаправленная и хорошо моделируется сообщениями, а не изолированными доменами мастер-данных.
данные отдаются в JSON
А почему не AVRO? И компрессию используете ли какую-нибудь?
забавно. Мне год назад активно слили карму за комментарий, что ПР претерпела серьезнейшие изменения.
Людям не объяснить, они будут продолжать думать так, как хотят
У вас удивительно бесполезный комментарий. Перефразируя:
Мне год назад слили карму за <ищите сами за что>
Люди тупые
А сколько максимально могут выдержать ваши 12 серверов сообщений в секунду?
3 млн это какая загруженность ваших серверов? (процессоры / оперативка)
И у вас данные на диски сохраняются? Диски SSD M.2? Какая скорость чтения\записи у них и влияет ли это на производительность вашей шины в такой реализации? Или все в оперативке хранится, и от дисков ничего не зависит?
Интересно, какая latency на доставку сообщений под нагрузкой?
(сарказм: надеюсь не как у посылок и писем?)
а почему не написать с нуля на го? Быстрее взять готовый вариант и разобраться в нём? Этот момент вообще не рассмотрен в статье, нет сравнения между сделать своё и взять готовое.
Дополнительный слой для работы с большими данными. Тесты показали, что сообщения больше мегабайта критически роняют перформанс Kafka
а почему падает производительность?
Мы работаем даже не с дисками. ОС кэширует данные, к которым мы чаще всего обращаемся, и именно за счёт этого позволяет с максимальной скоростью читать и обрабатывать их на кластере
опять же) а почему не сделать свой кэш или ОС хорошо кэширует?
Мы пробовали запускаться на виртуальных серверах. Скажу честно, получилось не очень. И дело даже не в CPU, а вот в чём:
Появляется latency на память.
По поводу производительности, скорее всего она упирается в количество контроллеров оперативной памяти процессора. Если в проце 2 контроллера, то он может работать одновременно с двумя планками оперативы (в пользовательских компах обычно так, в серверных больше контроллеров), и пусть там хоть 64 ядра, но читать/писать память одновременно можно только в 2 потока, и данные должны быть в физически разных планках
Xms24G -Xmx24G -XX:MetaspaceSize=96m -XX:+UseG1GC
Вот тут вопрос возник: с какой целью такой объем по heap?
И сколько при этом у вас выделено под page cache?
На практике да и по рекомендации confluent:
"Kafka uses heap space very carefully and does not require setting heap sizes more than 6 GB"
В целом выглядит так как будто вы не поняли как работает Kafka.
Возможно я не прав, поправьте. :o)
>Заметьте, мы используем G1 GC, а не стандартный garbage collector.
Так G1 и есть стандартный. Уже довольно давно. Или Kafka только на Java 8 умеет?
Как мы построили корпоративную шину данных на Kafka, которая обрабатывает до 3 млн сообщений в секунду