php для сайтов с большим трафиком

Question

Я читал, что "вероятным" недостатком PHP является то, как он обрабатывает "параллелизм". Только с помощью сессий и файлов cookie для отслеживания состояния пользователя, как PHP может обрабатывать следующие ситуации с высокой точностью:

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

2. несколько пользователей входят в одну и ту же учетную запись, используя одни и те же данные для входа

3. несколько пользователей одновременно редактируют одно и то же изображение (хотя в реальной жизни такое бывает редко)

или любые другие транзакции, требующие обработки нескольких потоков

(прошу прощения, если я здесь неправильно использовал термины)

Answer 1

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

1. Пользователи, опускающие свой инвентарь в 1, не виноваты в PHP. Вы можете временно игнорировать 1, когда кто-то уже добавил его в свою корзину, и освободить его, если он не приобрел его до истечения сеанса.
2. Хорошо? Вы можете выйти из системы других пользователей или управлять всеми сеансами.
3. Опять же, они, скорее всего, не сделают это в то же микротоп . Если они это сделали, подбросьте приятную ошибку и попросите их попробовать еще раз. Как указано в комментариях, MySQL обладает достаточными возможностями для обработки этих типов событий (если они когда-либо происходят).

Answer 2

Это не настоящие проблемы параллелизма. Несмотря на то, что PHP как среда не обладает возможностями потоков, любой веб-сервер, использующий модуль PHP, будет иметь несколько потоков, каждый из которых имеет собственную активную среду PHP внутри, и все будут использовать одни и те же ресурсы. Вы можете столкнуться с этими проблемами с Java, .Net, Perl или любым другим языком веб-приложений.

1. Вам нужна транзакция в вашей базе данных, возможно, с блокировкой записи, чтобы другие пользователи не могли ее прочитать и запустить процесс извлечения, пока кто-то проверяет. Это не проблема языкового потока, это проблема транзакций базы данных.
2. Это не проблема с многопоточностью. Сеансы довольно тривиальны со всеми доступными инструментами, и я никогда не слышал о стиле «один поток на сессию» реализации на любой языковой платформе (это было бы нетривиально, сложно реализовать и просто добавило бы накладные расходы). Вы либо разрешаете активировать несколько токенов сеанса для одной учетной записи (пользователь может входить в систему несколько раз на разных вкладках или в веб-браузерах, если они этого хотят), либо нет (все токены сеанса очищаются каждый раз, когда выполняется процедура входа в систему, так что только один токен активен).
3. Странно, но я не уверен, как здесь вписывается многопоточность. Редактирование изображений должно быть сделано на стороне клиента в браузере. Вы не можете держать «темы» открытыми для браузера пользователя на любом языке ... HTTP не работает так. Вы отправляете им изображение, и все готово, пока они не нажмут «сохранить» и не отправят его обратно. Если вы беспокоитесь о том, что пользователи перезаписывают изменения друг друга, опять же, вам просто нужно установить транзакционную блокировку. Я бы, вероятно, просто «версировал» каждое изображение, и если бы обновление происходило от одного пользователя, когда другой редактировал его, вы бы сообщили другому пользователю, что ему нужно обновить свою копию.

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

Answer 3

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

Answer 4

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

Но если я прочитаю ваш вопрос типа "Является ли PHP масштабируемым?", То ответ также будет положительным.

PHP обрабатывает «параллелизм» как можно лучше, потому что он полностью скрывает все связанные с параллелизмом детали от приложения, что хорошо для веб-приложений. Это делает приложения по своей природе масштабируемыми, так же как HTTP сделал «веб» масштабируемым. HTTP не имеет состояния, поэтому в некотором смысле PHP не имеет состояния. Это позволяет легко масштабировать по горизонтали, например, добавив больше аппаратного обеспечения без изменений в код приложения (хотя это все еще требует некоторой поддержки приложения заранее).

Ознакомьтесь с этими замечательно статьями для объяснения.

Answer 5

Вы когда-нибудь слышали о транзакциях базы данных? При правильном использовании они могут исправить все ваши проблемы (кстати, это не проблемы PHP).

Answer 6

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

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