-
所有的对象都放在内存，20万用户以下无压力。
-
如果游戏的用户很多，例如超过50万，内存就会不够，可使用LRU算法来淘汰一些数据。
流程：收到用户请求 - 在内存查找用户对象 - 如果不存在就从数据库中加载- 放入内存cache-如果cache中的用户超过20万 - 用LRU算法淘汰最古老的用户数据。
-
避免同步的IO操作，所有会发生写数据库的操作：例如角色获得了经验，要更新数据库；这类和游戏逻辑相关、安全性要求不高的保存操作，一律用异步操作，由后台的数据库保存线程定期保存。
流程：如果要保存到数据库 - 检查该对象是否已有标志为在保存队列中 - 如果为假 - 将对象放入保存队列。 后台保存线程的流程：从队列中获取要保存的对象 - 保存 - 置保存标志位为假。
内存cache + 异步保存模式，并发 每秒1000+ 不会有任何压力，而且正常情况下每个请求的处理时间不会超过50毫秒。
邮件操作一定产生大量IO操作，而且都是同步操作，可用上面的cache机制处理，或者专门的邮件服务器。
如果是DNF之类的格斗类游戏，因为对系统响应的时间要求特别高，50毫秒都嫌慢，这种情况下，瓶颈是在网络上，可用UDP包来解决。搜索UDP，有大量文档。
如果用户数是海量的，例如超过500万，或者对并发的要求更高，例如每秒5000+次请求，这种指标明显超过了单机的处理能力，这个时候就必须采用分布式结构，使用多台服务器。可参照EJB二次远程调用的原理实现多机分布式结构，搜索EJB，也有大量文档。