0

我们正在开发一个 Web 应用程序,应该至少有 10,000 人同时登录。现在,我们正在尝试解决以下问题,

目标 - 禁止并发登录(使用相同的凭据登录)

接近的解决方案 - AJAX 调用在 javascript 计时器上运行,以检查数据库中的本地会话 ID 和会话 ID。详细解释请参考避免并发登录

问题 - 在有大量在线用户的情况下,每 10 秒通过一个计时器访问服务器会在服务器上产生巨大的负载,即最大连接数/秒和不必要的客户端-服务器事务,即使没有并发登录也是如此。

解决方案 - 除了我们目前解决并发登录问题的方法之外,还有其他方法吗?

非常感谢您的精彩!!!!...

4

1 回答 1

0

Interesting question.

I'd say that anything that can be done to use a pure RAM based solution would probably be the best fit for this type of problem. Mysql has a RAM based storage engine but that aside, memcached and redis both has automated data expiry and probably has superior performance, so I consider them a better fit. See Redis expire and memcached expiration.

If you can make sure that you only hit stuff in RAM, I believe you have won half the battle.

Besides that, try carefully evaluating how frequently you really need "pings" from the clients. If the user is idle, is it then necessary that the clients sends a ping every 10 seconds? Is it possible to handle user interaction after a session expiry gracefully? (Such as having the user click a button and the system then responding something along the lines "you are already logged in, please close the other window". This could work if the users aren't spending a long time writing things into forms, only to discover that they have been logged out once they submit.)

What is the worst case scenario?

Try this scenario:

| time | Client 1    | Client 2 | Server                     |
|   t0 | Log in      |          |                            |
|   t1 |             |          | Authorize client 1 session |
|   t2 | Send ping   |          |                            |
|   t3 |             |          | Update client 1 session    |
|   t4 |             | Log in   |                            |

Lets say that the time between t3 and t4 is 1 second. In that case what happens next is:

|   t5 |             |          | Server rejects client 2    |

And if the time between t3 and t4 is 20 seconds and the ping interval is 10 seconds, we'll assume that Client 1 is gone and:

|   t5 |             |          | Delete client 1 session    |
|   t6 |             |          | Authorize client 2 session |

But you could use a model with much longer ping intervals, and introduce a possible delay before the client is logged in. Given that the ping time is 60 seconds and the time between t3 and t4 is 30 seconds:

| t4+30| Send ping   |          |                            |
|   t5 |             |          | Server rejects client 2    |

Or - if client 1 is gone,

| t4+30|             |          | Delete client 1 session    |
|   t6 |             |          | Authorize client 2 session |

But this delay will only take place if there has been a recent login from another client, so if the typical use case has only one client per user, it won't pose a serious problem.

于 2013-06-18T19:35:55.230 回答