+1 за timestamp в ключевом поле, c плавающей точной или без, в зависимости от плостности добавления полей. На мой взгляд это делает базу несколько компактнее (избавляет от created_at или аналогичного) и дает возможность конвертировать в любой формат времени когда приспичит, да и для аналитики на мой взгляд лучше и проще.
Отличный выпуск. Спасибо
Для организации очереди событий вполне себе можно использовать какой нибудь MQ, не понимаю какие с ним возникают проблемы. Также, очередь можно построить с помощью какой нибудь БД.
речь шла о том, что кластеризованная RabbitMQ не линеаризуется...а собственные поделки не выдерживают нагрузки, если не понимаешь какие проблемы возникают, опиши архитектуру о которой ты говоришь и я тебе спасибо тебе скажу если это работать будет
Я говорю о следующей схеме:
На отдельном инстансе работает один MQ, на нем организуется упорядоченная очередь. Перед MQ стоит кластер апликух, которые только регистрируют поступающие запросы. На MQ эти запросы выстраиваются в очередь. За MQ стоит кластер апликух, обрабатывающих запросы из очереди и отправляющих результат клиенту.
ну во первых MQ явно не один инстанс, а клстер, иначе это горлышко("если ты понимаешь о чем я"); во вторых упорядоченная очередь это значит линеаризовать ее, и соответственно я не услышал как это сделать, да еще и учитывая что MQ - кластер?
Не может быть, что все клиенты одновременно принимают участие в одном событии. Можно например иметь несколько отдельных инстансов MQ и под каждое событие создавать свою fifo очередь сообщений, все клиенты, принимающие участие в этом событии, будут обслуживаться конкретной очередью, на конкретном инстансе.
Дорогой и многоуважаемый pod-слушатель, я настоятельно рекомендую поднять самостоятельно кластер любой MQ, предварительно прочитав спецификацию по AMQP и сделать правильные выводы. Тогда наши диалоги станут так сказать более осмысленными и полезными. С уважением ваш аноним, ой я же авторизовался...ну да ладно
Fedotoff Vyacheslav (vfedotoff)