Question

游戏服务端究竟解决了什么问题

Answer 1

邮件操作一定产生大量IO操作。
没事不要用c或者c++写游戏服务器端，而且正常情况下每个请求的处理时间不会超过50毫秒、有大量工具包、开发周期短才是最重要的。可参照EJB二次远程调用的原理实现多机分布式结构，可使用LRU算法来淘汰一些数据，由后台的数据库保存线程定期保存，内存就会不够。搜索UDP。

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

避免同步的IO操作