总结：那些热门的开源游戏服务器框架，还不看你就out了

作为一名业内资深的游戏开发人员，经常会遇到实习的新同事在工作中会问到这样的问题：

工作中到底有哪些开源游戏服务器框架，该去值得学习呢？

囊括到nodejs 、java、C#、golang 、c++、python 等技术栈有各种各样的游戏框架。

本文给大家总结了一些github上star和fork比较常用的且有一定数量的较为完整的框架做了一个说明，大家可以往下看。

地址： >1、如果使用python语言，需要学习哪些知识？
python作为一门简单明了的语言，非常容易上手，语言层面不会太复杂，稍微有点难度的顶多就是装饰器、元类和少量函数式编程内容。要说学习的话，我觉得更多是一些编程方面通用的东西，比如：数据结构和算法、设计模式、 *** 作系统、计算机网络之类的
2、选择什么样的python框架开发，这个框架的优势？
tornado，因为非阻塞io的原因，性能非常高，特别适合写后端API（App的后端应该都是rest风格的api），而且成熟稳定
3、如何部署服务器？本地服务器调试，以及公网服务器部署？
这个一两句说不清楚，涉及到运维、测试、开发诸多方面， 部署和测试推荐几个包：fabric、nose、unittest(python自带)，版本管理推荐git，持续集成推荐使用docker+jenkins
4、如果使用python框架开发移动后台服务，在开发源码内使用哪种框架？mvc还是其它的，比如我返回json数据，每次json对象最外层有一些相同的东西，该如何处理？
MVC什么的，一般的框架都差不多的，tornado也是支持的，返回json有相同的东西，写个修饰器就完了
5、python的后台服务最大能支持多大的pv量会严重影响用户体验性能？
youtube、reddit、豆瓣、知乎这样的大流量网站都是python写的，觉得你的App的规模不太可能遇到性能问题，即使有也应该不是python的问题，而是任何语言都会有问题。毕竟web后端不是计算密集型，而是io密集型的，python和其他语言的区别不会太大吧，大量的pv是可以靠堆服务器堆出来的，如果是计算量比较大的任务，你可以考虑用c或c++写
6、如何兼顾 网页前端以及移动端 开发的后台？
用python写的API，网页和移动端都是可以调用啊，让前端学学React，就可以轻松解决前后端分离这个问题（PS: facebook 就是后端php + 前端React，淘宝也有在用nodejs做前后端分离）
7、有没用相关的案例，即用python开发的移动后台？有没有该问题的开源项目？
这个应该比较少，App后端开源的不常见，而且大部分是rest风格的api，很多时候会涉及到自身的业务和敏感信息应该不会开源的吧（又不是bbs或者博客程序）

亿万克蛟云AF系列全闪存存储是基于NVMe协议的全闪存阵列，采用NVMe SSD作为存储介质的存储产品，面向高IOPS的客户环境，如高性能计算ERP、CRM、VDI等，针对数据中心IO密集型、延迟敏感性等关键业务能提供极致的性能、全方位的数据保护和全产品生命周期解决方案。针对客户的业务模型，针对闪存的读写进行优化，能满足客户不同环境下的需求，实现极高的IOPS、IO吞吐带宽以及极低延时。感兴趣的话点击此处，免费了解一下

服务器的功能相对于PC机来说复杂许多，不仅指其硬件配置，更多的是指其软件系统配置。服务器要实现如此多的功能，没有全面的软件支持是无法想象的。但是软件系统一多，又可能造成服务器的使用性能下降，管理人员无法有效 *** 纵。所以许多服务器厂商在进行服务器的设计时，除了在服务器的可用性、稳定性等方面要充分考虑外，还必须在服务器的易使用性方面下足功夫。

亿万克研发高性能 MCA 移动网络信息终端产品，荣获“国家重点新产品证书”，并在同年成为英特尔嵌入式联盟 (Intel Embedded Alliance) 的 Associate 级会员、微软嵌入式全球金牌合作伙伴，开启服务器研究领域新征程。亿万克亚当R322N6是一款搭载英特尔第三代至强可扩展系列处理器的2U双路虚拟化计算型服务器，计算性能强，性能稳定，拥有优异的整机输出性能。

本文介绍NGINX缓存机制，配置和参数说明。

如图所示，nginx缓存，可以在一定程度上，减少源服务器的处理请求压力。因为静态文件（比如css，js， ）中，很多都是不经常更新的。nginx使用proxy_cache将用户的请求缓存到本地一个目录。下一个相同请求可以直接调取缓存文件，就不用去请求服务器了。毕竟，IO密集型服务的处理是nginx的强项。

