分布式服务器设计

分布式服务器设计

1.什么是分布式服务器？

​ 数据和程序可以不位于一个服务器上，而是分散到多个服务器，以网络上分散分布的地理信息数据及受其影响的数据库操作为研究对象的一种理论计算模型服务器形式。

​ 在互联网大行其道的今天，各种分布式系统已经司空见惯。搜索引擎、电商网站、微博、微信、O2O平台。凡是涉及到大规模用户、高并发访问的，无一不是分布式。

​ 关于分布式系统，并没有一个标准答案，说某某架构一定是最好的。不同的业务形态所面对的挑战不一样，使用的架构设计也不一样，通常都需要具体业务具体分析。由于本人一直在从事游戏服务端的开发工作,下面就讲讲我们用到最多的所谓分布式的游戏服务器架构

2.关于分布式的基本思想

1.系统分拆

微信的架构师说过一句话：“大系统小做“。对于一个大的复杂系统，首先想到的就是对其分拆，拆成多个子系统。每个子系统自己的存储/Service/接口层，各个子系统独立开发、测试、部署、运维。从团队管理角度讲，也可以不同团队用自己熟悉的语言体系，团队之间基于接口进行协作，职责清晰，各司其职。

2.子系统分拆

拆成子系统之后，子系统内部又可以分层，分模块。当然，这里“系统“，“子系统“，“层“，“模块“ 都只是一个相对概念。在一个系统里面，某个模块复杂到一定程度，会把它抽出来，单独做成一个系统；而在初期，很大简单模块，可能不回拆分，集中在一个系统里面。 这就像一个生物组织，自身是在不断成长、演化、有分有合，不断变化发展的。

3.存储分拆

Nosql：对于Nosql数据库，比如MongoDB，其天生就是分布式的，很容易实现数据的分片。
Mysql: 对于Mysql，或者其它关系型数据库，就会设计到分库分表。而分库分表，就会涉及到几个关键性的问题：切分维度，join的处理，分布式事务

4.计算分拆

计算的分拆有2种思路：

①数据分拆：一个大的数据集，拆分成多个小的数据集，并行计算。
比如大规模数据归并排序

②任务分拆：把一个长的任务，拆分成几个环节，各个环节并行计算。

Java中多线程的Fork/Join框架，Hadoop中的Map/Reduce，都是计算分拆的典型框架。其思路都是相似的，先分拆计算，再合并结果。再比如分布式的搜索引擎中，数据分拆，分别建索引，查询结果再合并。

5.并发

最常见的就是多线程，尽可能提高程序的并发度。
比如多次rpc顺序调用，通过异步rpc转化为并发调用；
比如数据分片，你的一个Job要扫描全表，跑几个小时，数据分片，用多线程，性能会加快好几倍。

6.在线计算 vs. 离线计算 / 同步 vs. 异步

在实际的业务需求中，并不是所有需要都需要完全实时的：
比如内部针对产品、运营开发的各种报表查询、分析系统；
比如微博的传播，我发了一个微博，我的粉丝延迟几秒才看到，这是可以接受的，因为他并不会注意到晚了几秒；
比如搜索引擎的索引，我发了一篇博客，可能几分钟之后，才会被搜索引擎索引到；

比如支付宝转帐、提现，也并非这边转出之后，对方立即收到；等等

这类例子很多。这种“非实时也可以接受“的场景，就为架构的设计赢得了充分的回旋余地。

因为非实时，我们就可以做异步，比如使用消息队列，比如使用后台的Job，周期性处理某类任务；

也因为非实时，我们可以做读写分离，读和写不是完全同步，比如Mysql的Master-Slave。

7.Push vs. Pull

在所有分布式系统中，都涉及到一个基本问题：节点之间（或者2个子系统之间）的状态通知。比如一个节点状态变更了，要通知另外一个节点，都有2种策略：
Push: 节点A状态变了， push给节点B
Pull: 也就是轮询。节点B周期性的去询问节点A的状态。

这个问题不光出现在分布式系统中，可以说是编写代码的一个基本问题。对应到面向对象的编程中，也就是常说的“双向关联”这种耦合问题。

A调用B，B再回调A，这种情形，在系统开发中经常出现。再复杂一点，多个模块之间，彼此调用，调用关系跟蜘蛛网一样。

这个问题的出现，就和Push/Pull的策略密切相关： A调用B，那逻辑就会写在B这边；B调用A，逻辑就会写在A这边。所以是采用主动调用的pull方式，还是回调的push方式，会严重影响职责在各个模块或者子系统里面的分配。

8.CAP理论

上面讲的各种思想，用一个更大的思想来概括的话，就是CAP。

