Сессии в PHP — подводный камушек при асинхронных запросах

Я не использую сессию для хранения подобных данных, там только данные по авторизации пользователя и текущей сесиии. Если нужна статистика — использую модуль статистики, для работы с временными данными — memcache или тот же mongo.

Да, привет) вот и у меня что-то смутное в голове шевельнулось, решил написать.

Мы не могли столкнуться с этим в РИА, т.к. там использовался Drupal 6. который хранит сессии в БД.

Может ты столкнулся с этим, во время работы в РИА, но в другом проекте? :)

Сначала надо определиться — нужна ли блокировка сессии. Это зависит от того, какие данные хранятся в сессии и как они используются.
В своё время я для своего проекта пришёл к выводу, что от блокировки можно отказаться.
Далее пользовал встроенные механизмы memcache(d), но в итоге остановился на использовании очень простых собственных хэндлеров. Получив при этом прозрачный для меня механизм сессии, вместо «чёрного ящика». Это оказалось плюсом, т.к. проект был нагружен (более миллиона pageview в сутки).
Вот код:

function my_session_open($save_path, $session_name) {
  return true;
}
function my_session_read($id) {
  $GLOBALS['session_read_return'] = Cache_Proxy::get($id);
  return $GLOBALS['session_read_return'];
}
function my_session_write($id, $data) {
  if ($GLOBALS['session_read_return'] == $data) return true;  // Если в пределах этого запроса данные не менялись - не записываем их обратно
  return Cache_Proxy::set($id, $data, 0, 36000);
}
function my_session_destroy($id) {
  Cache_Proxy::delete($id);
  return true;
}
function my_session_gc($maxlifetime) {
  return true;
}
function my_session_close() {
  return true;
}
session_set_save_handler('my_session_open', 'my_session_close', 'my_session_read', 'my_session_write', 'my_session_destroy', 'my_session_gc');
register_shutdown_function('session_write_close');

В качестве кэша используется APC (apc_fetch и apc_store). Работает очень быстро при любых нагрузках. Сбором мусора занимается АРС.

PS: если бы завтра нужно было писать новый проект с нуля, я бы вообще не стал бы использовать такой механизм как сессии. По сути вся «сессия» — это уникальная кука на клиенте + данные на стороне сервера, однозначно связанные со значением этой куки. Так зачем всё усложнять и вносить в систему такой чёрный ящик, как стандартные сессии? (прошу воспринимать это не как совет, а как личное мнение, которое вполне может быть ошибочным)

Там REST full-stack описание. (а не только про сессии)