Ну да, от юз кейса зависит. У нас не тысячи. Сотня, пожалуй, это максимум, сколько одновременно может быть. В одну небольшую запись на несколько килобайт отлично влезает. Хранится в SQL, закодировано Storable::freeze, доступ всегда по primary key, ну и кешируется в memcached. 99.9% обращений - на чтение.
On Wed, Dec 23, 2015 at 4:41 PM Oleg Alistratov <[email protected]> wrote: > > > 23.12.2015, 17:29, "Alexander Lourier" <[email protected]>: > >> Как обычно, детали роляют. Прямо сейчас вот осбуждаем, где хранить > признак, что юзер уже был празднично обрадован: в куке, в сессии или в > базе, учитывая еще, что юзер может быть опоздравлен как на одном только > клиенте (во время Ч в вебсокет будет выдана структурка), так и с > задействованием шаблонизатора на бэкенде (время Ч уже пропустил и в сокет > ему ничего не надуло). Ну и юзер не должен слишком долго радоваться, не > должен быть обрадован дважды, и т.д. и т.п. > > > > У меня за эту механику отвечает сущность "модификаторы игрока". У игрока > может быть любое количество модификаторов. У модификатора есть код, > "значение" (для разных целей) и срок годности. Любой модуль может в любой > момент проверить $character->modifier('newyear_gift_presented'). Если > модификатора нет (или он стух), то вернётся undef. В момент выдачи подарка > под ёлкой, ставится модификатор на полгода - он стухнет летом, когда он уже > никому не нужен, и к следующему новому году его снова ни у кого нет. > Проверка стухания делается в момент вызова modifier (т.е. физически запись > есть, но она не возвращается). При очередном обновлении модификатора (когда > запись в БД идёт), стухшие модификаторы вычистятся из записи тоже. > > Ага, штука у нас такая же по сути. Но говорю ж, дьявол в деталях :) > > Механизм этот на самом деле не для новых годов делается. Событий, которые > придут юзеру, может быть сотни и тысячи, но большая часть из них живет не > более получаса. Вот и не хочется базу раздувать, а обойтись куками и > редисами. Тако вот. > > > >> 23.12.2015, 16:48, "Ivan Serezhkin" <[email protected]>: > >>> ну что господа, хвастающиеся своим знанием по егэ, > >>> > >>> А расскажите ка как у вас в проектах реализован функционал нового года, > >>> который где-то в начале нового года должен включится, отработать новый > >>> год, и к концу каникул выключится. > >>> > >>> или у вас ответственный деплой 31 вечером? Не, тогда лучше молчите. > >>> > >>> В свою очередь, через некоторое время обещаю обещать рассказ про > миксины. > >>> > >>> -- > >>> WBR, Vany > >>> > >>> -- > >>> Moscow.pm mailing list > >>> [email protected] | http://moscow.pm.org > >> > >> -- > >> Oleg Alistratov > >> -- > >> Moscow.pm mailing list > >> [email protected] | http://moscow.pm.org > > ,-- > > Moscow.pm mailing list > > [email protected] | http://moscow.pm.org > > > -- > Oleg Alistratov > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