Consistency：数据一致性，这个很容易理解，就是没有脏数据。我们知道，在Mysql中有一致性的概念，比如参照完整性约束、事务等。但这里的C主要特指同1份数据的多个备份之间的一致性。

Availability：可用性有2重意思，一个是说稳定性，服务可用，不会挂；另外一个是性能，也就是要快，如果延迟很高，经常超时，那和挂了也就区别不大了。

Partition tolerance(分区容错性)：分区，其实指网络分区。当你把数据从1个物理设备，分到多个物理设备之后，设备之间必然是通过网络进行通信。这就会遇到网络分区，也就是典型的“2将军问题“，网络超时时间不定。学术上有个词，叫“异步通信环境“。

以前说CAP理论，说对于一个分布式系统，上面3个，只能同时满足2个。但这个其实不准确，P其实一定存在，是你避免不了的。能做的，其实主要是在C和A之间权衡。

比如拿Mysql来说，它的C最强，A次之，P最弱。如果你为了A，给数据做冗余，比如重写轻读，那C就很难保证；为了P，给数据做分库分表，那就做不了事务；

比如Nosql，P最强，可以很好的做数据拆分，但C就不够，做不了事务；

比如微博系统，对C的要求降低，就可以加很多缓存，提高A；数据分片，提高P；

而支付，交易转帐，对C的要求很高，就不能简单的用Cache来提高性能

3.游戏服务器最常用的分布式

其实在写这篇文章时，我也不知道游戏服务器中到底有没有涉及到分布式，但是CAP理论深深的启发了我.

多进程的游戏服务器系统，最早起源于对于性能问题需求。由于单进程架构下，总会存在承载量的极限，越是复杂的游戏，其单进程承载量就越低，因此开发者们一定要突破进程的限制，才能支撑更复杂的游戏。

一旦走上多进程之路，开发者们还发现了多进程系统的其他一些好处：能够利用上多核CPU能力；利用操作系统的工具能更仔细的监控到运行状态、更容易进行容灾处理。

多进程单线程的服务器设计模式

网路通讯，业务逻辑，数据存储，守护进程，分别在不同的进程。

①各个进程可以分布在不同的物理服务器上，可以做成分布式的服务器框架，例如可以将数据存储单独放到一个物理服务器上，供几个区的服务器使用。将网络通讯进程独立出来，甚至可以做成导向服务器，实现跨服战。

②可以通过守护进程监控其它进程状态，例如有进程死掉，马上重启该进程，或者某个进程cpu使用率接近100%（基本可以判断是某个逻辑死循环了）, 强制kill掉该进程，然后重启。

③单个服务器进程异常退出，只要不是网络通讯进程（一般这个都会比较稳定，没什么逻辑），那么就可以及时被守护进程重启，不会造成玩家掉线，只会造成在1-2秒内，某个逻辑功能无法使用，甚至玩家都感觉不到。

④服务器通过共享内存进行数据交换，那么如果其中一个服务器死掉，数据还在，可以保护用户数据（当然多线程也可以使用共享内存）。

⑤并发性相对多线程要高点。

4.如何划分进程？

游戏服务器中最常用的:

1.按照游戏地图拆分:将服务器中的地图服务器拆分成多个,每一个地图一个进程

2.按照玩家人数拆分:根据单进程服务器最大可承载的人数,进行拆分多个进程,已达到分流

3.按照业务功能拆分:根据不用的玩法,将计算量大的功能单独使用一个服务器进程

等等

5.分布式架构需要解决什么?

我个人认为可以分为两点：

1.负载均衡

利用不同进程间的服务器通讯来了解各个进程间的负载情况，从而合理分配服务器及客户端连接

2.数据同步

比如商品页面的图片，如果进行了修改，同步要求并不高，就算有数秒甚至数分钟的延迟都是可以接受的，因为一般不会产生损失性的影响，因此可以简单的通过文件修改的时间戳，隔一定时间扫描同步一次，可以牺牲一致性来提高效率。

但银行中的分布式数据库就不一样了，一丁点不同步就是无法接受的，甚至可以通过加锁等牺牲性能的方式来保障完全的一致。

总结:

分布式是计算机科学中十分重要的一个研究领域。随着现代计算机集群规模的不断增长,为了能达到较好的可靠性(Reliability)、可扩展性(Scalability)和可维护性(Maintainability)，分布式系统设计中通常会使用多副本(Replication)、数据分区(Partition)、一致性算法(Consensus)、事务(Transaction)等技术。

参考文献:

[1]游戏服务器框架分析 博客园

[2]分布式架构—基本思想汇总 CSDN

[3]分布式与集群的区别是什么？知乎