Nginx的缓存加速功能是由proxy_cache（用于反向代理和静态缓存）和fastcgi_cache（PHP动态缓存）两个功能模块完成。

Nginx缓存特点：

先上个例子：

因为我是在一台服务器上做试验，所以用了两个端口 80 和 90 进行模拟两台服务器之间的交互。

接下来讲一下配置项：

这里我设置了 、 css 、 js 静态资源进行缓存。
当用户输入 >

解目前3大主流企业级私有云落地方案主要有以下三种，下面逐一介绍，并讲解其各自特点：

将AWS、Azure、阿里云等商业公有云方案全套落地到私有环境；

使用类似 OpenStack、Ceph 等开源软件构建私有云；

使用类似 VMware、SmartX、Nutanix 等虚拟化或超融合产品配合 CMP 组件等成熟的商业组件构建私有云。

一个有趣的现象是，由于 HCI 架构为私有云带来的诸多优势，方式 1、2 也都衍生了基于超融合架构的落地方案，以下逐一介绍。

公有云移植构建私有云

将公有云移植到企业数据中心，方案最大的优势是它来自于公有云成功经验，并经过长时间，大规模营运的考验，拥有比较全面的功能，以 AWS 为例展示其落地方案及架构。

AWS 以 EC2 （Elastic Compute）服务为核心提供虚拟计算能力，

S3（对象存储）和 EBS（块存储）等服务提供虚拟存储能力，由 VPC 等网络服务提供虚拟网络能力，以及包括其他安全及管理工具共同构建 IaaS 层。在 PaaS 层也有非常丰富的解决方案，在这里不再一一赘述。AWS 的私有云方案基本上就是按照 AWS 标准， 包括硬件、软件，甚至运营整体交付到企业用户数据中心里面，这类方案比较明显的特征是非常依赖公有云供应商的自有生态。

近几年，AWS、Azure 等公有云供应商，在落地私有云的基础架构方案时也推出了类似如 AWS Outpost、Azure Stack HCI 等超融合架构进行交付。

Azure Stack HCI Solution

这些方案的优势是可以在一家厂商获得从私有到公有云的统一方案和服务，但也存在诸如以下弊端：
1产品封闭，例如Azure Stack HCI 只能支持Hyper-v虚拟平台，并且无法形成多云方案；
2前期投入大且完全新建，对原有VMware等系统无法管理。

开源软件构建私有云

使用开源软件构建私有云，实际上利用多个开源软件分别完成 IaaS、PaaS等各层的构建。这种方案的重点依然在 IaaS 层构建之上，其中  OpenStack 是无疑是最热门的开源 IaaS 平台之一，以下是以 OpenStack 为中心构建私有云的架构图。

由于 OpenStack 本质上是一个 IaaS 的框架，需要结合其他的软件才能完成 IaaS 层的构建 ，通过下图展示 OpenStack 方案的组成。

通过上图可以看到 ：

1OpenStack 本身不直接提供服务虚拟化、存储、网络等功能。

2OpenStack Nova 计算组件负责对接 Hypervisor 软件，如：KVM、VMware vSphere、XenServer 等，实际上由 Hypervisor 提供服务器虚拟化功能。

3 存储方面可能选择的方案包括 SDS、传统集中式存储等。

目前，市场上同样出现了基于 Openstack、KVM、Ceph 等开源产品整合的超融合方案，基于开源的方案可以快速从社区获得最新的功能，但以超融合产品交付存在着诸多问题：
1Openstack 架构复杂、大量模块在超融合中并不需要，商用程度差，且计算资源要求高；
2基于开源的Ceph同样模块和代码复杂，服务商对产品核心问题无法有效支持，且Ceph对计算资源消耗高较高，IO密集型场景性能也表现欠佳；
3此类超融合方案一般对VMWare都无法有效支持。
因此，此类方案实际上无法真正达到超融合产品简单、稳定、高效、开放等特点。

使用成熟的商用生态打造私有云

使用商用生态组件打造私有云，其优点是方案经过来自不同行业的实践验证、并且能获得来自厂商的持续的服务与支持。另外，基于这种模式用户可以采取逐步扩展与完善组件的策略来完成私有云的构建，通过这种模式实现私有云切换的代价是最小的。

在资源池的构建上方式上，以往 VMware vSpere 、FC 网络、FC SAN 存储传统三层式架构占据统治地位，但超融合方案正在越来越多地替换原有的架构。VMware、SmartX、等主流超融合厂商配合成熟的商用 CMP 产品都提供了诸多基于超融合架构的私有云案例。相比于以上两种方案，该落地方案具有独特的特点：

1相比于公有云厂商以及全栈的私有云方案，该方案具备更好的开放性，更灵活轻量；

