2017-01-10 6 views
1

Это действительно хлопотно для меня. У меня есть бот телеграммы, который работает в django и python 2.7. Во время разработки я использовал django sslserver, и все работало нормально. Сегодня я развернул его с использованием gunicorn в nginx, и код работает очень иначе, чем на моем localhost. Я пробовал все, что мог, с тех пор, как я начал получать пользователей, но все безрезультатно. Мне кажется, что большинство объектов python теряют свое состояние после каждого запроса, и именно это может вызвать проблемы. Библиотека, которую я использую, имеет класс, который обрабатывает разговор с пользователем телеграммы, и состояние разговора сохраняется в экземпляре класса. Иногда, когда появляются новые запросы, эти значения уже теряются. Пожалуйста, кто-нибудь столкнулся с этим? и есть ли способ быстро решить проблему? Я нахожусь в критической ситуации и нуждаюсь в быстром решении.Объекты Python теряют состояние после каждого запроса в nginx

+4

gunicorn использует модель рабочего тела предка. Prefork. Это означает, что у вас есть куча разрозненных ** независимых процессов **. Независимые, то есть они имеют собственное состояние и не обмениваются друг с другом памятью. Если вы не создали свою систему для связи с центральным хранилищем (redis, & c), вам нужно будет вернуться к чертежной доске. –

+0

@ Charles Duffy, у меня есть база данных, но библиотека, которую я использую, кажется, просто экономит состояние. Более того, я не знал об этом стрельбе – Ken

+1

На данный момент вы можете превратить рабочий счет в 1. Это повредит производительности, но лучше, чем иметь сервис, который не работает вообще. –

ответ

2

Gunicorn имеет модель рабочего класса - это означает, что он запускает несколько независимых подпроцессов, каждый из которых отвечает за обработку подмножества нагрузки.

Если вы полагаетесь на то, что внутреннее состояние приложения согласовано во всех потоках, участвующих в предоставлении вашей услуги, вы захотите превратить число работников в 1, чтобы гарантировать, что все эти потоки находятся в одном процессе.


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