This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-09-07
Channels
- # beginners (7)
- # boot (25)
- # clojure (66)
- # clojure-australia (10)
- # clojure-berlin (1)
- # clojure-czech (1)
- # clojure-denmark (2)
- # clojure-france (27)
- # clojure-italy (6)
- # clojure-japan (1)
- # clojure-nl (5)
- # clojure-norway (1)
- # clojure-russia (25)
- # clojurescript (55)
- # cursive (27)
- # datascript (2)
- # datomic (5)
- # editors (4)
- # emacs (2)
- # hoplon (183)
- # ldnclj (45)
- # off-topic (4)
- # om (2)
- # rdf (5)
- # re-frame (11)
- # reagent (5)
- # ring (3)
@nicola: по чатику интересуют такие вопросы: - как организован обмен с клиентами - websockets, ajax+sse или еще какие варианты? - как сделан диспатч - очереди внутренние, внешние, через базу?
@maxp 1) я реализовал первый вариант rest over websockets, он позволяет переиспользовать обработчики и для обычного rest (можно и sse прикрутить) - ничем не жертвуем ;)
С очередями ещё разбираюсь - хочу попробовать kafkу. Под диспатчем ты что подразумевеашь? Каким клиентам какие сообщения роутить? Персистенс в базу думаю будет обычным потребителем или группой. Думаю где сессии хранить - справиться ли postgres?
Я делал когда-то прототип чат-системы на Java - там были требования в 1000 коннектов максимум (туда смс должны были заворачиваться из разных источников).
Там было тупо по одной нити на коннект, джавовские очереди и семафорчики. Центральная нить, которая только занималась тем, что перекладывала сообщеньица и дёргала семафорчики.
Узлов с коннекторами можно было делать больше одного. Условиями допускалась потеря сообщений при внезапном рестарте диспетчера.
Да, кстати, вспомил - я тут как-то спрашивал насчет clojure аналога джавовского wait(timeout) - это как раз там работало успешно.
Там совсем другие требования - меньше коннектов, но 1-2 сообщения в секунду от каждого (1 Hz от GPS'а и возможно доп.данные).
По сессиям в чате варанты могут быть разные - на стороне сервера вероятно кто-то все-равно так или иначе "помнит" про клиентский коннект и нет нужды на каждый чих лазить в базу за сессиями. То есть нагрузки на базу в этом месте нет.
Далеко не всегда есть резон тащить в проект "взрослую" очередь. К примеру, простенькая реализация "надежной" очереди на питоне поверх постгреса занимает пару экранов текста.
Подобная реализация давала требуемый минимум в 100 рпс на очень средней машинке нескольколетней давности, а это соизмеримо с чатилкой на 1000 коннектов.
На постгресе есть реализации высокопроизводительных очередей (от Скайпа вроде) в виде экстеншенов.
народ, а приходится кому юзать pallet? https://github.com/pallet/pallet
@nicola: @maxp Zach Tellman на одной из конференций (не помню, какой) рассказывал про их имплементацию очереди – https://github.com/Factual/durable-queue Она, кажется, намного легче Кафки или Кролика, но я не пробовал. Плюс решения типа Kafka или RabbitMQ хорошо работают в именно кластере – для чего-то небольшого их использовать нет смысла. А про очередь на постгресе интересно – недавно холиварили с коллегой на эту тему – он как раз предлагал заменить кролика на самописное решение на постгресе после того, как на машине с кроликом в очередной раз сломалась сеть (Azure…), и у нас встала работа на полчаса.
очень поучительно. Это то, о чем вы хрен заранее догадаетесь, даже если вы знаете про mvcc, постгрес, таплы, txn_id и всякое такое
@konukhov: У нас в ненагруженном проекте очередь на pg работала хорошо, но сейчас именно нагрузка интересует - вроде кафка способна большую держать.
если кто-то вдруг сомневался есть ли лимит на переповтор транзакций в stm, то он есть, равен 10000 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L25