本文主要是介绍sns的服务器架构设计，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
今天写写网络负载的事。之前的项目是MMORPG，mina做网络层的TCP服务器。服务器设计目标应该是5K人以下，其实一般的上线服务器设定3k的就会显示爆满了。当时除了偶尔会突然出现CPU峰值之外，可能是服务器富gc吧，一般情况下还是很轻松的。听说当时的服务器还不是太好的硬件。手机屏幕显示的玩家还是比较少的，通过用分线的策略，按块同步的方式，再加上手游玩家对网络的宽容：），同步的压力也不算太大， 总的来说项目还是比较成功的。
现在的项目是一个轻sns的的游戏， 对服务器要求很不高， 如果不主动联网，你甚至可以当它是一个单机游戏，而且客户端对手机电量有要求，所以选择了HTTP协议。
但是因为需求表面上看起来是很简单，所以大家对服务器的负载都有很大的期望，第一个目标是一台服务器负载20W的同时在线用户。
首先，HTTP的协议的方式对网络层的第一个考验应该就是session的问题。
这里还是遇到一个问题， 看jetty的介绍，其中一个特色就是容器内的各个模块是独立组件式的， 这样的话session是可以手动关闭的。 而再看到一些资料， 据说当request.getsession（）方法不主动调用时就不会创建session， 这样也就无所谓关不关容器的session功能了。 与客户端协调了一下， 认为客户端的cookies实现的方式是可以保证安全的。 服务器做一个sessionID加密。 就可以当做令牌填到HTTP协议头上实现客户端，服务器端交互了。
第二， 应该考虑的问题是数据存在哪的问题。
MMORPG的服务器，是高交互，数据使用密集而又集中的场景， 用户量不大，单独的服务器将数据保存在内存里就完全好使了， 而且，编程实现起来也很简单。 当然， 也正是因为这个原因，导致MMORPG的服务器一般没有人想着做成一个大而一统的系统的， 分区分线的方式广大玩家也已经接受。但是SNS类的游戏面临的是用户数据量巨大， 交互比较少，玩家之间的互动也相对较少，但人与人之间建立的关系是以现实中人与人的的基础建立起来的， 你不可能让一个人上一个sns游戏里找到自己的同学时发现TA在3区，而自己在1区。 鉴于他们很少的数据交互，实时性要求也不高的情况下，做一个大而统一的服务器是可以实现的。因为我们可以做web集群，可以做负载均衡。 可以一个游戏放100台web服务器来做业务服务器。 但要求100台服务器的内存是一个统一体， 那么大量数据存在哪呢？好吧， 就是memcached。
关于memcached我也没怎么研究过， 据同行们说，有这么用的。 先把架构搭起来，一步步走吧。
第三， 都是谁在线？
想要在一个远程内存环境里去维护一份在线列表其实也不是容易的事， 假如一台服务器20w人的数据， 每条在线状态还需要记录一个活跃的时间。多个服务器乘下来，很可能一份在线列表就是几十M的量。 此外，web服务器之间的列表数据合并的消耗。 memcached获取数据后版本重新失败，需要重新gets下来再cas等等。即使是局域网下的数据交互也是不能忍受的。 该怎么做？我们想了一个办法， web服务器群组开TCP连接到一个World服务器上。 world服务器来同步大家的时间，在线列表统一管理，即每台web服务器变化了的在线状态列表集中发到world服务器上，world服务器将在线列表更新到Memcached服务器上，然后逐一通知web服务器，去做更新操作。
第四， 数据保存。
同样的问题，在mmo的服务器实现上，一般都是间隔行的保存数据。 并且一般不会很频繁， 甚至有的实现是直接共享内存，异步的保存数据，java实现起来不好实现，但是异步的间隔性的保存数据对数据库压力还算可以。基于这个思路，我们的sns服务器也正好有world服务器， 数据的保存就可以交给world服务器来做了。 不会对用户产生任何影响。但是可能会有数据一致性的问题带来。
总的来说，游戏服务器的设计还是有很多不懂的， 没有很好解决了问题的情况。其实办法可以一步步的想出来，最大的问题是有些连自己都不知道的问题出现。 而这种问题往往会发生在服务器上线之后。 路还很长，一步步走吧。
这篇关于sns的服务器架构设计的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