2 相比于基于的开源产品，该方案稳定简单，具备真正“生产就绪“能力。

众所周知，java在处理数据量比较大的时候，加载到内存必然会导致内存溢出，而在一些数据处理中我们不得不去处理海量数据，在做数据处理中，我们常见的手段是分解，压缩，并行，临时文件等方法;例如，我们要将数据库(不论是什么数据库)的数据导出到一个文件，一般是Excel或文本格式的CSV;对于Excel来讲，对于POI和JXL的接口，你很多时候没有法去控制内存什么时候向磁盘写入，很恶心，而且这些API在内存构造的对象大小将比数据原有的大小要大很多倍数，所以你不得不去拆分Excel，还好，POI开始意识到这个问题，在384的版本后，开始提供cache的行数，提供了SXSSFWorkbook的接口，可以设置在内存中的行数，不过可惜的是，他当你超过这个行数，每添加一行，它就将相对行数前面的一行写入磁盘(如你设置2000行的话，当你写第20001行的时候，他会将第一行写入磁盘)，其实这个时候他些的临时文件，以至于不消耗内存，不过这样你会发现，刷磁盘的频率会非常高，我们的确不想这样，因为我们想让他达到一个范围一次性将数据刷如磁盘，比如一次刷1M之类的做法，可惜现在还没有这种API，很痛苦，我自己做过测试，通过写小的Excel比使用目前提供刷磁盘的API来写大文件，效率要高一些，而且这样如果访问的人稍微多一些磁盘IO可能会扛不住，因为IO资源是非常有限的，所以还是拆文件才是上策;而当我们写CSV，也就是文本类型的文件，我们很多时候是可以自己控制的，不过你不要用CSV自己提供的API，也是不太可控的，CSV本身就是文本文件，你按照文本格式写入即可被CSV识别出来;如何写入呢？下面来说说。。。在处理数据层面，如从数据库中读取数据，生成本地文件，写代码为了方便，我们未必要1M怎么来处理，这个交给底层的驱动程序去拆分，对于我们的程序来讲我们认为它是连续写即可;我们比如想将一个1000W数据的数据库表，导出到文件;此时，你要么进行分页，oracle当然用三层包装即可，mysql用limit，不过分页每次都会新的查询，而且随着翻页，会越来越慢，其实我们想拿到一个句柄，然后向下游动，编译一部分数据(如10000行)将写文件一次(写文件细节不多说了，这个是最基本的)，需要注意的时候每次buffer的数据，在用outputstream写入的时候，最好flush一下，将缓冲区清空下;接下来，执行一个没有where条件的SQL，会不会将内存撑爆？是的，这个问题我们值得去思考下，通过API发现可以对SQL进行一些 *** 作，例如，通过：PreparedStatementstatement=connectionprepareStatement(sql)，这是默认得到的预编译，还可以通过设置：PreparedStatementstatement=connectionprepareStatement(sql，ResultSetTYPE_FORWARD_ONLY，ResultSetCONCUR_READ_ONLY);来设置游标的方式，以至于游标不是将数据直接cache到本地内存，然后通过设置statementsetFetchSize(200);设置游标每次遍历的大小;OK，这个其实我用过，oracle用了和没用没区别，因为oracle的jdbcAPI默认就是不会将数据cache到java的内存中的，而mysql里头设置根本无效，我上面说了一堆废话，呵呵，我只是想说，java提供的标准API也未必有效，很多时候要看厂商的实现机制，还有这个设置是很多网上说有效的，但是这纯属抄袭;对于oracle上面说了不用关心，他本身就不是cache到内存，所以java内存不会导致什么问题，如果是mysql，首先必须使用5以上的版本，然后在连接参数上加上useCursorFetch=true这个参数，至于游标大小可以通过连接参数上加上：defaultFetchSize=1000来设置，例如：jdbc：mysql：//xxxxxxxxxxxx：3306/abc？zeroDateTimeconvertToNull&useCursorFetch=true&defaultFetchSize=1000上次被这个问题纠结了很久(mysql的数据老导致程序内存膨胀，并行2个直接系统就宕了)，还去看了很多源码才发现奇迹竟然在这里，最后经过mysql文档的确认，然后进行测试，并行多个，而且数据量都是500W以上的，都不会导致内存膨胀，GC一切正常，这个问题终于完结了。我们再聊聊其他的，数据拆分和合并，当数据文件多的时候我们想合并，当文件太大想要拆分，合并和拆分的过程也会遇到类似的问题，还好，这个在我们可控制的范围内，如果文件中的数据最终是可以组织的，那么在拆分和合并的时候，此时就不要按照数据逻辑行数来做了，因为行数最终你需要解释数据本身来判定，但是只是做拆分是没有必要的，你需要的是做二进制处理，在这个二进制处理过程，你要注意了，和平时read文件不要使用一样的方式，平时大多对一个文件读取只是用一次read *** 作，如果对于大文件内存肯定直接挂掉了，不用多说，你此时因该每次读取一个可控范围的数据，read方法提供了重载的offset和length的范围，这个在循环过程中自己可以计算出来，写入大文件和上面一样，不要读取到一定程序就要通过写入流flush到磁盘;其实对于小数据量的处理在现代的NIO技术的中也有用到，例如多个终端同时请求一个大文件下载，例如视频下载吧，在常规的情况下，如果用java的容器来处理，一般会发生两种情况：其一为内存溢出，因为每个请求都要加载一个文件大小的内存甚至于，因为java包装的时候会产生很多其他的内存开销，如果使用二进制会产生得少一些，而且在经过输入输出流的过程中还会经历几次内存拷贝，当然如果有你类似nginx之类的中间件，那么你可以通过send_file模式发送出去，但是如果你要用程序来处理的时候，内存除非你足够大，但是java内存再大也会有GC的时候，如果你内存真的很大，GC的时候死定了，当然这个地方也可以考虑自己通过直接内存的调用和释放来实现，不过要求剩余的物理内存也足够大才行，那么足够大是多大呢？这个不好说，要看文件本身的大小和访问的频率;其二为假如内存足够大，无限制大，那么此时的限制就是线程，传统的IO模型是线程是一个请求一个线程，这个线程从主线程从线程池中分配后，就开始工作，经过你的Context包装、Filter、拦截器、业务代码各个层次和业务逻辑、访问数据库、访问文件、渲染结果等等，其实整个过程线程都是被挂住的，所以这部分资源非常有限，而且如果是大文件 *** 作是属于IO密集型的 *** 作，大量的CPU时间是空余的，方法最直接当然是增加线程数来控制，当然内存足够大也有足够的空间来申请线程池，不过一般来讲一个进程的线程池一般会受到限制也不建议太多的，而在有限的系统资源下，要提高性能，我们开始有了newIO技术，也就是NIO技术，新版的里面又有了AIO技术，NIO只能算是异步IO，但是在中间读写过程仍然是阻塞的(也就是在真正的读写过程，但是不会去关心中途的响应)，还未做到真正的异步IO，在监听connect的时候他是不需要很多线程参与的，有单独的线程去处理，连接也又传统的socket变成了selector，对于不需要进行数据处理的是无需分配线程处理的;而AIO通过了一种所谓的回调注册来完成，当然还需要OS的支持，当会掉的时候会去分配线程，目前还不是很成熟，性能最多和NIO吃平，不过随着技术发展，AIO必然会超越NIO，目前谷歌V8虚拟机引擎所驱动的nodejs就是类似的模式，有关这种技术不是本文的说明重点;将上面两者结合起来就是要解决大文件，还要并行度，最土的方法是将文件每次请求的大小降低到一定程度，如8K(这个大小是经过测试后网络传输较为适宜的大小，本地读取文件并不需要这么小)，如果再做深入一些，可以做一定程度的cache，将多个请求的一样的文件，cache在内存或分布式缓存中，你不用将整个文件cache在内存中，将近期使用的cache几秒左右即可，或你可以采用一些热点的算法来配合;类似迅雷下载的断点传送中(不过迅雷的网络协议不太一样)，它在处理下载数据的时候未必是连续的，只要最终能合并即可，在服务器端可以反过来，谁正好需要这块的数据，就给它就可以;才用NIO后，可以支持很大的连接和并发，本地通过NIO做socket连接测试，100个终端同时请求一个线程的服务器，正常的WEB应用是第一个文件没有发送完成，第二个请求要么等待，要么超时，要么直接拒绝得不到连接，改成NIO后此时100个请求都能连接上服务器端，服务端只需要1个线程来处理数据就可以，将很多数据传递给这些连接请求资源，每次读取一部分数据传递出去，不过可以计算的是，在总体长连接传输过程中总体效率并不会提升，只是相对相应和所开销的内存得到量化控制，这就是技术的魅力，也许不要太多的算法，不过你得懂他。类似的数据处理还有很多，有些时候还会将就效率问题，比如在HBase的文件拆分和合并过程中，要不影响线上业务是比较难的事情，很多问题值得我们去研究场景，因为不同的场景有不同的方法去解决，但是大同小异，明白思想和方法，明白内存和体系架构，明白你所面临的是沈阳的场景，只是细节上改变可以带来惊人的效果。

---