weldp
Новичок
Может ли очередь быть спасательным кругом?
Привет Всем.
До очереди:
POST-запрос передаем некому скрипту, который возвращает данные, допустим из ДБ. Возникает вопрос - как защитить БД, как справится с нагрузкой ( 1000 пользователей решили что-то изменить одновременно).
После очереди:
Делаем POST-запрос который обрабатываем в скрипте, тот данные кладет в нужную очередь, дальше их достаем из очереди, обрабатываем. Вроде бы некий оверхед? Но с другой стороны у нас есть механизм управления нагрузкой - скорость обработки очереди
MemcacheQ позволяет обращаться по сети, а это значит, что очередь легко разгребать на множестве машин
На ум приходит таким образом проводить регистрацию/добавление данных/удаление данных отсылка уведомлений и т.п. - то, что может подождать.
По идеи можно защитить свою БД от атак - нападающий не получает назад никаких worning'ов, предупреждений или же изменение поведения ПО, он видит - данные добавлены(после стандартных методов обработки/анализа).И только в недрах обработчика данные заливаются в БД. Кстате БД может быть и не реляционой))
Я не знаю может ли быть выигрыш от того, что один/несколько обработчиков разгребают постоянно очередь перед тем, что каждый раз в скриптах Мы коннектимся к БД, вносим изменения?...
Хотелось бы услышать мнения других и примеры где используют/не используют очереди(memcacheQ и подобные).
Привет Всем.
До очереди:
POST-запрос передаем некому скрипту, который возвращает данные, допустим из ДБ. Возникает вопрос - как защитить БД, как справится с нагрузкой ( 1000 пользователей решили что-то изменить одновременно).
После очереди:
Делаем POST-запрос который обрабатываем в скрипте, тот данные кладет в нужную очередь, дальше их достаем из очереди, обрабатываем. Вроде бы некий оверхед? Но с другой стороны у нас есть механизм управления нагрузкой - скорость обработки очереди
MemcacheQ позволяет обращаться по сети, а это значит, что очередь легко разгребать на множестве машин На ум приходит таким образом проводить регистрацию/добавление данных/удаление данных отсылка уведомлений и т.п. - то, что может подождать.
По идеи можно защитить свою БД от атак - нападающий не получает назад никаких worning'ов, предупреждений или же изменение поведения ПО, он видит - данные добавлены(после стандартных методов обработки/анализа).И только в недрах обработчика данные заливаются в БД. Кстате БД может быть и не реляционой
))Я не знаю может ли быть выигрыш от того, что один/несколько обработчиков разгребают постоянно очередь перед тем, что каждый раз в скриптах Мы коннектимся к БД, вносим изменения?...
Хотелось бы услышать мнения других и примеры где используют/не используют очереди(memcacheQ и подобные).
