Fork me on GitHub
#clojure-russia
<
2015-09-07
>
maxp01:09:58

@nicola: по чатику интересуют такие вопросы: - как организован обмен с клиентами - websockets, ajax+sse или еще какие варианты? - как сделан диспатч - очереди внутренние, внешние, через базу?

maxp01:09:31

@nicola: наиболее интересна мотивация тех или иных решений.

nicola05:09:01

@maxp 1) я реализовал первый вариант rest over websockets, он позволяет переиспользовать обработчики и для обычного rest (можно и sse прикрутить) - ничем не жертвуем ;)

nicola05:09:08

С очередями ещё разбираюсь - хочу попробовать kafkу. Под диспатчем ты что подразумевеашь? Каким клиентам какие сообщения роутить? Персистенс в базу думаю будет обычным потребителем или группой. Думаю где сессии хранить - справиться ли postgres?

maxp07:09:19

Тут стоит сразу требования оговорить, конечно. Сильно они разные могут быть.

maxp07:09:50

Я делал когда-то прототип чат-системы на Java - там были требования в 1000 коннектов максимум (туда смс должны были заворачиваться из разных источников).

maxp07:09:56

Там было тупо по одной нити на коннект, джавовские очереди и семафорчики. Центральная нить, которая только занималась тем, что перекладывала сообщеньица и дёргала семафорчики.

maxp07:09:04

Отдельным "клиентом" была база данных.

maxp07:09:54

Узлов с коннекторами можно было делать больше одного. Условиями допускалась потеря сообщений при внезапном рестарте диспетчера.

maxp07:09:19

Да, кстати, вспомил - я тут как-то спрашивал насчет clojure аналога джавовского wait(timeout) - это как раз там работало успешно.

maxp07:09:12

Делал еще другой вариант - там машинки ездили по карте в вебклиенте.

maxp07:09:10

Там совсем другие требования - меньше коннектов, но 1-2 сообщения в секунду от каждого (1 Hz от GPS'а и возможно доп.данные).

maxp07:09:16

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

maxp07:09:07

С очередями тоже довольно интересно.

maxp07:09:53

Далеко не всегда есть резон тащить в проект "взрослую" очередь. К примеру, простенькая реализация "надежной" очереди на питоне поверх постгреса занимает пару экранов текста.

maxp07:09:02

"надежная" здесь означает, что клиент получает "ок" только после постгрессова коммита.

maxp07:09:34

Подобная реализация давала требуемый минимум в 100 рпс на очень средней машинке нескольколетней давности, а это соизмеримо с чатилкой на 1000 коннектов.

maxp07:09:43

На постгресе есть реализации высокопроизводительных очередей (от Скайпа вроде) в виде экстеншенов.

a.espolov09:09:36

народ, а приходится кому юзать pallet? https://github.com/pallet/pallet

konukhov15:09:09

@nicola: @maxp Zach Tellman на одной из конференций (не помню, какой) рассказывал про их имплементацию очереди – https://github.com/Factual/durable-queue Она, кажется, намного легче Кафки или Кролика, но я не пробовал. Плюс решения типа Kafka или RabbitMQ хорошо работают в именно кластере – для чего-то небольшого их использовать нет смысла. А про очередь на постгресе интересно – недавно холиварили с коллегой на эту тему – он как раз предлагал заменить кролика на самописное решение на постгресе после того, как на машине с кроликом в очередной раз сломалась сеть (Azure…), и у нас встала работа на полчаса.

gordon15:09:21

ща притащу былину про очереди на постгресе

gordon16:09:38

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

nicola16:09:21

@konukhov: У нас в ненагруженном проекте очередь на pg работала хорошо, но сейчас именно нагрузка интересует - вроде кафка способна большую держать.

gordon19:09:25

если кто-то вдруг сомневался есть ли лимит на переповтор транзакций в stm, то он есть, равен 10000 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LockingTransaction.java#L25