Оптимальный способ реализации сеансового кэша

Оптимальный способ реализации сеансового кэша
Оптимальный способ реализации сеансового кэша - mahkeo @ Unsplash

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

Пока что я сделал следующее: я создал ConcurrentHashMap, который хранит Session объект (объект состоит из SessionID, CreatedTime, Validity, ServiceURL, Session и т.д.) Когда приходит новый запрос, я получаю HashMap объект из sessionID, проверяю действительность сессии и, если он действителен, возвращаю сессию.

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

Изначально я думал добавить новое поле Session в объект lastAccessTime и проводить валидацию на его основе. Но проблема в том, что поскольку мое приложение является высоко параллельным приложением, которое обрабатывает много запросов, каждый раз, когда приходит запрос, я буду извлекать сессию, обновляя HashMap и добавляя обратно в HashMaps, что кажется накладным.

Есть ли лучший способ сделать это (я думал, может быть, поддерживать два Session, один для lastAccessTime объекта, другой для ConcurrentHashMap)? Или я могу просто игнорировать тот факт, что сессия обновляется при доступе, и придерживаться первоначально созданной сессии. Возможно, я буду делать больше запросов к Salesforce, но между обновлением карты сессии при каждом запросе я буду чувствовать, что это более эффективно.

и добавляем обратно в HashMap

Почему? Активность не является причиной для удаления из карты. Причиной является истечение времени.

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

Вы можете просто хранить lastAccessTime в объекте сессии и позволить объекту самому обновлять и сообщать об этом. Я сомневаюсь в этом, потому что это сделает объект сессии изменяемым, а вы сказали, что это очень параллельная задача.

Устойчивым к параллелизму решением может быть просто создание новых карт при очистке. Допустим, ваши сессии заканчиваются через 15 минут. Поддерживайте 5 карт. При активности добавьте сессию во все 5. Через 3 минуты сбросьте первую карту и начните новую. Вы по-прежнему поддерживаете 5 карт, и единственная мутация заключается в том, в каких картах хранятся текущие сессии.

Если вы думаете, что это в 5 раз больше работы, то вы не изучали нотацию большого О. Если это слишком много, вы, скорее всего, решаете непроблему.

Поскольку вы пытаетесь оптимизировать несколько видов деятельности в быстрой последовательности, начните проверку с самой новой карты.

Большая экономия здесь в том, что вы не держите мертвые сессии. Таким образом, они не съедают память и не раздувают карты. Вам не нужно зацикливать карту, чтобы избавиться от них. Достаточно просто выбросить всю карту.

Жертвой является гранулярность тайм-аута. Вам важна точность тайм-аута до миллисекунды?

Это упрощает работу с картой. Карта должна хранить только ссылку на объект сессии. Она не должна иметь никакого представления о том, что сессии имеют тайм-аут. Сессии либо есть в карте, либо их нет.

Отказ от ответственности: Я никогда не кодировал это и не видел кода, который это делает. Просто идея, которая пришла мне в голову. Если вы попробуете это, ПРОВЕРЬТЕ.


LetsCodeIt, 18 января 2023 г., 04:32