如何在服务器端管理大量用户?

时间:2012-09-30 10:34:03

标签: java

我构建了一个社交Android应用程序,用户可以通过gps位置查看周围的其他用户。一开始事情进展顺利,因为我的用户数量很少,但现在我的用户数量越来越多(每天约1500 + 100),我在设计中发现了一个主要问题。

在我的Google App Engine servlet中,我有静态HashMap,它包含所有用户配置文件对象,当前1500,随着更多用户注册,此数字将会增加。

为什么我这样做

请求周围用户的每个用户将他的gps与其他用户进行比较,并检查他们是否在他的10公里范围内,平均每5分钟发生一次。 这就是我每次都无法从db获取用户的原因,因为GAE读/写操作配额会让我分开。

此设计的问题是

随着用户数量的增加,Hashmap每4-6小时变为空,我觉得这次会缩短,但我不确定。 我正在通过每次检测到它变为空时从数据库重新加载用户来修复此问题,但这会导致DOS给我的用户30秒,所以我正在寻找更好的解决方案。
我猜它发生的原因是hashmap的大小,我是对的吗?

我想知道如何管理所有用户个人资料并获得最大的可用性。

感谢。

2 个答案:

答案 0 :(得分:1)

我不会将这些数据存储在HashMap中,因为如果你在多个实例上运行并且你使用了大量内存,它就无法真正扩展。

为什么不使用像MongoDB这样的“云端”可用的不同存储? (例如www.mongohq.com)。

如果您想扩展,则需要将数据与处理器分开。例如。让x服务器运行你的servlet(或者让Google AppEngine自己扩展它)并将数据放在不同的地方(例如在MongoDB或PostgreSQL中)。

答案 1 :(得分:0)

您需要重新考虑整个设计。将所有用户存储在一个巨大的HashMap中将无法扩展(迟早您将需要对应用程序进行集群)。此外,算法的复杂性非常高 - 您需要遍历每个用户的整个地图。

更具可扩展性的解决方案是使用spatial database。所有主要关系数据库和一些NoSQL产品都提供地理空间索引。基本上,数据库查询引擎针对以下查询进行了优化:为我提供接近此给定点的所有记录

如果您的应用程序真的成功,即使是内存映射也会比企业级地理空间索引慢。