@gogolang - страница 805 - Telegram web archive

🏳️ Phil

А причем тут server_name?

🏳️ Phil

Тут в пору listen показывать

Anonymous

@schors server { listen 80; server_name ~^(www\.)?(?<subdomain>.+)\.example\.com$; return 301 https://$subdomain.example.com$request_uri; }

🏳️ Phil

Тут надо чтото комментировать или и так все понятно? SSL просто не настроен и отсуьствует в конфиге

Anonymous

так он в следующем блоке server

Anonymous

наверное, если бы он не был настроет, то https://subdomain.example.com тоже не работало

🏳️ Phil

Ну оно только в тот блок и идет. В этот даже не пытается.

Anonymous

тоесть в него тупа скопироватьвсе тоже самое как и в следующем блоке для ssl?

🏳️ Phil

Я не знаю, что в следуюзем блоке) Но предположительно - да. А как иначе то?

Anonymous

а можно как нибудь этот ssl вкакую то переменную записа. а потом во всех блоках добавить?

🏳️ Phil

Зачем? Покажи следующий блок. Можно без location

Anonymous

server { listen 443 ssl; server_name *.example.com; root /public; ssl_certificate /ssl/example.crt; ssl_certificate_key /ssl/example.key; }

Anonymous

=)

🏳️ Phil

ssl_* можно вынести просто выше в http секцию. А listen дублировать

Anonymous

а у меня вооще нету http секции, это нормально?

🏳️ Phil

Да

Zloy-Dobry

А причем тут голанг?

Zloy-Dobry

И нахуя делать одно и тоже в двух чятах? Профильном и ничего общего не имеющем?

Alexander

он еще и в jvm написал

Alexander

некоторые люди очень тупые, смиритесь с этим

Zloy-Dobry

Мдэ.

Oleg

Высокомерие

Aleksandr

https://tools.ietf.org/html/rfc8259

Aleksandr

новый json rfc. Из некосметических отличий одно: json должен быть в utf-8 (раньше в utf-8,-16,-32)

Anonymous

новый json rfc. Из некосметических отличий одно: json должен быть в utf-8 (раньше в utf-8,-16,-32)

не помню откуда, но мне устойчиво помнится что так изначально было

Aleksandr

не помню откуда, но мне устойчиво помнится что так изначально было

возможно в другой какой-то спеке, например w3c. в 7159 нет

Alexey

Господа, кто-нибудь юзал nats? Я делаю простую очередь, в случае отсутсвия subscriber`ов данные просто трутся, это можно как-то настроить? Т.е я поднимаю сначала publisher (он шлет несколько сообщений), затем subscriber, а данные он не получает.

Dmitry

Господа, кто-нибудь юзал nats? Я делаю простую очередь, в случае отсутсвия subscriber`ов данные просто трутся, это можно как-то настроить? Т.е я поднимаю сначала publisher (он шлет несколько сообщений), затем subscriber, а данные он не получает.

Если хочется чтобы не терлось, тогда заюзайте nats streaming, а не nats

Anonymous

