站务联系
弹指一挥间从事游戏相关的开发工作早已十多年。在开发了六年多几经坎坷差点舍弃的
项目也迎来了1.0版本的上线。虽然演示版本以及集群功能早在17年1月份就
开发完毕但更改跟建立计划现在依旧排的满满当当，导致1.0上线一推再推迄今依然不甚满
意。
说起最初开发这个项目的本意如同那盏雾霭中的红光使人激动不已，在此也希望由于我
的执着而被伤害的人幸福。以下引到《thegreat gatsby》
“Gatsby believed in the green light, the orgastic future that year byyear
recedes before us.It eluded us then, but that's no matter--tomorrow we will run
faster, stretch outour arms farther.... And one fine morning---- So we beat on,
boats against thecurrent, borne back ceaselessly into the past.”
或许人们还没有意识到，游戏服务器将是继计算机操作系统以后，现代软件工程中最复
杂的估算系统。经过wow跟无数游戏公司的崛起使这个系统得到了迅猛发展。最初的游戏服
务器引擎可以上溯至1992年的mudos。这是一个简略的文字对话系统，但可以多人在线。
因为交互简略对功耗要求不高，普通的服务器就可以支持上万人同时在线。在接下来的这些
年时间内，mudos代表着游戏服务器引擎的精典原形。我们可以把这类服务器引擎亦称为经
典游戏服务器引擎。
经典的游戏服务器引擎的核心建立就逻辑服务器，所谓逻辑服务器就是对用户的键入数
据进行处理，产生输出数据返回给用户。见图1
因为mysql数据库写入跟加载得速率不快，数据操作须要等候时间的过长，在磁盘数据
因为服务器崩溃的主要成因是显存表针的泄露，为了解决崩溃的问题形成了各类脚本语
言取代指针型语言。可服务器功能越来越多，越来越复杂，崩溃，卡死，内存泄漏象逻辑
服务器上空的阴云挥之不去。
服务器第一要求是稳定，但依然不能阻挡人们对服务器功能无尽的渴望。于是形成了新
的看法分拆逻辑服务器扩充服务器承载能力。见右图4
挥舞着匕首。在某一瞬间一个看法踏入脑部，为什么不能一个服务器就把一个玩家的所有请
求都处理好呢？这样犹如给每位玩家搭载了一个专职的秘书，任何需求都还给秘书去做，涉
及跟其他玩家勾通的事情，秘书会找到其他玩家的秘书进行勾通。见右图5
到这儿精典游戏服务器发展至了颠峰,其数据处理的复杂度远低于同期的任何服务器系
统。
为何说其处理数据的复杂度多于同期的任何服务器系统，因为同期的服务器系统都是服
务于现实生活，而游戏服务器是服务于纯粹的虚拟世界。例如说寄送物品这个事情，在游戏
服务器就是一个指令，也许在聊天过程，也许在战斗过程。没有现实中寄送的等候过程，需
要游戏服务器立即就返回。并且可以发生在任何功能服务器上。例如聊天的过程中给对方一
个物品，这在现实中是绝对不或许发生的。
因为功能跟功能之间不是绝对的独立，经典的服务器系统随着功能的界定越来越细游戏服务器，每
个服务器之间的通讯就越来越复杂。这样使人联想至了复杂低效的士族系统。有大量的恳求
都耗费在了通讯跟复杂的勾通上，而且每位开发人员要提防奕奕，不知道那个逻辑会搭错崩
溃掉。
在六年前的一个夜间，看着眼前这越来越庞大复杂的怪兽，我象极了唐吉坷德奔向风车
挥舞着匕首。在某一瞬间一个看法踏入脑部，为什么不能一个服务器就把一个玩家的所有请
求都处理好呢？这样犹如给每位玩家搭载了一个专职的秘书，任何需求都还给秘书去做，涉
及跟其他玩家勾通的事情，秘书会找到其他玩家的秘书进行勾通。见右图5
这个设计方式称为“one objectdo something”，这个设计方式第一个弊端就是增加了硬件开发的难度。在按功能分割的服务器中，每个服务器上都是不同功能的代码。每个功能之间的联系是一种耦合关系。存在耦合关系的代码就存在不确定性的风险，每个功能固然单独更改都没有问题，但在一起相互配合才会出现各类不确定性。Starrydb的“one object do something”的方式中服务器C跟服务器D使用代码是一样的。这种买卖关系无论是A向B订购还是B向A订购过程都是一样的。这样高内聚的安装工程在开发调试的过程中不容易出现错误。提高了开发速率跟硬件品质，降低了软件工程的不确定性。
Starrydb的“one objectdo something”的方式的另一个弊端就是极大的便捷服务器的扩充。因为每位服务器的配置都是一样的，当用户提高的时侯只要添加新的服务器，就可以满足数据处理的需求。传统的精典服务器构架，按功能界定服务器结构的形式都会出现难题，功能不能经常不断细分。见右图6
限制用户社交速率的状况下承载能力与cpu数目成正相关，直到抵达单个cpu处理上
限。假设单个cpu处理上限是10人，服务器至10以后处理能力会随之衰退出现抵制服务。
见右图8：
在精典的游戏服务器引擎中，按功能界定的模块分别运行在不同的服务器上。这显然也
可以称谓为分布式，但我们晓得分拆不同功能至不同的软件上运行，需要对原有硬件系统进
行巨大的改动。这种扩充不是线性的而是阶梯性的。见右图10：
我们见到想要通过添加服务器达到无限扩充应当要遵守基本的物理准则。限制单位时间
处理的数量或则提高数据交换的频次。这个结果似乎使人失望，但从另一个方面也使我们
看到分布式服务器无限扩充的可能性。到这儿我们有了一个评价游戏服务器引擎的物理标准。
那么只要遵守这个标准写出一个稳定，高性能，可扩充的游戏服务器引擎就成为或许。
见右图11:
稳定是游戏服务器引擎的基石。这个稳定的涵义只是尽可能的降低耦合性，让估算运行
在最简略靠谱的环境内。只有尽可能把数据的估算储存都置于同一台计算机上。减少每位计
算机节点间的数据交换。用最快的时间处理完每条数据恳求。这就是数据跟估算越逾效率越
高系统越稳定。经典的游戏服务器引擎的数据被保存有三份。逻辑服务器一份，数据缓存一
份，硬盘数据库一份。在系统运行过程中确认数据一致性跟完整性的工作就消耗了大半。而
且出现掉线跟宕机，很容易破坏数据的一致性跟完整性。是潜在破坏服务器稳定性的诱因。
高性能是服务器稳定以后追求的第二个目标。为了无限的接近软件处理的上限，不耗费
硬件资源。这其实跟分布式系统是互相矛盾的，因为分布式系统就是要把数据跟任务分配给
集群内的每台服务器，分配的过程必定带给耗损。但也不能起身把高性能寄寓在优化开发库
上。因为我们晓得服务器受限于cpu的处理能力。开发库中添加功能都会影响硬件运行效率，
开发库分割功能都会提高数据复制费用。减少硬件开发难度的根本还是加大内聚降低耦合，
减少安装工程的复杂度。
扩展性是游戏服务器引擎追求的最高目标，虽然英语准则告诉我们这么的追求对于分布
式系统有限制。但确立在线数量跟功能的扩充与服务器软件总量的线性关系还是十分的必要。
能保障数据安全的并不是starrydb,starrydb也是一个系统功能的实现，对于数据安全
我觉得任何系统都是不靠谱的。Node可以宕机，link可掉线只要假定软件是不靠谱的，那
么系统就是不靠谱的。我们就该想办法用系统靠谱的一方面去填补不靠谱的一方面。就现在
看真正能靠谱的就是明晰假设不靠谱的前提下，在数据逻辑上做到相互检测彼此校准。实现
操作数据逻辑的任务可重入可检测。
任务的可重入是检测数据完整性一致性的一种安全写法，可重入的意思是任务的相关数据是记录式的，例如存入1块钱，那么中行的记录是存入1块钱，当前余额为2块钱。对应就是两条记录，当前存入的数据，累加的数据。累加数据是为了便于调用。那么对应key-value就应该是3条数据。
Key： 任务号 ，value： 顺序id;
任务号是客户端生成次序id是服务器生成的由小到大的顺序号,方便查询最后的任务。
Key ：顺序id ，value： 加减值；
当前次序id加减的数值。
Key ：顺序id ，value ：加减以后的产值；
根据上一个id估算出的产值便于查询。
可重入的意识是可以拿客户端的任务号再次检测当前任务是否早已形成次序id是否早已写入正确的加减值，是否早已形成正确的总额，如果没有就再次形成记录。这样只要客户端的任务号不变同一个任务不会形成多次重复操作，保证数据的一致性跟完整性。
如果任何状况掉线造成任务中断，这个交易也会记录在册。
在用户界面都会显示这条交易失败。可以由发起方再次自动继续交易，直到交易完成。一个正常的交易有中断，失败，成功3种状态。
这个系统对崩溃的规避举措，如同是单向交易扣钱的同时荣获物品，或则扣物品的同时荣获钱。假设两个对象的数据都同一台计算机，这个计算机出现回滚。那么两个对象的交易数据同时消失，这笔交易就不存在。即不损失钱也不会被扣掉物品。如果两个对象的数据分别在不同的计算机，其中一个计算机的运行失败。每个用户都是扣除钱荣获物品，或则扣除物品得到钱，相当收支平衡。
对于双向交易的A对象扣钱，B对象荣获钱。如果A所在服务器回滚至没有扣钱，那么B将陡然荣获一笔钱。那么A在退款以后要等候一段时间，服务器写入磁盘成功以后，这段时间恐怕10秒至30秒。然后再发起给B对象荣获金钱的操作。这样假如A没有将数据写入硬碟时，服务器宕机回滚数据，B也不会荣获金钱。A可以再次发起步骤完成转帐。
到这儿我们有了一个分布式的，扁平开发复杂度的，可重入数据的，可线形扩充的游戏
服务器引擎。欢迎您关注及其未来无限或许的发展。有建议跟合作意向可以
发邮件至。在此谢谢支持我的家人和忠诚的阿旺跟小白。
来自。
