关于游戏服务器的服务拆分

先阐明一下观点,可以使用单体（单线程）应用程序解决的问题,都不应该使用分布式系统来解决，因为分布式真的很复杂。 在游戏服务器中，我们做服务拆分，大部分情况下都是为了可伸缩，而不是为了高可用（这里暂不考虑那些使用WEB模式实现游戏服务器的思路。我认为这种思路，逻辑的复杂度和实时性都不能保证，而且还需要处理并发问题。) 以前我就说过，游戏服务器的开发更像是在开发数据服务。 现在，我觉得可以更明确一点。 游戏服务器的开发，其实就是针对某种业务逻辑开发的专用数据……

再谈分布式服务架构

在两年前，我曾经设计过一版，高可伸缩服务器架构， 但只进行了理论推演，并没有使用具体业务逻辑验证过。以这两年的经验来看，这个架构不具备可实施性。 在之前的架构中，我只考虑了Gate和其服务之间的交互。没有考虑其他服务之间也会有基于"玩家"的交互，还可能有基于"联盟"等其他对象的交互。 按这套模型继续演化下去，为了解决"任意两服务"之间的交互问题，势必需要所有服务都有一份相同的Agent对象。这样一来，整个架构的复杂性就大大提升了。 ……

客户端缓存落地方案

先大致描述一下场景，客户端按登陆流程成功登陆后，开始按各个模块加载所需数据，待收到消息返回后cache在内存中，只有当所有模块全部加载完成之后，客户端才算真正登陆成功，这时玩家才可以进行各种操作。在玩家操作过程中，客户端不断与服务器进行消息交互，并始终与服务器数据保持一致（这里是指状态一致，不是指所有数据全部一致，服务端存储的数据与客户端所需要的数据并不完全相同）。 由于模块过多，每个模块都是分别独立加载，因此从用户点击登陆按钮开始到真正可以操作所经……

Paxos算法

大神说，世界上只有一种一致性算法，那就是Paxos。 但是大部分文章或论文的套路都差不多，先说paxos是一个完美的一致性算法，然后就给出证明等等，最后才给出实现步骤。 然而，对于我这个初学者来讲，我更希望先知道这个算法是如何工作的，然后再去研究他们的证明过程。这其实也符合学习的过程，先抛出问题，思考之后，最后看答案印证。然而大神写的Chubby并不开源，而证明过程也很数学化，很难理解在实际执行流程当某一步出现错误时，这个算法是如何保证数据的一致性的。 本文从pax……

一个高可伸缩的游戏服务器架构

设计完socket通讯协议后，就面临着服务器架构设计了。我希望他是一个去中心化且具有高可伸缩性的集群架构。 水平扩展是高可伸缩的首要条件，因此，在设计之初就必须考虑好水平扩展考方案。事实上这一部分几乎花了我1整个月的时间来设计，在此期间我重写了3版才总算确定下来我认为可用的方案。 第一版设计方案如下： 将服务器分为3类，分别是GateServer, LoginServer, LogicServer。 GateServer管理客户端链接，数据包的加密、解密、广播、转发等与业务逻辑无关的操作。当压力过大时……

服务器的分布式部署

两周前使用redis-benchmark测了一下silly的并发请求响应速度， 开1000个客户端， 平均大概每秒能响应6W个请求。 但是这些请求仅仅是PING/PONG协议，也就是说这基本上就是纯网络I/O的性能，如果考虑到逻辑处理、数据压缩、加密、解密等时间， 可能一个silly都不一定能够撑得起5000人的访问量。 所以最近两周除了在研究redis之外， 就是在研究怎么给silly增加cluster支持，以便可以将计算分摊到不同的计算机上来降低客户端的请求的响应延迟，silly应该怎么增加对cluster的支持。 直到……