Господа, кто-нибудь юзал nats? Я делаю простую очередь, в случае отсутсвия subscriber`ов данные просто трутся, это можно как-то настроить? Т.е я поднимаю сначала publisher (он шлет несколько сообщений), затем subscriber, а данные он не получает.

вопрос в духе ру-коммунити - но зачем именно натс? если это внутри 1 процесса то каналы, если между - то редис, вполне тянет нагрузку

Aleksandr

вопрос в духе ру-коммунити - но зачем именно натс? если это внутри 1 процесса то каналы, если между - то редис, вполне тянет нагрузку

поменяй в вопросе местами редис и натс и он так же звучит без объяснений почему ты выбрал такой порядок слов

Slach

+1 ;) Redis - хорошая штука... но все таки она изначально не для очередей делалась

Anonymous

поменяй в вопросе местами редис и натс и он так же звучит без объяснений почему ты выбрал такой порядок слов

не совсем, с редисом пути все пройдены, натс менее популярен, требует ресерча и манов меньше

Ruslans

я конечно не эксперт, но почему бы не юзать rmq?

Ruslans

(он же создан для этого елы палы)

Anonymous

я конечно не эксперт, но почему бы не юзать rmq?

не для хайлоад

Ruslans

а редис хайлоад

Ruslans

ахаха

Anonymous

хоть и да, это самый популярный инструмент очередей

Ruslans

вообще конечно у меня куча вопросов с чего это он не для хайлоад?

Anonymous

а редис хайлоад

ну вполне. непредсказуемых ростов таймингов при грамотном использовании нет. очередь хранится в нескольких ключах, на разных инстансах. читатели читают все очереди

Sergey

хоть и да, это самый популярный инструмент очередей

редис - гавно

Anonymous

вообще конечно у меня куча вопросов с чего это он не для хайлоад?

в durable режиме большие тайминги. в memory режиме он аналогичен редису

Anonymous

редис - гавно

такой ответ - говно

Slach

редис - гавно

безосновательное утверждение, скорее всего вы с ним не работали

Anonymous

+1 ;) Redis - хорошая штука... но все таки она изначально не для очередей делалась

на офф сайте редиса описаны паттерны использования его для очередей

Emil

+1 ;) Redis - хорошая штука... но все таки она изначально не для очередей делалась

а что редису мешает быть очередью?

Slach

на офф сайте редиса описаны паттерны использования его для очередей

попробую обосновать свою точку зрения очереди в redis появились вообще не сразу, приоретезированные очереди через ZSET и ZPOP это немного костыль, PUBSUB это частный случай очередей и если придет сразу МНОГО publishers и все начнут срать по многу, то редис немножечко офигеет и консюмеры могут просто не получить своего... потому что redis однопоточный

Aleksandr

не совсем, с редисом пути все пройдены, натс менее популярен, требует ресерча и манов меньше

я про другое. ты не объяснил почему так, а не иначе. тобой может пройдены - вопрошающим нет. поэтому для него это просто перестановка x и y

Anonymous

попробую обосновать свою точку зрения очереди в redis появились вообще не сразу, приоретезированные очереди через ZSET и ZPOP это немного костыль, PUBSUB это частный случай очередей и если придет сразу МНОГО publishers и все начнут срать по многу, то редис немножечко офигеет и консюмеры могут просто не получить своего... потому что redis однопоточный

по поводу “много" говорил: масштабируем очередь изначально. много ключей. паблишеры паблишат в рандомные очереди, читатели читают например раундробином эти очереди могут быть даже на разных хостах. как чувствуем что редис упирается - разносим.

Anonymous

поскольку эта очередь “самодельная”, реализовать в ней подобные паттерны использования несложно. в отличие от того же реббита. если есть носители решения как масштабировать реббит, когда ему становится плохо - поделитесь а плохо ему становится только уже от большого кол-ва сообщений в очереди

Alexander

а большое - это сколько ? сотни тысяч, миллионы ?

Alexey

это как будто разговор про кафку щас будет ))

Anonymous

а большое - это сколько ? сотни тысяч, миллионы ?

у меня были проблемы > 100k просто от хранения такого объема но понятно что это зависит от железа, какое оно, я не скажу. но скажу что заменил на редис на том же железе, который живет долго и счастливо

Alexander

а недавно видел аналог кафки на го. sandglasess что ли

Alexander

совсем свежий, только-только кто-то шибанул

Alexander

https://github.com/celrenheit/sandglass

Alexander

по описаниям и фичам - вроде огонь. но руками не трогал

Alexey

ну надо смотреть реальные внедрения

Alexey

по кафке просто мы знаем кто юзает

Alexey

а вот sandglass..кто такие..где внедряли

Alexander

да я думаю пока никто

Alexey

ну скорее кто то для себя

Alexey

но звезд много у них

Roman

sandglass - сырой еще

Roman

EXPERIMENTAL: This is a prototype of a side project. This should not be used in production in its current form as things may change quickly without notice.

Alexander

ясен перец. все что младше 10 лет продакшена - сырое

Alexey

10 лет наверное совсем )

Alexey

я обычно 3 года жду )

Alexey

потом уже технология уже перестает быть хипстерской

Alexey

и можно щупать

Anonymous

ясен перец. все что младше 10 лет продакшена - сырое