php为“高流量”网站

Question

I have read that PHPs "probable" weakness is how it handles "concurrency". With only sessions and cookies to keep track of user state, how can PHP handle the following situations with high accuracy:

1. multiple users check out with one item that has only 1 stock in inventory (sorry for grammar mistakes, but you pretty much get the picture already)

2. multiple users logging into the same user account using the same login details

3. multiple users editing an the same image at the same time (though this rarely happens in real life)

or any other transactions that demands multiple thread handling

(I apologize if I misused terms here)

Answer 1

These aren't necessarily problems for PHP. These are problems for developers to overcome given any technology of choice.

1. Users letting their inventory get to 1 isn't PHP's fault. You could temporary ignore the 1 when somebody has already added it to their cart though, and free it up if they don't purchase it before their session expires.
2. Okay? You can logout other users, or manage all sessions.
3. Again, they likely won't do it at the same microtime . If they did, toss up a nice error, and ask them to try again. As pointed out in the comments, MySQL has sufficient capabilities to handle these types of occurrences (if they ever happen).

Answer 2

These aren't real concurrency issues. While it's true that PHP as an environment lacks in thread capability, any web server utilizing a PHP module will have multiple threads, each with thier own active PHP environment inside it, all utilizing the same resources. You would run into these problems with Java, .Net, Perl, or any other web application language.

1. You need a transaction on your database, probably with a write lock so that other users can't read it and run the checkout process while someone else is checking out. This is not a language thread issue, it's a database transactional issue.
2. This isn't a threading issue either. Sessions are fairly trivial with all the tools available, and I've never heard of a "one thread per session" style of implementation on any language platform (that would be non-trivial, difficult to implement, and would just add overhead). You either allow multiple session tokens to be active for one account (user can log in multiple times on different tabs or web browsers if they want), or you don't (all session tokens are cleared each time a login procedure occurs so that only one token is active).
3. An odd one, but I'm not sure how threading fits here either. Image editing would have to be done client-side in the browser. You can't keep "threads" open to a user's browser in any language... HTTP doesn't work like that. You'd send them the image and you're done until they hit "save" and send it back. If you're worried about users overwriting each other's changes, again, you'd just have to put a transactional lock on it. I'd probably just "version" each image, and if an update occurred from one user while another was editing it, you'd inform the other user that they needed to refresh their copy.

As far as I'm aware, no language uses threads to accomplish any of these tasks. Because of the stateless nature of HTTP communication, cookies are sessions are a mainstay of every web language, so no matter what platform you use, you're going to see very much the same strategy in all of them for handling a given problem.

Answer 3

1. 您的数据库应该自动处理事务并删除最后一项，将其从php的责任中删除

Answer 4

Just like all languages you'll need to find some way of locking these files. If you're new to concurrency you might start out here and do some research on the different methods available to you.

But the real question I have is whether this is actually going to be a problem. And if you are going to be in a high concurrency system how high is the damage in the case of a collision. If the cost of a collision is really high, it might be work contracting out to someone who already has cut their teeth on this and just watch what methods they use.

Answer 5

Have you ever heard of database transactions? Used properly, these can fix all of your problems (which aren't PHP problems, by the way).

Answer 6

If your question is about transactions, then the answer is yes, but it is not a feature of the language itself. Transaction safety is the task of the database layer (usually a relational database like MySQL).

But if I read your question like "Is PHP scalable?", then the answer also is yes.

PHP handles "concurrency" just as perfect as possible, because it hides any concurrency related details completely from the application, which is a good thing for web applications. It makes applications inherently scalable, just as HTTP made the "web" scalable. HTTP is stateless, so PHP is stateless in a sense. This allows easily horizontal scalability, eg by adding more hardware without change to the application code (though this still requires some application support beforehand).

Check out these great articles for an explanation.