A
а что потом происходит с недоставленными сообщениями?
в каком случае?
Size: a a a
2020 December 09
IB
в каком случае?
в первом
2020 December 10
A
Date и Time отдельно в corefxlab висят, может когда то доедут
https://github.com/dotnet/corefxlab/blob/master/src/System.Time/System/Date.cs
https://github.com/dotnet/corefxlab/blob/master/src/System.Time/System/Date.cs
VS
Shukurdin Aidarov
Всем привет, я опять со своей болью.
Есть сервис который читает сообщения из кафки и отправляет его клиенту по веб-сокету. Недоставленные сообщения сервис хранит у себя в памяти пока действует ttl. Отправленые же сообщения он удаляет после получения потверждения от клиента (гарантийная доставка).
Дело в том что инстансов этого сервисе очень много и сообщений в кафке много, но одно сообщение предназначено для одного клиента. То есть клиент создает соединение с каким определенным инстансом сервиса, поэтому каждому инстансу приходится читать копию сообщения, чтобы можно было отправить его клиенту. Из-за этого в каждом инстансе становится очень много сообщений, которые доставить невозможно потому что соединение с нужным клиентом только на одном инстансе.
Чтобы сервис не упал из-за нехватки памяти мы сделали ограничение на максимальное количество сообщений в сервисе. Но из-за этого у нас увеличилось время доставки сообщения клиенту (лаг в кафке около 1500 сообщений).
Так вот думаем не хранить сообщения в памяти а хранить в бд - она конечно не реизновая, но в нее гораздо больше влезет. Можем чистить бд раз в день.
Как считаете норм будет или нет?
Есть сервис который читает сообщения из кафки и отправляет его клиенту по веб-сокету. Недоставленные сообщения сервис хранит у себя в памяти пока действует ttl. Отправленые же сообщения он удаляет после получения потверждения от клиента (гарантийная доставка).
Дело в том что инстансов этого сервисе очень много и сообщений в кафке много, но одно сообщение предназначено для одного клиента. То есть клиент создает соединение с каким определенным инстансом сервиса, поэтому каждому инстансу приходится читать копию сообщения, чтобы можно было отправить его клиенту. Из-за этого в каждом инстансе становится очень много сообщений, которые доставить невозможно потому что соединение с нужным клиентом только на одном инстансе.
Чтобы сервис не упал из-за нехватки памяти мы сделали ограничение на максимальное количество сообщений в сервисе. Но из-за этого у нас увеличилось время доставки сообщения клиенту (лаг в кафке около 1500 сообщений).
Так вот думаем не хранить сообщения в памяти а хранить в бд - она конечно не реизновая, но в нее гораздо больше влезет. Можем чистить бд раз в день.
Как считаете норм будет или нет?
берешь пульсар, тип подписки key_shared, все из коробки. Если через функции делать, то даже сервис не нужно отдельно держать, прямо в кластере с пульсаром будет
R
Aloraman
Date и Time отдельно в corefxlab висят, может когда то доедут
https://github.com/dotnet/corefxlab/blob/master/src/System.Time/System/Date.cs
https://github.com/dotnet/corefxlab/blob/master/src/System.Time/System/Date.cs
Полагаю к моему вопросу, посмотрю
AH
Aloraman
Date и Time отдельно в corefxlab висят, может когда то доедут
https://github.com/dotnet/corefxlab/blob/master/src/System.Time/System/Date.cs
https://github.com/dotnet/corefxlab/blob/master/src/System.Time/System/Date.cs
2 years ago
AH
а точнее 3
AH
не вижу смысла переизобретать колесо. нодатайм и вперде
A
2 years ago
В два раза моложе пропозала по Discriminated Union
у Noda порог вхождения высокий, и API мощное, тут же скорее простые структуры с данными, для совместимости с sql и xsd
у Noda порог вхождения высокий, и API мощное, тут же скорее простые структуры с данными, для совместимости с sql и xsd
V
Aloraman
В два раза моложе пропозала по Discriminated Union
у Noda порог вхождения высокий, и API мощное, тут же скорее простые структуры с данными, для совместимости с sql и xsd
у Noda порог вхождения высокий, и API мощное, тут же скорее простые структуры с данными, для совместимости с sql и xsd
Кстати сегодня думал, как можно было бы реализовать DU, когда с собакеном гулял.
Пришёл к выводу, что невозможно сложно сделать так, чтобы и на старом рантайме работало, и чтобы по типчикам 100% безопасно было, и чтобы без правок жита.
Хочется просто чтобы DU могли заменить enum в тех случаях, когда надо просто свич по значению (не флаги и не конвертацию в числа и обратно). То есть надо, чтобы DU были value-типами
Не помню, какой там синтаксис в пропозале, но мне показалось, что лучше ввести новый кейворд, чем пытаться расширять enum или придумывать какой-нибудь enum class или enum struct
Пришёл к выводу, что невозможно сложно сделать так, чтобы и на старом рантайме работало, и чтобы по типчикам 100% безопасно было, и чтобы без правок жита.
Хочется просто чтобы DU могли заменить enum в тех случаях, когда надо просто свич по значению (не флаги и не конвертацию в числа и обратно). То есть надо, чтобы DU были value-типами
Не помню, какой там синтаксис в пропозале, но мне показалось, что лучше ввести новый кейворд, чем пытаться расширять enum или придумывать какой-нибудь enum class или enum struct
A
К Maoni никто не обращался по этому поводу, так что вряд ли компактную реализацию завезут, а так можно еще пару лет подождать
AH
Aloraman
В два раза моложе пропозала по Discriminated Union
у Noda порог вхождения высокий, и API мощное, тут же скорее простые структуры с данными, для совместимости с sql и xsd
у Noda порог вхождения высокий, и API мощное, тут же скорее простые структуры с данными, для совместимости с sql и xsd
но простые структуры на простые структуры нет смысла менять. шило на мыло
E
ожидание: байтоебля перфоманса
реальность: ебола на JNI https://github.com/dotnet/runtime/pull/45870
реальность: ебола на JNI https://github.com/dotnet/runtime/pull/45870
NT
но зачем, оно ж поди тормозит теперь
NT
это как с той еболой
NT
когда HttpClient был поверх curl