Так компании хотят back-porting улучшений и security patches.
Если идти в ногу со временем (всегда быть на последней версии Java), то всё должно устраивать.
Наблюдаю обратную тенденцию с переносом vendor-специфичных на светлую сторону, например, в Java 9 класс sun.misc.Unsafe переехал в другой пакет: jdk.internal.misc.Unsafe.
.NET Framework (множество версий, в том числе несовместимых)
Mono
.NET Core 1.x
.NET Core 2.x
.NET Standard 1.0
.NET Standard 2.0
Мир C# ещё очень далёк от стандарта, в котором перестали бы ломать API. Через годик можно ещё попробовать присмотреться. Или мой анализатор сарказма сломался и это была шутка?)
Мне всегда казалось, что митапы нужны в первую очередь для нетворкинга. Для всего остального есть конференции (ок, в Екатеринбурге с этим не так здорово).
Есть самописная очередь Echelon, которая работает поверх самописной же базы Kanso (для которой идейным вдохновителем послужила Google FS). Когда-нибудь (я надеюсь), эти решения станут частью OpenSource-мира.
Vostok — это OpenSource, поэтому логично использовать в основе OpenSource-решение (например, Apache Kafka). Кроме того, Apache Kafka выдаёт огромные скорости благодаря zero-copy, когда упираемся либо в клиента, либо в сеть, либо в диск. В 2019 нам завезут серваки с 10 гигабитной сетью — посмотрим, что будет.
Я ничего не скажу за производительность и масштабируемость Echelon (потому что не знаю). Можно попробовать призвать Diafilm. :)
Соль больше не предоставляет площадку для таких мероприятий.
Из менее фатального:
У Соли были довольно существенные ограничения по времени использования площадки.
Конференц-зал в Контуре существенно больше и комфортнее.
В коференц-зале есть всё необходимое оборудование (звук, скринкаст, видеосъёмка).
Аренда стоит денег (существенных в масштабах митапа).
Изменение времени стало следствием смены площадки. В выходной день парковка способна принять несколько сотен машин, а добраться до офиса значительно проще, чем вечером буднего дня.
1. Продюсеры пишут сообщение в конкретный топик и конкретную секцию
Producer может указать и конкретный топик, и конкретную партицию в нём. // Ответ на вопрос: "да"
2. Консюмеры опрашивают брокера на наличие новых сообщений в топике (без привязки к секции)
Consumer может работать как в режиме publish/subscribe, т.е. сколько угодно Consumer может читать одни и те же данные, так и в режиме message queue, когда одно сообщение читается ровно одним Consumer. В последнем случае все Consumer объединяются в Consumer Group для чтения из одного топика, и одновременно из каждой партиции читает ровно один Consumer (балансировщик контролирует, если один из Consumer отпадёт, то свободный Consumer будет читать сообщения). // Ответ на вопрос: "да"
3. Брокер отдает (одновременно) неограниченное количество сообщений из топика но не больше одного сообщения из конкретной секции.
Не понял смысла выделенного фрагмента. Это как-то коррелирует с моим комментарием по второму пункту относительно работы Consumer Group?
Чему равно N (хотя бы порядок)? Какие есть требования помимо «порядок сообщений от каждого продюсера критично важен»?
Кафка предоставляет мощные инструменты для работы с данными (например, Kafka Streams или KSQL). При этом, в Кафка есть гарантия на порядок сообщений внутри одной партиции. Кроме того, в Кафке поддерживаются все три варианта семантик: at-most-once, at-least-once и exactly-once.
В разделе «Turning the Database Inside-Out» / «База данных изнутри» есть ссылка на одноимённую статью-доклад от Martin Kleppmann (тоже из Confluent, как и Michael G. Noll) — Мартин довольно интересно рассказывает про устройство баз данных, и там тоже есть немного про стримы в БД.
Наверное, я некорректно выразился: нет гарантии совместимости Java 8 SE API и Java X SE API, т.е. описанное в javadoc поведение может поменяться в будущем. Или есть?
Так я не спорю, что внутри 4.x таких проблем нет. Я защитил тезис с проблемами совместимости у некоторых версий .NET Framework.
Так компании хотят back-porting улучшений и security patches.
Если идти в ногу со временем (всегда быть на последней версии Java), то всё должно устраивать.
Это в теории всё замечательно, но на практике разработчики сталкиваются с кучей проблем.
sun.misc.Unsafeпереехал в другой пакет:jdk.internal.misc.Unsafe.Мир C# ещё очень далёк от стандарта, в котором перестали бы ломать API. Через годик можно ещё попробовать присмотреться. Или мой анализатор сарказма сломался и это была шутка?)
Это то, что сходу удалось вспомнить. Наверняка, есть и другие не менее популярные.
С появлением LTS-версии OpenJDK под CentOS — вариант с Corretto становится для нас весьма интересным.
Vostok — это OpenSource, поэтому логично использовать в основе OpenSource-решение (например, Apache Kafka). Кроме того, Apache Kafka выдаёт огромные скорости благодаря zero-copy, когда упираемся либо в клиента, либо в сеть, либо в диск. В 2019 нам завезут серваки с 10 гигабитной сетью — посмотрим, что будет.
Я ничего не скажу за производительность и масштабируемость Echelon (потому что не знаю). Можно попробовать призвать Diafilm. :)
Из менее фатального:
Изменение времени стало следствием смены площадки. В выходной день парковка способна принять несколько сотен машин, а добраться до офиса значительно проще, чем вечером буднего дня.
// Ответ на вопрос: "да"Consumer может работать как в режиме publish/subscribe, т.е. сколько угодно Consumer может читать одни и те же данные, так и в режиме message queue, когда одно сообщение читается ровно одним Consumer. В последнем случае все Consumer объединяются в Consumer Group для чтения из одного топика, и одновременно из каждой партиции читает ровно один Consumer (балансировщик контролирует, если один из Consumer отпадёт, то свободный Consumer будет читать сообщения).
// Ответ на вопрос: "да"Не понял смысла выделенного фрагмента. Это как-то коррелирует с моим комментарием по второму пункту относительно работы Consumer Group?
В остальном всё верно. :)
// gAmUssA, спасибо за уточнение.
Кафка предоставляет мощные инструменты для работы с данными (например, Kafka Streams или KSQL). При этом, в Кафка есть гарантия на порядок сообщений внутри одной партиции. Кроме того, в Кафке поддерживаются все три варианта семантик: at-most-once, at-least-once и exactly-once.
я бы предложил такой вариант с обнулением бита, отвечающего за знак:
Для отрицательных значений
hashCodeрезультат, конечно, будет отличаться:тем не менее, получим такое же распределение на
[0; partitions).