parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Ответ

AK666 20.11.2013 14:27 / 20.11.2013 14:31

Очень сомневаюсь, что у вашего браузера (а мы ведь про это говорим) стоит балансировщик и имеет несколько исходящих каналов :)
У меня на работе три оптонитки к разным ИСП и дома две оптонитки. Поэтому для меня - это действительно проблема :)
И так же посмотрю на ваше лицо, когда кто-либо перехватит вашу куку от интернет-банка без защиты по ip :)
ну вот пока (Украина) ни один банк с которым я работаю в куки ИП не пишут (или удачно сессии устанавливаются? через одну нитку)
перехватит вашу куку
О! а вот чем тогда кука лучше HTPP_AUTH ? перехватить-то можно и то и то :)
а в случае с https + HTTP_AUTH - то, как по мне, гемморроя с хранением кук на стороне сервера сильно меньше (ибо НЕТУ этого хранения, которое ещё и распределенным должно быть)
А с хештаблицами вообще рай, вы же туда ничего не пишите, только на чтение, так что никаких длительных блокировок.
а если бэкендов несколько? на САН надо таблицы писать? а если дописывать ещё и с разных parser-сессий - то блокировки опять возникнуть же могут.

несколько фронтов, общаются с несколькими бэкендами, соответственно для уменьшения нагрузки на СКЛ бэкенды один(первый) раз верифицируют пользователя из БД, а во всех последующих обращениях, по идее могу проверять и из общего мемкешеда (вот тут очень хочется пул:)).
Посмотрите в сторону микрокеша у nginx.
как кэш нжинкса поможет с авторизационной кукой обрабатывемой парсером? или может? тут подскажите, плиз