Состояние гонки с сеансом redis

Question

У меня проблема, что у моего программного обеспечения есть важные данные, хранящиеся в сеансе.

Поскольку я использую ajax, и пользователь может просто открыть программное обеспечение на нескольких вкладках, там будут параллельные запросы. Ограничение по одному запросу за один раз, к сожалению, невозможно.

Моя первоначальная попытка решить эту проблему состояла в том, чтобы использовать after_filter в приложении application_controller для вызова метода, который будет обнаруживать изменения, сделанные другими рабочими, и объединить их в свой собственный объект сеанса перед сохранением.

К сожалению, это смягчило мою проблему, но не решило ее полностью. Мне кажется, что между моим after_filter и промежуточным программным обеспечением, которое фактически сохраняет мой сеанс, который является ActionDispatch :: Session :: RedisStore, все еще существует разрыв, достаточный для того, чтобы другой рабочий написал свой сеанс.

Я не могу думать любого другого решения, чтобы закрыть этот пробел, но это одна:

1. Написать класс, который наследует от промежуточного
2. научить его выполнять «код сливаться» в get_session и set_session
3. заменить оригинальный промежуточное программное обеспечение с моим классом по config.middleware.swap

Перед тем, как сделать это, я хотел бы АКС для мнений и советов или, в идеале, лучшего решения. Мессинг с промежуточным ПО кажется мне слишком опасным, чтобы не спрашивать сначала.

Answer 1

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

Например, вы можете запускать несколько процессов с рельсами, каждый из которых выполняет прослушивание своего собственного порта и обеспечивает балансировку нагрузки (например, Nginx) над этими процессами. Балансировщик нагрузки с липкой функцией сеанса идеально подходит, но IP-хэш также является приемлемым.