105711人阅读
My Programmes（15）
&&& DirectX修复工具从发布至今已经过去整整一年的时间了，通过大家的反馈及交流我发现有一部分人并不清楚DirectX修复工具到底可以解决什么问题。虽说网上有众多网友的解释，但毕竟不是很全面，都只介绍了某一方面的应用。因此，在这里，就由作者为大家全面地阐释一下本程序的用途。
本程序可以解决的问题。
No.1 应用程序无法正常启动(0xc000007b)。请单击“确定”关闭应用程序。
修复时推荐使用版本：
解决概率：大于95%（使用V3.0及以上版本）
&&& 由于本程序主要针对0xc000007b问题设计，因此把这一条放在了第一位。从目前的反馈情况来看，使用增强版修复该问题时，解决概率可以达到95%以上（仅限使用V3.0及以上版本，使用低版本可能无法达到这个成功概率）。至于剩下的5%之所以不能解决，是由于有些软件不仅需要DirectX的支持，还需要其他组件的支持，而这些组件异常导致的0xc000007b问题本程序无法解决。还有很少的一部分人遇到了蓝屏问题，其提示代码为0x0000007b，这种情况通常都是由于硬盘设置造成的，因此本程序也无法解决。
No.2 无法启动此程序，因为计算机中丢失 d3dx9_42.dll。尝试重新安装该程序以解决此问题。
修复时推荐使用版本：
解决概率：大于99%
&&& 这个问题是新系统普遍存在的问题。不管是正版系统还是盗版系统由于默认都未包含DirectX相关组件，因此在首次运行大型游戏时普遍都会遇到这个问题。由于造成这个问题的机理简单，解决办法简单，因此针对该问题的解决概率也较高。除了标题中提到的d3dx9_42.dll文件外，类似的还有以下这些文件。注意，本程序只能解决在以下列表中包含的文件所遇到的问题：d3dcompiler_33.dll、d3dcompiler_34.dll、d3dcompiler_35.dll、d3dcompiler_36.dll、d3dcompiler_37.dll、d3dcompiler_38.dll、d3dcompiler_39.dll、d3dcompiler_40.dll、d3dcompiler_41.dll、d3dcompiler_42.dll、d3dcompiler_43.dll、d3dcsx_42.dll、d3dcsx_43.dll、d3dx9_24.dll、d3dx9_25.dll、d3dx9_26.dll、d3dx9_27.dll、d3dx9_28.dll、d3dx9_29.dll、d3dx9_30.dll、d3dx9_31.dll、d3dx9_32.dll、d3dx9_33.dll、d3dx9_34.dll、d3dx9_35.dll、d3dx9_36.dll、d3dx9_37.dll、d3dx9_38.dll、d3dx9_39.dll、d3dx9_40.dll、d3dx9_41.dll、d3dx9_42.dll、d3dx9_43.dll、d3dx10.dll、d3dx10_33.dll、d3dx10_34.dll、d3dx10_35.dll、d3dx10_36.dll、d3dx10_37.dll、d3dx10_38.dll、d3dx10_39.dll、d3dx10_40.dll、d3dx10_41.dll、d3dx10_42.dll、d3dx10_43.dll、d3dx11_42.dll、d3dx11_43.dll、X3DAudio1_0.dll、X3DAudio1_1.dll、X3DAudio1_2.dll、X3DAudio1_3.dll、X3DAudio1_4.dll、X3DAudio1_5.dll、X3DAudio1_6.dll、X3DAudio1_7.dll、xactengine2_0.dll、xactengine2_1.dll、xactengine2_2.dll、xactengine2_3.dll、xactengine2_4.dll、xactengine2_5.dll、xactengine2_6.dll、xactengine2_7.dll、xactengine2_8.dll、xactengine2_9.dll、xactengine2_10.dll、xactengine3_0.dll、xactengine3_1.dll、xactengine3_2.dll、xactengine3_3.dll、xactengine3_4.dll、xactengine3_5.dll、xactengine3_6.dll、xactengine3_7.dll、XAPOFX1_0.dll、XAPOFX1_1.dll、XAPOFX1_2.dll、XAPOFX1_3.dll、XAPOFX1_4.dll、XAPOFX1_5.dll、XAudio2_0.dll、XAudio2_1.dll、XAudio2_2.dll、XAudio2_3.dll、XAudio2_4.dll、XAudio2_5.dll、XAudio2_6.dll、XAudio2_7.dll、xinput1_1.dll、xinput1_2.dll、xinput1_3.dll、xinput9_1_0.dll(WindowsXP)、atl100.dll、mfc100.dll、mfc100chs.dll、mfc100cht.dll、mfc100deu.dll、mfc100enu.dll、mfc100esn.dll、mfc100fra.dll、mfc100ita.dll、mfc100jpn.dll、mfc100kor.dll、mfc100rus.dll、mfc100u.dll、mfcm100.dll、mfcm100u.dll、msvcp100.dll、msvcr100.dll、vcomp100.dll、atl110.dll、mfc110.dll、mfc110chs.dll、mfc110cht.dll、mfc110deu.dll、mfc110enu.dll、mfc110esn.dll、mfc110fra.dll、mfc110ita.dll、mfc110jpn.dll、mfc110kor.dll、mfc110rus.dll、mfc110u.dll、mfcm110.dll、mfcm110u.dll、msvcp110.dll、msvcr110.dll、vccorlib110.dll、vcamp110.dll、vcomp110.dll、MSVCRTD.dll、mfc120.dll、mfc120chs.dll、mfc120cht.dll、mfc120deu.dll、mfc120enu.dll、mfc120esn.dll、mfc120fra.dll、mfc120ita.dll、mfc120jpn.dll、mfc120kor.dll、mfc120rus.dll、mfc120u.dll、mfcm120.dll、mfcm120u.dll、msvcp120.dll、msvcr120.dll、vccorlib120.dll、vcamp120.dll、vcomp120.dll
No.3 C:\Windows\system32\d3dx9_42.dll没有被指定在Windows上运行，或者它包含错误。请尝试使用原始安装媒体重新安装程序，或联系您的系统管理员或软件供应商以获取支持。
修复时推荐使用版本：
解决概率：大于99%
&&& 这个问题多是由于用户自行修复缺失的文件后产生的。该问题由于机理简单因此也较容易解决。除了标题中提到的d3dx9_42.dll文件外，类似的还有以下这些文件。注意，本程序只能解决在以下列表中包含的文件所遇到的问题（列表见No.2的列表）。
No.4 发生了一个内部系统错误。请参阅您的Windows文件夹中的DXError.log和Directx.log来确定问题。
修复时推荐使用版本：
解决概率： 95%
&&& 这个问题也是存在比较广泛的，即使是正版的全新系统也时有发生。产生这个问题的原因是程序自身的BUG造成的，而是用本程序修复可以绕过这个问题。这里要说明一下，使用本程序修复成功后，相当于安装了微软提供的DirectX安装包，这时就没有必要再安装微软提供的DirectX安装包了。如果这时再安装微软提供的DirectX安装包，可能仍然会出现内部系统错误，但是用户可以忽略这条提示。
No.5 由于应用程序配置不正确，应用程序未能启动。重新安装应用程序可能会纠正这个问题。
修复时使用版本：必须使用
解决概率：80%
&&& 这个问题基本上都出现在Windows XP操作系统上。这个问题其实和DirectX没有什么关系，而绝大多数情况是由于c++异常造成的。由于本程序的增强版可以修复c++，因此使用本程序的增强版可以解决这个问题。
No.6 应用程序无法正常启动(0xc00000ba)。请单击“确定”关闭应用程序。
修复时推荐使用版本：
解决概率：50%
&&& 这个问题出现在个别的游戏上。如果是由于DirectX组件的异常造成的该问题，本程序可以正常修复，而如果是由于其他组件（如binkw32.dll等）异常造成的该问题，本程序则无法修复。因此说修复能否成功还要看具体情况。
No.7 部分游戏没有声音。
修复时推荐使用版本：、
解决概率：50%
&&& 部分游戏（如梦幻之星OL2、PSO2及最新的看门狗Watch dogs等）可以正常进入，但是没有声音，而系统声音是正常的。这个问题是由于DirectX中负责音频相关的组件异常或未注册造成的。这个问题通常情况下往往都是极个别的文件异常，因此没必要下载完整版的DirectX修复工具进行修复，只需下载在线修复版进行快速修复即可。
No.8 部分游戏双击点开后闪退。
修复时推荐使用版本：
解决概率：40%
&&& 某些游戏（如真三国无双6）点开后闪退，或者压根没反应。造成这种情况的原因有很多，其中一个很可能的原因就是c++有问题。由于c++版本众多，极有可能造成玩家因安装了错误的版本而不能进入游戏。如果是这种情况，使用增强版修复后即可进入游戏。如果修复完成后仍然会闪退，则可能是由于游戏本身或破解补丁有问题、显卡驱动有问题或硬件配置不够所致，玩家应从这3方面予以考虑。
No.9 Grand Theft Auto IV已停止工作 出现了一个问题，导致程序停止正常工作。请关闭该程序。
修复时推荐使用版本：
解决概率：33%
& & 某些游戏（如GTA &IV等）点开后会出现程序停止工作的错误。造成这种情况的原因大致有3种：第一，DirectX有问题；第二，游戏本身或破解补丁有问题；第三，显卡驱动有问题。对于DirectX有问题的用户，使用本程序进行修复即可进入游戏。而对于上述第二种情况的用户建议重新下载游戏或更换破解补丁；对于上述第三种情况的用户则建议到显卡官网下载最新的显卡驱动并安装。本项内容中只是拿GTA 4作一个例子，其他游戏如果出现同样提示也适用于本条内容。&
No.10 部分非主流游戏所遇到的DirectX的问题。
修复时推荐使用版本：
解决概率：较低
&&& 一些人玩的非主流游戏，有时也会遇到DirectX问题而无法进入。由于这些游戏的提示比较特殊，不具备代表性，因此不在这里详细介绍。只要你的游戏进不去，并且提示的对话框里包含“DirectX”等字样，都可以尝试用本程序进行修复。当然，对于非主流游戏的修复成功率要远低于主流游戏。
本程序无法解决的问题。
No.1 魔兽争霸III不能初始化DirectX。请确保你的系统拥有DirectX8.1或者更高的版本以及你的显示驱动程序是最新的。DirectX也可以在你的魔兽争霸3安装盘上找到。
&&& 这是一个极具迷惑性的提示（不仅会出现在war3中，其他一些游戏也会出现），往往大多数人看到这条提示后会开始修复自己的DirectX，但发现无论如何修复更新（包括用本程序进行修复）仍然会有这条提示。其实这个问题并不是由于DirectX有问题，而是你的显卡驱动有问题！至于显卡驱动为什么会有问题原因多种多样在此不想详谈，大家要作的只是对应自己的显卡型号，到显卡的官网下载最新的显卡驱动并安装即可。通常安装完显卡驱动这个问题也就会迎刃而解了，如果大家还不放心，可以打开“DirectX诊断工具”（在本程序的工具菜单里），找到“显示”选项卡，这时你会看到下面DirectX功能中的“DirectDraw加速”、“Direct3D加速”、“AGP纹理加速”都已处于已启用状态，这说明你的显卡驱动已经正常工作了。
No.2 “DirectDraw加速”、“Direct3D加速”、“AGP纹理加速”不可用。
&&& 其实这个问题和DirectX本身没有什么关系，因此即使用本程序修复后也无法解决。这个问题是由于显卡驱动有问题造成的。请大家对应自己的显卡型号，到显卡的官网下载最新的显卡驱动并安装即可。通常安装完正确的显卡驱动后这些内容都会自动变为已启用，这时就可以正常的玩游戏了。
No.3 “0xXXXXXXXX”指令引用的”0xXXXXXXXX”内存。该内存不能为”read”（或written）。要终止程序，请单击“确定”。要调试程序，请单击“取消”。
&&& 造成这个问题的原因实在是数不胜数——太多了。但是不管怎么说，由于DirectX有问题造成这个错误还比较少见。因此，如果大家遇到这个错误，基本不用考虑DirectX的问题了，从其他方面进行考虑。当然，由于DirectX没有问题，本程序也无法解决这个问题。
No.4 一些奇怪的疑难杂症。
&&& 系统开机慢，我的电脑图标不见了，上不了网，无法进行系统还原，无法备份文件，设备驱动坏了……本程序根本就不是为这些问题设计的，但是网上有一部分人拿本程序来修复这些问题，因此我在这里也不得不提一下。产生这些问题的原因一般都是系统文件损坏，缺少某些程序，系统被病毒木马感染破坏，某些组件未注册，而跟DirectX基本没有任何关系。如果您用本程序的“注册系统中所有dll文件”功能解决了上述某些问题，那么算您幸运；如果本程序没有解决这些问题那也是很正常的，因为本程序压根就没打算解决这些问题。请不要因此就说本程序无用，给本程序差评。这就好比，不能因为Windows无法杀蟑螂就说Windows是一个很差的操作系统，再厉害的药也得对症才有效。还是希望广大用户能够理解。
&&& 以上就是软件作者对于DirectX修复工具的用途进行的一个比较详尽的介绍，希望对大家有所帮助。人民的力量是无穷的，如果您发现本程序还有其他的用途，可以告诉我，以便和大家一起分享。如果大家有什么好的意见或者建议也欢迎和我交流，对大家的理解与支持深表感谢。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：4228001次
积分：4900
积分：4900
排名：第5530名
原创：31篇
评论：1259条
(1)(1)(1)(1)(1)(1)(4)(1)(1)(1)(1)(1)(2)(2)(1)(1)(1)(1)(1)(2)(3)(1)(1)(1)(2)(1)服务端开发小感 - 文章 - 伯乐在线
& 服务端开发小感
从事服务端开发已经有一些日子了，静下来可以想想和记录些服务端开发的想法了。
服务端开发，特别是Web开发，基本上全是处理HTTP请求的处理。根据具体用途分为两种：Web页面开发和API接口开发。Web页面开发也完全可以看成是API接口开发，只是它的两个主要部分，页面和ajax请求，一个是返回html，另外一个可以返回html，也可以返回其他格式的而已。API接口开发是针对有客户端产品而言的。可能是移动设备，可能是PC应用等。
应用框架一般使用的是LNMP或者LAMP，基本的框架就是前端N台Web服务机 + cgi访问PHP + php访问mysql。
PHP可以看成是C写的一个大型的Web框架，它的优势在于解释型，即时修改即时更新。所以线上代码更新维护成本极低，加之其为web开发几乎是专门定制的一些函数，所以适合用于web开发。相较于java开发web服务，动不动就需要重新编译的痛苦就很知足了。
web服务器现在nginx是越来越多使用，nginx比较apache的优势就在于轻便和静态页面的高并发性能。一般拿到设备先需要考虑下单机可承受的qps大概多少，方法大致就是先只考虑内存，计算同时能开启多少个php-cgi，比如一个4G内存的机器，每个php-fpm大概占用20M内存，所以差不多能开启200个php-cgi进程（一般会留些空余的），每个进程同一个时间只能跑一个php程序，所以假设每个php程序跑0.1s，1s就能处理10个请求，所以单机qps大概会是2000。当然，一般不会开启到这么极致的程度，有几个原因：
1 需要考虑到其他进程使用内存的情况
2 考虑到如果一旦全部内存都使用完了，是否启用swap，如果没有的话，那机器是否就立即当机
3 还需要考虑到CPU和带宽的使用情况。CPU对一些比如加解密，视频转码等操作比较耗时，这个时候如果没有使用队列，那么每个请求的时间就会加长。
文件服务器
一般会要求文件服务器和web服务器分开，分开的意思就是使用不同的域名进行拆分。当然web服务器也是可以当做文件服务器的，但是由于文件服务器需要上传文件，而上传文件是一个非常耗时的工作，即php的一个程序需要停留的时间很长，所以需要将它们分开。一则可以为以后扩展文件服务器提供便利，二则不会导致文件服务影响了正常的web服务。
从文件服务器拆分的理由上看，在运营过程中一些比较占用资源或者特别频繁调用的接口是可以或者应该考虑拆分到不同机器上的。
Web前端机始终要访问持久化的数据的，mysql的使用是最为频繁的。其实所有的web服务说到底都是对数据库进行增删改查的操作。说到性能，数据库的增删改查操作的性能其实就决定了一切。所以对数据库的建表，索引的使用对一个网站来说尤为重要。觉得最有用的几个mysql的技巧有：
1 覆盖索引。就是想办法让查询操作只查索引而不去查表的索引建立方法。建立合适的索引和能只在索引就能找到数据的查询能提高效率。
2 InnoDB表最好能使用自增键，提高插入操作的效率。
3 string类型的变量的存储格式，是使用varchar还是char比较好，曾经有个项目表设计从char到varchar之后的数据库大小差别达到70G和20G的大小…
4 建表的时候需要考虑下以后的分库分表，如果是使用分表，什么是分表键？是否需要反向查询表？
5 甚至当考虑到数据库和Web机器的机房分布，这个设计就更麻烦了…
mysql的建表环节和需求有很大关系。没有明确的需求，表设计一定是不正确的。
数据库支持有可能还是不足够的，那么首先想到的可能就是缓存了。缓存是使用全局缓存？放在web前端机？需要用什么hash算法？用什么缓存？memcache？redis？mysql也有自带缓存，如何查询才能更好命中这个缓存？当数据更新的时候，缓存中的数据是否是脏数据？如何更新数据？
Web页面开发
当需要做一个网站的时候，首先要考虑的是用户量有多少？做一个SNS网站和做一个运营后台网站完全是两个不同的概念。
首先是在页面压力上，SNS网站的qps可能几千上万，而运营后台压力几乎完全可以不用计算。这个就意味着后端的数据库支持不同了。SNS网站可能最常调用的会是好友关系和个人信息的接口，这样的接口是不是需要独立出来处理？这样的请求会很多是重复的，是不是考虑使用中间件或者缓存来减轻对数据库的直接压力呢？运营数据一般使用单表就可以解决的。个人觉得运营中统计的需求是最难做的。首先统计并不是任意的统计要求都可以满足，这个需要和产品讨论需求。其次，统计一般需要使用些访问日志之类的，可能涉及到许多shell脚本。
其实相对于Web开发，API开发是属于被动的。意思就是，由于客户端可能是手机产品，可能是PC产品。往往都是有发布和版本的。这个意味着API接口没法像Web那样为所欲为随时更新代码。它更多需要考虑到各个版本之间的兼容问题。兼容问题在很大程度上会变为加法，永远不会是减法。个人感觉，如果毫无节制地满足需求，随着版本越来越多，你的代码中会越来越多if else，到最后，你的代码就根本无法维护了。然后就会是别人来接手你的工作，踩坑，边骂边重构….API开发是最需要依赖测试的。往往只有测试人员才对各个版本的小改动，小特性如数家珍。
再考虑到非功能配套：
你可能需要对API调用时间进行统计，这样你才明白你的接口表现如何。
你的代码可能还会用到其他机器上的服务，比如curl一个其他服务，这样的情况，最好考虑下错误处理和日志记录。
对于有金钱交易的接口服务，日志处理更是必不可少。
对于一些内部错误，最好不需要直接抛出显示给用户，所以需要使用的最好是白名单错误机制。
接口的加密方式，一般最少是需要有个签名机制的，考虑到加密方法，大致有几种：对称加密和非对称加密。加密的时候就需要考虑到一些情况了，比如手机客户端的用电量等。
如果是给手机开发接口，需要考虑流量问题，图片的规格问题。
框架永远是会变的，不说需求的变化，单就用户量的变化，20w用户和1000w用户的框架一定是不一样的。刚开始的时候你不可能根据1000w的用户量来设计框架来给20w人用。所以一个好的服务端框架一定是随着用户量变化会进行几次大的变化的。
这篇是想到哪写到哪，写到这里发现写不下去了…总之，web服务开发的技巧和小东西还是很多的。有的坑是需要自己踩过才知道痛的。可爱的是，我还在继续踩坑中…
补充下，接口重构几乎是每个服务端开发人员必须经历过的。相较于开发一个新系统，接口重构的难度可以说是翻翻，当然这里的难度也可以理解为难受程度…也会是很锻炼人的一个活。对于重构来说，测试尤为重要，如何有个很好的测试集来保证你的重构的正确性是个难度。
可能感兴趣的话题
重构 简直是令人崩溃的事情 － － 尤其接手的是一个 仅仅可以使用的程序 还需要加功能 － －
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2017 伯乐在线游戏服务端究竟解决了什么问题？
游戏服务端究竟解决了什么问题？
发布时间： 17:45:11
编辑：www.fx114.net
本篇文章主要介绍了"游戏服务端究竟解决了什么问题？"，主要涉及到游戏服务端究竟解决了什么问题？方面的内容，对于游戏服务端究竟解决了什么问题？感兴趣的同学可以参考一下。
1.写在前面
既然是游戏服务端程序员，那博客里至少还是得有一篇跟游戏服务端有关的文章，今天文章主题就关于游戏服务端。写这篇博客之前也挺纠结的，一方面是因为游戏服务端其实不论架构上还是具体一些逻辑模块的构建，都属于非常成熟的技术，举个简单的例子，像端游的多zone/scene/game进程+单全局进程架构，网上随便一搜能搜出来几十篇内容差不多的。另一方面是因为中国特色MMO基本上把服务端程序员整成了业务逻辑狗，很多明星团队的业务狗基本上从入职第一天开始就成天写lua、写python，纯写lua/python，你是完全无法辨别一个程序员的vision强弱区别的，结果论资排辈导致vision弱的上去了。（也许vision强的出去创业了？）你就会发现，游戏服务端的话语权到底是被谁占据了。
在我看来，游戏服务端程序员容易陷入两个误区：
第一，游戏服务端实际上要解决的并不是性能问题。一方面，即使是千人同屏的端游（姑且不论这千人同屏是不是一个中国特色的伪需求，反正我是没法将千人同屏跟游戏乐趣联系在一起的），其服务端如果进程划分得当，一个场景进程也至多只有千级别entity的压力，性能问题退化为了逻辑狗的业务素养问题。另一方面，现在端游MOBA和手游时代，开房间式场景同步已经成为主流，各种逻辑狗进化来的资深人士不需要也没必要将性能挂在嘴边了。
第二，大部分游戏服务端所谓框架的定位有误。服务端框架的设计有好有坏，判断一个设计好不好没有普适统一的标准，但是判断一个设计烂不烂一定是存在一个标准线的。简单列举几种烂设计：
烂设计基础版本。帮你定义好框架中的几种角色，你要么全盘接受，要么全不接受，不存在中间状态。但是，提供一种简单的通信机制，以及外部与框架通信的clientLib。或者能让你定制开发其中一种角色，可以写外部driver。这样，虽然架构丑一点，至少还能提供一定程度的扩展性。
烂设计进阶版本。除了满足基础版本的定义之外，还具有一些额外的烂特点：框架中的角色定义的特别二逼，举个例子，基础版本的烂设计在角色定义上可能只是大概区分了Db代理进程、Gate进程、逻辑进程，但是进阶版本会对逻辑进程进行区分，定义了不同的逻辑进程角色。这意味着什么？意味着我想写一个简单的单逻辑进程游戏是没办法用这个框架的，因为框架默认就集成进来了一堆莫名其妙的东西。更有甚者，我想要添加一种角色，是需要动手去改框架的。
说实话，正是由于这类设计的存在，我在看到类似于“游戏服务端技术含量不高”这类论断的时候，总感觉辩无可辩，因为就这两种设计而言，我甚至除了代码逻辑复杂度之外看不到跟本科毕设级别的游戏服务器有什么区别。
不知道算是不幸还是幸运，前段时间亲眼目睹了上述提到的某种设计的从无到有的过程。当然，今天写此文的目的不是为了将这种设计批判一番，每种设计的诞生都是与各种因素相关的，我们不能站在上帝视角去评判这个过程。今天写此文，是希望对自己这整整一年半的游戏服务端编码历程中的一些所思所惑做个整理，希望能带各位看官从另一个思路看游戏服务端。
&2.游戏服务端究竟解决了什么问题？
从定义问题开始，简单直接地说，一套游戏服务端开发框架应该具有下面两种能力：
下面就从这两点来展开这篇文章。
3 消息pipeline
3.1 经典消息pipeline
3.1.1 场景同步
当讨论到游戏服务端的时候，我们首先想到的会是什么？要回答这个问题，我们需要从游戏服务端的需求起源说起。
游戏对服务端的需求起源应该有两个：
第一种需求长盛不衰，一方面是console游戏特别适合这一套，另一方面是最近几年手游起来了，碎片化的PVE玩法+开房间式同步PVP玩法也得到验证，毕竟MMO手游再怎么火也不可能改变手游时间碎片化的事实的，最近的皇家冲突也证明，手游不会再重走端游老路了。
第二种需求就不用说了，网上大把例子可以参考。最典型的是假设有这样一块野地，上面很多玩家和怪，逻辑都在服务端驱动，好了，这类需求没其他额外的描述了。
但是，解决方案毕竟是不断发展的，即使速度很慢。
说不断发展是特指针对第一种需求的解决方案，发展原因就是国情，外挂太多。像war3这种都还是纯正的主客机，但是后来对战平台出现、发展，逐渐过渡成了cs架构。真正的主机 其实是建在服务器的，这样其实服务器这边也维护了房间状态。后来的一系列ARPG端游也都是这个趋势，服务端越来越重，逐渐变得与第二种模式没什么区别。 同理如现在的各种ARPG手游。
说发展速度很慢特指针对第二种需求的解决方案，慢的原因也比较有意思，那就是wow成了不可逾越的鸿沟。bigworld在wow用之前名不见经传，wow用了之后国内厂商也跟进。发展了这么多年，现在的无缝世界服务端跟当年的无缝世界服务端并无二致。发展慢的原因就观察来说可能需求本身就不是特别明确，MMO核心用户是重社交的，无缝世界核心用户是重体验的。前者跑去玩了天龙八部和倩女不干了，说这俩既轻松又妹子多；后者玩了console游戏也不干了，搞了半天MMO无缝世界是让我更好地刷刷刷的。所以仔细想想，这么多年了，能数得上的无缝世界游戏除了天下就是剑网，收入跟重社交的那几款完全不在一个量级。
两种需求起源，最终其实导向了同一种业务需求。传统MMO架构（就是之前说的天龙、倩女类架构），一个进程维护多个场景，每个场景里多个玩家，额外的中心进程负责帮玩家从一个场景/进程切到另一个场景/进程。bigworld架构，如果剥离开其围绕切进程所做的一些外围设施，核心工作流程基本就能用这一段话描述。
抽象一下问题，那我们谈到游戏服务端首先想到的就应该是多玩家对同一场景的view同步，也就是场景服务。
本节不会讨论帧同步或是状态同步这种比较上层的问题，我们将重点放在数据流上。
如何实现场景同步？
首先，我们看手边工具，socket。
之所以不提TCP或UDP是因为要不要用UDP自己实现一套TCP是另一个待撕话题，这篇文章不做讨论。因此，我们假设，后续的实现是建立在对底层协议一无所知的前提之上的，这样设计的时候只要适配各种协议，到时候就能按需切换。
socket大家都很熟悉，优点就是各操作系统上抽象统一。
因此，之前的问题可以规约为：如何用socket实现场景同步？
拓扑结构是这样的（之后的所有图片连接箭头的意思表示箭头指向的对于箭头起源的来说是静态的）：
场景同步有两个需求：
要做到前者，最理想的情况就是由游戏程序员把控消息流的整套pipeline，换句话说，就是不借助第三方的消息库/连接库。当然，例外是你对某些第三方连接库特别熟悉，比如很多C++服务端库喜欢用的libevent，或者我在本篇文章提供的示例代码所依赖的，mono中的IO模块。
要做到后者，就需要保持场景同步逻辑的简化，也就是说，场景逻辑最好是单线程的，并且跟IO无关。其核心入口就是一个主循环，依次更新场景中的所有entity，刷新状态，并通知client。
正是由于这两个需求的存在，网络库的概念就出现了。网络库由于易于实现，概念简单，而且笼罩着“底层”光环，所以如果除去玩具性质的项目之外，网络库应该是程序员造过最多的轮子之一。
那么，网络库解决了什么问题？
抛开多项目代码复用不谈，网络库首先解决的一点就是，将传输层的协议（stream-based的TCP协议或packet-based的UDP协议）转换为应用层的消息协议（通常是packet-based）。对于业务层来说，接收到流和包的处理模型是完全不同的。对于业务逻辑狗来说，包显然是处理起来更直观的。
流转包的方法很多，最简单的可伸缩的non-trivial buffer，ringbuffer，bufferlist，不同的结构适用于不同的需求，有的方便做zero-copy，有的方便做无锁，有的纯粹图个省事。因为如果没有个具体的testcast或者benchmark，谁比谁一定好都说不准。
buffer需要提供的语义也很简单，无非就是add、remove。buffer是只服务于网络库的。
网络库要解决的第二个问题是，为应用层建立IO模型。由于之前提到过的场景服务的rich interaction的特点，poll模型可以避免大量共享状态的存在，理论上应该是最合适场景服务的。所谓poll，就是IO线程准备好数据放在消息队列中，用户线程负责轮询poll，这样，应用层的回调就是由用户线程进入的，保证模型简单。
而至于IO线程是如何准备数据的，平台不同做法不同。linux上最合适的做法是reactor，win最合适的做法就是proactor，一个例外是mono，mono跑在linux平台上的时候虽然IO库是reactor模型，但是在C#层面还是表现为proactor模型。提供统一poll语义的网络库可以隐藏这种平台差异，让应用层看起来就是统一的本线程poll，本线程回调。
网络库要解决的第三个问题是，封装具体的连接细节。cs架构中一方是client一方是server，因此连接细节在两侧是不一样的。而由于socket是全双工的，因此之前所说的IO模型对于任意一侧都是适用的。
连接细节的不同就体现在，client侧，核心需求是发起建立连接，外围需求是重连；server侧，核心需求是接受连接，外围需求是主动断开连接。而两边等到连接建立好，都可以基于这个连接构建同样的IO模型就可以了。
现在，简单介绍一种网络库实现。
具体代码不再在博客里贴了。请参考：
引入新的问题
如果类比马斯洛需求中的层次，有了网络库，我们只能算是解决了生理需求：可以联网。但是后面还有一系列的复杂问题。
最先碰到的问题就是，玩家数量增加，一个进程扛不住了。那么就需要多个进程，每个进程服务一定数量的玩家。
但是，给定任意两个玩家，他们总有可能有交互的需求。
对于交互需求，比较直观的解决方案是，让两个玩家在各自的进程中跨进程交互。但是这就成了一个分布式一致性问题——两个进程中两个玩家的状态需要保持一致。至于为什么一开始没人这样做，我只能理解为，游戏程序员的计算机科学素养中位程度应该解决不了这么复杂的问题。
因此比较流行的是一种简单一些的方案。场景交互的话，就限定两个玩家必须在同一场景（进程），比如攻击。其他交互的话，就借助第三方的协调者来做，比如公会相关的通常会走一个全局服务器等等。
这样，服务端就由之前的单场景进程变为了多场景进程+协调进程。新的问题出现了：
玩家需要与服务端保持多少条连接？
一种方法是保持O(n)条连接，既不环保，扩展性又差，可以直接pass掉。
那么就只能保持O(1)条连接，如此的话，如何确定玩家正与哪个服务端进程通信？
要解决这个问题，我们只能引入新的抽象。
3.1.2 Gate
整理下我们的需求：
要解决这些需求，我们需要引入一种反向代理（reverse proxy）中间件。
反向代理是服务端开发中的一种常见基础设施抽象（infrastructure abstraction），概念很简单，简单说就是内网进程不是借助这种proxy访问外部，而是被动地挂在proxy上，等外部通过这种proxy访问内部。
更具体地说，反向代理就是这样一种server：它接受clients连接，并且会将client的上行包转发给后端具体的服务端进程。
很多年前linux刚支持epoll的时候，流行一个c10k的概念，解决c10k问题的核心就是借助性能不错的反向代理中间件。
游戏开发中，这种组件的名字也比较通用，通常叫Gate。
Gate解决了什么问题
仅就这两点而言，Gate已经能够解决上一节末提出的需求。做法就是client给消息加head，其中的标记可以供Gate识别，然后将消息路由到对应的backend上。比如公会相关的消息，Gate会路由到全局进程；场景相关的消息，Gate会路由到订阅该client的场景进程。同时，玩家要切场景的时候，可以由特定的backend（比如同样由全局进程负责）调度，让不同的场景进程向Gate申请修改对client场景相关消息的订阅关系，以实现将玩家的entity从场景进程A切到场景进程B。
站在比需求更高的层次来看Gate的意义的话，我们发现，现在clients不需要关注backends的细节，backends也不需要关注clients的细节，Gate成为这一pipeline中唯一的静态部分（static part）。
当然，Gate能解决的还不止这些。
我们考虑场景进程最常见的一种需求。玩家的移动在多client同步。具体的流程就是，client上来一个请求移动包，路由到场景进程后进行一些检查、处理，再推送一份数据给该玩家及附近所有玩家对应的clients。
如果按之前说的，这个backend就得推送N份一样的数据到Gate，Gate再分别转给对应的clients。
这时，就出现了对组播（multicast）的需求。
组播是一种通用的message pattern，同样也是发布订阅模型的一种实现方式。就目前的需求来说，我们只需要为client维护组的概念，而不需要做inter-backend组播。
这样，backend需要给多clients推送同样的数据时，只需要推送一份给Gate，Gate再自己dup就可以了——尽管带来的好处有限，但是还是能够一定程度降低内网流量。
那接下来就介绍一种Gate的实现。
我们目前所得出的Gate模型其实包括两个组件：
Gate的工作流程就是，listen两个端口，一个接受外网clients连接，一个接受内网backends连接。
Gate有自己的协议，该协议基于Network的len+data协议之上构建。
clients的协议处理组件与backends的协议处理组件不同，前者只处理部分协议（不会识别组控制相关协议，订阅协议）。
在具体的实现细节上，判断一个client消息应该路由到哪个backend，需要至少两个信息：一个是clientId，一个是key。
同一个clientId的消息有可能会路由到不同的backend上。
当然，Gate的协议设计可以自由发挥，将clientId+key组成一个routingKey也是可以的。
引入Gate之后的拓扑：
具体代码请参考：
引入新的问题
现在我们在需求的金字塔上更上了一层。之前我们是担心玩家数量增长会导致服务端进程爆掉，现在我们已经可以随意扩容backend进程，我们还可以通过额外实现的全局协调者进程来实现Gate的多开与动态扩容。甚至，我们可以通过构建额外的中间层，来实现服务端进程负载动态伸缩，比如像bigworld那样，在场景进程与Gate之间再隔离出一层玩家agent层。
可以说，在这种方案成熟之后，程序员之间开始流行“游戏开发技术封闭”这种说法了。
举一个简单的例子，大概描述下现在一个游戏项目的服务端生命周期状况：
结果就是，产出了几个玩具水平的服务器进程。要非得说是工业级或者生产环境级别的吧，也算是，毕竟bugfix的代码的体量是玩具项目比不了的。而且，为了更好地bugfix，通常会引入lua或者python，然后游戏逻辑全盘由脚本构建，这下更方便bugfix了，还是hotfix的，那开发期就更能随便写写写了，你说架构是什么东西？
至于具体拓扑，可以对着下图脑补一下，增加N个节点，N个节点之间互相连接。
玩具水平的项目再修修补补，也永远不会变成工艺品。
skynet别的不说，至少实现了一套轻量级的actor model，做服务分离更自然，服务间的拓扑一目了然，连接拓扑更是优雅。网易的mobile_server，说实话我真的看不出跟bigworld早期版本有什么区别，连接拓扑一塌糊涂，完全没有服务的概念，手游时代了强推这种架构，即使成了几款过亿流水又怎样？
大网易的游戏开发应届生招聘要求精通分布式系统设计，就mobile_server写出来的玩具也好意思说是“分布式系统”？
很多游戏服务端程序员，在游戏服务端开发生涯结束之前，其接触的，或者能接受的设计基本到此为止。如果是纯MMO手游，这样做没什么，毕竟十几年都这样过来了，开发成本更重要。更搞笑的是社交游戏、异步战斗的卡牌游戏也用mobile_server，真搞不明白怎么想的。
大部分游戏服务端实现中，服务器进程是原子单位。进程与进程之间的消息流建立的成本很低，结果就是服务端中很多进程互相之间形成了O(n^2)的连接数量。
这样的话会有什么问题？
一方面，连接拓扑关系很复杂。一种治标不治本的方法是抬高添加新进程的成本，比如如非必要上面不会允许你增加额外进程，这样更深度的解耦合就成了幻想。
另一方面，游戏服务端的应用层与连接层难以分离。举个例子，在这种设计思路下，两个进程有没有连接是一种不确定态，设计的时候觉得没有，结果某个需求来了，不建立连接就很难实现。这样对于应用层来说，就需要提供连接的概念，某个进程必须先跟其他进程连接建立成功了，然后才能调用其他进程提供的服务。而实际上，更优雅的设计是应用层完全不关注连接细节，只需要知道其他的进程提供了服务，自己就能获取到这种服务。
这样，我们就需要在游戏服务端中提供服务的概念。场景同步服务是一种服务，聊天服务是另一种服务。基于这个思路，我们继续探讨服务应该如何定义，服务有哪些类型，不同类型的服务的消息流应该是怎样的。
3.2 Service-Oriented游戏服务端
3.2.1 游戏服务端中的服务
之前提到，传统MMO架构随发展逐渐出现了分拆的需求，最常见的是把聊天逻辑从全局进程中拆出来。
这种拆分的思路是符合service-oriented的发展趋势的，仔细想想的话，其实聊天服务本来就应该是具体项目无关的。游戏中可以嵌入公司的公共聊天服务，甚至是第三方提供的聊天服务，比如网易最近开推的云信。
这样，聊天服务就是独立于游戏业务而持久存在的，我们就从代码复用的层次上升到了服务复用。诚然，公司内不同项目，也可以直接用同一套聊天服务代码库，达到代码级别的复用。但是这样做最后的结果往往就是，每个团队都会从更早的团队拿过来聊天业务代码，然后自己改造改造，成了完全不同的分支，最后连代码复用都做不到了。
从另一个思路来讲，同一款游戏的不同组服务器，其实也只需要同样的一组聊天服务。但是如果按传统的模式，一组服务器只能开零或一个聊天服务器，事实上，有可能某10组服务器用1个聊天服务器就够了，而某1组服务器用1个聊天服务器压力都有些大。
因此，我们可以定义服务的概念。
在明确这个定义之前，你也许注意到了，我在文章的之前部分措词很混乱——一会儿是XX进程，一会儿是XX服务器，一会儿又是XX服务。现在，我们统称为XX服务（或XXservice）。
比如，场景服务与切场景服务，聊天服务，公会服务等等。
服务是什么？
可以简单理解为一组方法集合。服务是分布式游戏服务端中的最小实体，一个服务提供了一组确定的、可供调用的方法。
skynet中，一个skynet_context唯一对应一个服务，而一个skynet节点对应一组服务；传统MMO中，一个进程对应一组服务，但是很难在其中找到“一个”服务的划分界限。
在确定如何划分服务之前，首先看看服务的类型。
对于游戏服务端的需求来说，服务可以大概分为两类：一类是具有独立命名空间的；一类是在全局命名空间的。
服务的命名空间其实也算是具有游戏开发特色的，虽然不知道最早MMO分服的具体原因是什么，但是就事实而言，ARPG游戏的分服已经成了策划需求。后来又是各种渠道服的需求出现，命名空间更是没办法丢掉。而且还有一点，就是开发阶段本地调试对隔离服务端环境的需求。
举个例子，之前提到的聊天服务就是一种全局命名空间的服务，而对于分服游戏来说，场景服务就是具有独立命名空间的服务。而对于手游来说，可以划分出的服务就更多了。
服务划分解决了什么问题？
以进程为单位开发和服务为单位开发是两种不同的思路。人是有惰性的，如果不是特别必要，上面也没人强推，那我想大部分程序员还是会把聊天服务实现在全局协调进程里。
服务的概念就是为了提出一种与物理容器无关的抽象。服务可以以某个进程为容器，也可以以某个线程为容器。可以像skynet一样以一个luaState为容器，也可以像Erlang游戏服务端那样以一个actor为容器。而一个容器也可以提供多种服务。
注意，这里提出的服务这种抽象与之前所说的Gate这种基础设施抽象是不同的。如果将游戏服务端看做一个整体，那么Gate就是其中的static parts，服务就是其中的dynamic parts。两者解决的是不同层面的问题。
服务划分的核心原则是将两组耦合性较低的逻辑划分为不同的服务。具体实现中肯定不存在完美的划分方案，因此作为让步，只要是互交互不多的逻辑都可以划分为不同的服务。举一个简单的例子就是公会服务v.s.场景服务，两者的关系并不是特别密切。
引入新的问题
服务划分的极端是每一个协议包都对应一种服务。事实上，服务的定义本来就是基本隔绝的逻辑集合。如果服务定义得太多，服务间数据交互就会复杂到程序员无法维护的程度。
复杂数据交互的另一方面，是复杂的网络拓扑。基于我们之前的架构，client与服务的通信可以借助Gate简化模型，但是服务之间的通信却需要 O(n^2)的连接数。服务都是dynamic parts，却对其他服务的有无产生了依赖，而且大部分情况下这种依赖都是双向的。整个服务端的网络会错综复杂。
3.2.2 游戏服务端中的Message Queue
我们要解决的最关键的问题是：如果服务之间很容易就产生相互依赖，应该如何化简复杂的网络拓扑。如果说得实际一点，那就是让服务器组的启动流程与关闭流程更加优雅，同时保证正确性。
skynet给我带来的思路是，服务与服务之间无需保持物理连接，而只需要借助自己寄宿的skynet与其他服务通信，相当于所有服务间的连接都是抽象的、虚拟的。skynet是整个集群中的static parts，服务作为dynamic parts启动顺序肯定在skynet之后。
skynet可以大大简化服务间拓扑关系，但是其定位毕竟不在于此，比如，skynet并不做消息的qos保证，skynet也没有提供各种方便的外围设施。我们还需要提供更强大语义的基础设施抽象。
面对这种需求，我们需要一种消息队列中间件。
生产者消费者一直都是一种比较经典的解耦模型，而消息队列就是基于这种模型构建的。每个skynet节点本质上就是一个高度精简的消息队列，为寄宿的每个服务维护一个私有队列，对全局队列中的消息dispatch，驱动寄宿服务。
而我希望的是更纯粹的消息队列中间件，选择有很多，下面以RabbitMQ为例简单介绍。
RabbitMQ提供了消息队列中间件能提供的所有基本语义，比如消息的ack机制和confirm机制、qos保证、各种pattern的支持、权限控制、集群、高可用、甚至是现成的图形化监控等等。接下来的讨论会尽量不涉及RabbitMQ具体细节，把它当做一个通常的消息队列中间件来集成到我们目前为止形成的游戏服务端之中。当然，Gate经过扩展之后也能替代MQ，但是这样就失去了其作为Gate的意义——Gate更多的是用在性能敏感的场合，比如移动同步，协议太重是没有必要的。而且，重新造个MQ的轮子，说实话意义真的不大。
MQ解决了什么问题？
MQ与Gate的定位类似，都是整个生态中的static parts。但是MQ与Gate是两种不同的基础设施抽象，提供的语义也不尽相同。
这样，我们的服务端中就出现了两个static parts——一个是Gate，一个是MQ。Gate与MQ是两个完全无关的基础设施，这两部分先于其他所有dynamic parts启动、构建。场景服务连接Gate与MQ（前提是确实有其他服务会与场景服务进行通信），聊天服务连接MQ，client连接Gate与MQ。
引入MQ之后的拓扑：
再脑补一下，增加N个节点，就形成了Gate和MQ的双中心，网络拓扑优雅了很多。
就具体实现来说，之所以选择RabbitMQ，还因为其对mqtt协议支持的比较好，官网上就有插件下载。mqtt协议可以参考这里。client走mqtt协议跟MQ通信还是比较轻量级的。
引入新的问题
现在，client或者服务都需要通过不同的协议（Gate、MQ）与其他部分通信。
这样对应用层开发者来说就是一个负担。
ps. Gate的私有协议和mqtt、amqp协议下面会统称为消息路由协议。
而且不同的API的调用模型都不一样，因此我们需要一种应用层统一的调用规范。
3.3 游戏服务端中的RPC与Pattern
整理一下现状。
目前，client可以发送两类消息：一类交由Gate路由，一类交由MQ路由。service也可以接收两类消息：一类由Gate路由过来，一类由MQ路由过来。
我们希望的是，应用层只需要关心服务，也就是说发送的消息是希望转到哪个服务上，以及接收的消息是请求自己提供的哪个服务。
这样对于应用层来说，其看到的协议应该是统一的，而至于应用层协议的底层协议是Gate的协议还是MQ的协议，由具体的适配器（Adaptor）适配。
这个应用层的协议就是RPC的一部分。
RPC一直都是很有争议的。一方面，它能让代码看起来更优雅，省了不少打解包的重复代码；另一方面，程序员能调RPC了，系统就变得很不可控，特别是像某些架构下面RPC底层会绕很多，最后用的时候完全违背设计本意。
但是总的来说，RPC的优势还是比较明显的，毕竟游戏服务端的整体服务定义都是同一个项目组内做的，副作用严格可控，很少会出现调用一条RPC要绕很多个节点的情况。
RPC解决什么样的问题？
RPC的定位是具体消息路由协议与应用层函数调用的中间层。一个标准的RPC框架要解决两个问题：
RPC的协议定义也可以做个划分：
RPC调用规范的核心设计意图就是让应用层程序员调用起来非常自然、不需要有太多包袱（类bigworld架构的rpc设计通常也是这个原则，尽量让应用层不关注切进程的细节）。调用规范的具体细节就跟语言和平台相关了。在支持异步语法的语言/平台，可以原生集成异步等待、执行完恢复上下文继续执行的语义。在不支持异步语法的语言/平台，那就只能callback。如果是不支持将函数作为参数传递的语言/平台，我想你应该已经离现代游戏开发太远了。
通用的部分确定之后，还得解决特定于具体路由方式的、需要适配的部分。
我将这部分逻辑称为Adaptor，很好理解，就是RPC到具体消息路由协议、具体消息路由协议到RPC的适配器。
下面，结合一种具体的RPC实现方式（下文称为Phial规范），来探讨下如何将上面提出的这几个概念串起来。
先通过一个大概的流程来厘清一次RPC流程中涉及的所有角色。
RPC既然作为一次远程过程调用，那么，对于调用方来说，其调用的是一个跟普通函数很像的函数（有可能表现为一个异步函数，也有可能表现为一个同步函数）；对于被调用方来说，其被调用的就真的是自己的一个函数了。
整个的pipeline也很清晰：
在这个过程中，我们称调用方可以调用的是服务的delegate（可以类比为Stub），被调用方注册进来的是服务的implement（可以类比为Skeleton）。路由适配层就是Adaptor。可以基于不同类型的Adaptor构造服务的delegate。服务的implement也可以注册在不同的Adaptor上。不同的Adaptor只需要针对RPC层提供同样的接口，让RPC层可以发送打包消息和服务特定的路由规则，可以注册implement即可保证RPC层与Adaptor层是完全无关的。
我们在示例中实现了多种Adaptor，目前为止涉及到的有MqttAdaptor、GateAdaptor、AmqpAdaptor。
除了这整个的数据流之外，示例中还包装了两种异步调用与回调形式。
第一种专门针对不支持.Net 4.5的平台，比如Unity。但是只要针对这种形式稍加扩展，也能支持.Net 2.0的yield语义，实现简单协程。关于.Net 2.0中的协程实现，可以。
两种异步方式实现回调的原理是相同的，都是本地hold住调用上下文，等回包的时候检查即可。
这样，在支持.Net 4.5的平台，一个穿插了RPC调用的函数就可以写成这个样子：
123int a = GetNumber(0);int b = await SceneToSceneMgrService.GetNumber(a);int c = b;在Unity中的脚本逻辑，可以这样调用RPC：
service.AskXXX(x,
y).Callback
(operation.IsComplete)
operation.Result;
关于一些细节的说明
引入新的问题
有了RPC之后，我们可以在应用层以统一的形式进行服务请求。
但是这样还不够——我们目前所提的RPC就是普通的方法调用，虽然对应用层完全隐藏了协议或者其他中间件的细节，但是这样一来这些中间件的强大特性我们也就无法利用了。
还应该有另一种与RPC平行的抽象来特化RPC的形式，这种抽象与RPC共同组成了一种游戏开发规范。
3.3.2 RPC、Pattern与规范
由于不同的中间件解决问题的方式不同，因此我们没办法在应用层用统一的形式引用不同的中间件。因此，我们可以针对游戏开发中的一些比较经典的消息pipeline，定义pattern。然后，用pattern与RPC共同描述服务应该如何声明，如何被调用。
Pattern解决了什么问题
不同的基础设施抽象可以实现不同的pattern子集，如果需要新增加一类基础设施，我们可以看它的功能分别可以映射到哪几种pattern上，这样就能直接集成到Phial规范中。
下面，就针对游戏服务端的常见需求，定义几种pattern。
三种通信情景：
最简单的pattern是ask，也就是向服务发起一次异步调用，然后client不关注服务的处理结果就直接进行后续的逻辑。最常见的就是移动请求。
还有一种是传统MMO中不太重视，而异步交互手游反倒从web引入的request。client向服务发起一次异步调用，但是会等到服务处理结果返回（或超时）才进行后续的逻辑。例子比较多，比如一次抽卡或者一次异步PVP。
与ask对应的是sync，是服务进行一次无源的对client的impl调用，client无条件执行impl逻辑。sync需要指明被调用方。这种最常见的是移动同步。有一点需要注意，示例中实现了一种形式比较丑陋的组播sync，依赖了Gate的私有协议，也就是forward指定一个int值。这个之后会做调整。
与request对应的是reply。这个相当于是处理一次request然后直接返回一个值，没什么特别之处。
最常见的就是invoke，相当于一次希望返回值的远程调用。例子有很多，适用于任意两个服务间的通信需求。
还有一种解耦利器我称之为notify。当然本质上其实就是pub-sub，消息会在中间件上dup。应用情景是消息提供者/事件源只管raise event，而不关注event是否被处理、event后续会被路由到哪里。在中间件上，只要有服务实现了该notify service的impl，就能得到通知；如果没有任何节点提供对该服务的impl，就相当于消息被推到了sink。应用情景是可以将玩家行为log以及各种监控、统计系统逻辑从业务代码中剥离出来，事件源触发的逻辑只有一处，而处理的逻辑可以分散在其他监控进程中，不需要增加一种监控就得在每个事件源都对应插一行代码。
Gate和MQ实现了不同的pattern集合。当然，正如之前所说，Gate本质上也是一种MQ，但是由于我们对这两种基础设施抽象的定位不同，所以在实现各自的Adaptor的时候也限定了各自支持的pattern。比如，Gate不能支持notify，MQ不能支持ask-sync。
我在示例实现中没有加入MQ对客户端组播的支持。主要原因是考虑到client是通过MQTT协议跟MQ通信，相当于组维护是client发起的。对于聊天这种的可能还好，对于其他的可能会有隐患。
引入新的问题
到目前为止，我们总结出了如下几种与游戏服务端有关的消息pipeline：
这基本上已经能涵盖游戏中的大部分需求了，因此我们对消息流的讨论就到此为止。
接下来讨论游戏世界的状态维护。
维护游戏世界状态的职责同样由一种服务负责，这种服务下面称为数据服务。
但是数据服务所说的服务与之前所提的作为dynamic parts的Phial服务不太相同，实际上是一些基础设施抽象和Phial服务的组合。
有了数据服务，我们还可以更加明确client与service走Gate与MQ究竟有什么本质区别。
4 游戏世界状态的维护方式
4.1数据服务的定位
游戏世界的状态可以简单分为两个部分，一部分是需要存档的，比如玩家数据；一部分是不需要存档的，比如场景状态。
对于访问较频繁的部分，比如场景状态，会维护成纯内存数据；对于访问较不频繁的部分，比如玩家存档，就可以考虑维护在第三方。这个第三方，就是数据服务。
数据服务与之前所提到的场景服务、IM服务等都属于应用层的概念。数据服务通常也会依赖于一种基础设施抽象，那就是缓存。
4.1.1 传统架构中的数据服务
传统MMO架构中，数据服务的概念非常模糊。
我们还是先通过回顾发展历史的形式来厘清数据服务的定义。回到场景进程的发展阶段，玩家状态是内存中的数据，但是服务器不会一直开着，因此就有了存盘（文件或db）需求。但是随着业务变复杂，存盘逻辑需要数据层暴露越来越多的存储API细节，非常难扩展。因此发展出了Db代理进程，场景进程直接将存档推给Db代理进程，由Db代理进程定期存盘。
这样，存储API的细节在Db代理进程内部闭合，游戏逻辑无须再关注。场景进程只需要通过协议封包或者RPC的形式与Db代理进程交互，其他的就不用管了。
Db代理进程由于是定期存盘，因此它相当于维护了玩家存档的缓存。这个时候，Db代理进程就具有了数据服务的雏形。
跟之前的讨论一样，我在这里又要开始批判一番了。
很多团队至今，新立项的项目都仍然采用这种Db代理进程。虽然确实可以用来满足一定程度的需求，但是，存在几个致命问题。
我们可以构建一个数据服务解决这些问题。至于依赖的具体缓存基础设施，我之后会以redis为例。
redis相比于传统的KV比如memcache、tc，具有不同的设计理念，redis的定位是一种数据结构服务器。游戏服务端开发可以拿redis当缓存用，也可以直接当一个数据库用。
数据服务解决了什么问题
数据服务首先要解决的就是玩家存档问题。redis作为一个高性能缓存基础设施，可以满足逻辑层的存档需求。同时还可以实现额外的落地服务，比如将redis中的数据定期存回mysql。之所以这样做，一方面是因为redis的定位是高性能缓存设施，那就不希望它被rdb、aofrewrite机制拖慢表现，或者卡IO；另一方面是对于一些数据分析系统，用SQL来描述数据查询需求更合适，如果只用redis，还得单独开发查询工具，得不偿失。
数据服务其次要解决的问题是可以做到服务级别的复用。这一点我们可以借助企业应用开发中的ORM来设计一套对象-kv-关系映射。也就是数据服务是统一的，而不同的业务可以用不同的数据结构描述自己的领域模型，然后数据服务的配套工具会自动生成数据访问层API、redis中cache关系以及mysql中的table schema。也就是说，同样的数据服务，我在项目A中引用并定义了Player结构，就会自动生成LoadPlayer的API；在项目B中定义User同理生成LoadUser的API。
这两个问题是比较容易解决的，最关键的还是一个思路的转换。
下面看一种non-trivial的实现。，。
实际上，数据服务除去缓存基础设施的部分，都属于外围机制。在有些设计中，我们可以看到还是存在缓存服务与逻辑服务的中间层。这种中间层的单点问题很容易解决——只要不同的逻辑服务访问不同的中间层节点即可。中间层的意义通常是进行RPC到具体缓存协议API的转换，在我的实现中，由于已经有了数据访问API的自动生成，因此没有这种中间层存在的必要。所有需要访问数据服务的逻辑服务都可以直接通过数据访问API访问。
其中还有几点细节：
引入新的问题
目前仍然遗留了几个问题：
&4.1.2 无状态服务中数据服务的定位
之前提到过，游戏世界的状态除了需要存档的玩家数据，还有一部分是不需要存档的逻辑服务的状态。
数据服务如果只是用来替代MMO中的Db代理进程的，那么它的全部职责就仅仅是为需要存档的数据提供服务。从更高的抽象层次来看的话，数据服务相当于是维护了client在服务端的状态。
但是，数据服务提供了更强大的抽象能力。现在数据服务的API结构是任意定制的、code first，而且数据服务依赖的基础设施——redis又被证明非常强大，不仅仅是性能极佳，而且提供了多种数据结构抽象。那么，数据服务是否可以维护其他服务的状态？
在web开发中，用缓存维护服务状态是一种很常规的开发思路。而在游戏服务端开发中，由于场景服务的存在，这种思路通常并不靠谱。
为什么要用缓存维护服务状态？
考虑这样一个问题：如果服务的状态维护在服务进程中，那么服务进程挂掉，状态就不存在了。而对于我们来说，服务的状态是比服务进程本身更加重要的——因为进程挂了可以赶紧重启，哪怕耽误个1、2s，但是状态没了却意味着这个服务在整个分布式服务端中所处的全局一致性已经不正确了，即使瞬间就重启好了也没用。
那么为了让服务进程挂掉时不会导致服务状态丢掉，只要分离服务进程的生命周期和服务状态的生命周期就可以了。
将进程和状态的生命周期分离带来的另一个好处就是让这类服务的横向扩展成本降到最低。
比较简单的分离方法是将服务状态维护在共享内存里——事实上很多项目也确实是这样做的。但是这种做法扩展性不强，比如很难跨物理机，而且共享内存就这样一个文件安全性很难保障。
我们可以将服务状态存放在外部设施中，比如数据服务。
这种可以将状态存放在外部设施的服务就是无状态服务（stateless service）。而与之对应的，场景服务这种状态需要在进程内维护的就是有状态服务（stateful service）。
有时候跟只接触过游戏服务端开发的业务狗谈起无状态服务，对方竟然会产生 一种“无状态服务是为了解决游戏断线重连的吧”这种论点，真的很哭笑不得。断线重连在游戏开发中固然是大坑之一，但是解决方案从来都跟有无状态毫无关系， 无状态服务毕竟是服务而不是客户端。如果真的能实现一个无状态游戏客户端，那真的是能直接解决坑人无数的断线重连问题。
无状态游戏客户端意味着网络通信的成本跟内存数据访问的成本一样低——这当然是不可能实现的。
无状态服务就是为了scalability而出现的，无状态服务横向扩展的能力相比于有状态服务大大增强，同时实现负载均衡的成本又远低于有状态服务。
分布式系统中有一个基本的CAP原理，也就是一致性C、响应性能A、分区容错P，无法三者兼顾。无状态服务更倾向于CP，有状态服务更倾向于AP。但是要补充一点，有状态服务的P与无状态服务的P所能达到的程度是不一样的，后者是真的容错，前者只能做到不把鸡蛋放在一个篮子里。
两种服务的设计意图不同。无状态服务的所有状态访问与修改都增加了内网时延，这对于场景服务这种性能优先的服务是不可忍受的。而有状态服务非常适合场景同步与交互这种数据密集的情景，一方面是数据交互的延迟仅仅是进程内方法调用的开销，另一方面由于数据局部性原理，对同样数据的访问非常快。
既然设计意图本来就是不同的，我们这一节就只讨论数据服务与无状态服务的关系。
游戏中可以拆分为无状态服务的业务需求其实有很多，基本上所有服务间交互需求都可以实现为无状态服务。比如切场景服务，因为切场景的请求是有限的，对时延的要求也不会特别高，同理的还有分配房间服务；或者是面向客户端的IM服务、拍卖行服务等等。
数据服务对于无状态服务来说，解决了什么问题？
简单来说，就是转移了无状态服务的状态维护成本，同时让无状态服务具有了横向扩展的能力。因为状态维护在数据服务中，所以无状态服务开多少个都无所谓。因此无状态服务非常适合计算密集的业务需求。
你可能觉得我之前在服务划分一节之后直接提出要引入MQ有些突兀，实际上，服务划分要解决的根本问题就是让程序员能清楚自己定义每种服务的意图是什么，哪一种服务更适合Request-Reply，哪一种服务更适合Ask-Sync。
假设策划对游戏没有分服的需求，理论上讲，有节操的程序是不应该以“其他游戏就这样做的”或“做不到”之类的借口搪塞。每一种服务都由分布式的多个节点共同提供服务，如果服务的消息流更适合Request-Reply pattern，那么实现为无状态服务就更合适，原因有二：
针对第二点，可能需要稍微介绍下rabbitMQ。rabbitMQ中有exchange（交换机）、queue、binding（绑定规则）三个主要概念。其中，exchange是对应生产者的，queue是对应消费者的，binding则是描述消息从exchange到queue的路由关系的。exchange有两种常用类型direct、topic。其中direct exchange接收到的消息是不会dup的，而topic exchange则会将接收到的消息根据匹配的binding确定要dup到哪个target queue上。
这样，对于无状态服务，比如同一命名空间下的切场景服务，可以共用同一个queue，然后client发来的消息走direct exchange，就可以在MQ层面做到round-robin，将消息轮流分配到不同的切场景服务上。
而且无状态服务本质上是没有扩容成本的，波峰就多开，波谷就少开。
程序员负责为不同服务规划不同的横向扩展方式。比如类似公会服务这种走MQ的，横向扩展的触发条件就是现在请求数量级或者是节点压力。比如场景服务这种Ask-Sync的，横向扩展就需要借助第三方的服务作为仲裁者，而这个仲裁者可以实现为基于MQ的服务。
这里有个问题需要注意一下。
由于现在同一个client上来的request消息可能由无状态服务的不同节点处理，那么就会出现这样的情况：
假如Sa与Sb有交集，那就会出现竞态条件，如果这时允许服务A存回结果，那数据就有可能存在不一致。
类似的情况还会出现在像率土之滨或者cok这种策略游戏的大世界刷怪需求中。当然前提是玩家与大地图上的元素交互和后台刷怪逻辑都是基于无状态服务做的。
这其实是一个跨进程共享状态问题，而且是一个高度简化的版本——因为这个共享状态只在一个实例上维护。可以引入锁来解决问题，思路通常有两个：
最直观的一种方案是悲观锁。也就是如果要进行修改操作，就需要在读相关数据的时候就都加上锁，最后写成功的时候释放锁。获得锁所有权期间其他impure服务任意读写请求都是非法的。
但是，这毕竟不是多线程执行环境，没有语言或平台帮你做自动锁释放的保证。获取悲观锁的服务节点不能保证一定会将锁释放掉，拿到锁之后节点挂掉的可能性非常大。这样，就需要给悲观锁增加超时机制。
第二种方案是乐观锁。也就是impure服务可以随意进行读请求，读到的数据会额外带个版本号，等写的时候对比版本号，如果一致就可以成功写回，否则就通知到应用层失败，由应用层决定后续操作。
带过期机制的悲观锁和乐观锁本质上都属于可抢占的分布式锁，相当于是将paxos要解决的问题退化为单Acceptor，因此实现起来非常简单。可过期的悲观锁和乐观锁唯一的区别就是前者在申请锁的时候有可能申请失败，而后者申请锁时永远不会失败。两种方案具体的表现优劣跟业务需求有关，不论一开始选择的是哪一种，都非常容易切换到另一种。
我在示例中实现了一个，在提交修改的时候用一个lua脚本做原子检查就能简单实现。如果要实现带过期机制的悲观锁，需要保证应用层有简单的时钟同步机制，而且在申请锁的时候也要写一个lua脚本。
在应用层也做了对应修改，调用数据访问层API可以按如下这种方式调用。之所以用了RTTI，是考虑到有可能会改成悲观锁实现，在Dispose的时候会自动release lock。现在pure服务与impure服务对数据服务调用的接口是不一样的，我们甚至还可以基于这一点在底层做一些扩展，最典型的比如读写分离。当然，这些都是引入主从之后要考虑的问题了。
structFstAccesser
GetStructFstAccesser())
&&&&&&using
structSndAccesser
GetStructSndAccesser())
&&&&&&&&&&var
structFstAccesser.LoadFieldFstAsync();
&&&&&&&&&&var
structSndAccesser.LoadFieldSndAsync();
&&&&&&&&&&//
logic here...
structFstAccesser.UpdateFieldFst(fieldFst);
structSndAccesser.UpdateFieldSnd(fieldSnd);
SubmitChanges(structFstAccesser,
structSndAccesser);
result handle here
有了这样一个简易的锁机制，我们可以保证单redis实例内的一致性。
引入新的问题
有了无状态服务的概念，我们的架构中就可以逐步干掉类似切场景管理这种单点进程。无状态服务是高可用的，也就是说，任意挂掉一个，仍然能持续提供服务。
整个游戏服务端理论上应该具有整体持续提供服务的能力。也就是说，随便挂掉一个节点，不需要停服。场景服务挂掉一个节点，不会影响其他任何服务，只是玩家短期内无法进行场景相关操作了而已。
而我们见过的大多数架构，处处皆单点，这完全不能叫可用的架构。有的时候一个服务端跑的好好的，有人硬是要额外加一个全局单点，而且理由是更容易管理，让人哭笑不得。分布式系统中动不动就想加单点，这是病，得治。判断一整个游戏服务端是否具有可用性很简单，随便kill掉一个节点，如果服务端仍然能持续提供服务，即使是部分client受到了影响，也能称为是可用的。
但是，现在逻辑服务具有可用性了，可是数据服务还没有具有可用性，数据服务依赖于一个redis实例，这个redis实例反而成为了整个服务端中的单点。
幸好，redis像其他大多数工业级缓存基础设施一样，已经提供了足够用的可用性机制。但是，在讨论redis的可用性机制之前，我们先解决一下数据服务的一个遗留问题，那就是如何构建一个可以扩展的全局数据服务。
4.2 数据服务的扩展
redis是一种stateful service，继续应用之前的CAP原则，redis是倾向于AP的。之后我们可以看到，redis的各种扩展，实际上都是基于这个原则来做的。
4.2.1 分片方案
我们遇到的问题是，如果将数据服务定位为全局服务，那仅用单实例的redis就难以应对多变的负载情况。毕竟redis是单线程的。
从mysql一路用过来的同学这时都会习惯性地水平拆分，redis中也是类似的原理，将整体的数据进行切分，每一部分是一个分片shard，不同的shard维护的key集合是不同的。
那么，问题的实质就是如何基于多个redis实例设计全局统一的数据服务。同时，有一个约束条件，那就是我们为了性能需要牺牲全局一致性。也就是说，数据服务进行分片扩展的前提是，不提供跨分片事务的保障。redis cluster也没有提供类似支持，因为分布式事务本来就跟redis的定位是有冲突的。
因此，我们之后的讨论会有一个预设前提：不同shard中的数据一定是严格隔离的，比如是不同组服的数据，或者是完全不相干的数据。要想实现跨shard的数据交互，必须依赖更上层的协调机制保证，底层不做任何承诺。
这样，我们的分片数据服务就能通过之前提到的简易锁机制提供单片内的一致性保证，而不再提供全局的一致性保证。
基于同样的原因，我们的分片方案也不会在分片间做类似分布式存储系统的数据冗余机制。
分片方案解决了什么问题
分片需要解决两个问题：
针对第一个问题，解决方案通常有三：
需求决定解决方案，对于游戏服务端来说，后两者的成本太高，而且增加了很多不确定的复杂性，因此现阶段这两种方案并不是合适的选择。比如gossip protocol，redis cluster现在都不算是release，确实不太适合游戏服务端。而且，游戏服务端毕竟不是web服务，通常是可以在设计阶段确定每个分片的容量上限的，也不需要太复杂的机制支持。
但是第一种方案的缺点也很明显，做不到动态增容减容，而且无法高可用。但是如果稍加改造，就足以满足需求了。
在谈具体的改造措施之前，先看之前提出的第二个问题。
第二个问题实际上是从另一种维度看分片，解决方案很多，但是如果从对架构的影响上来看，大概分为两种：
第一种方案的缺点显而易见，在整个架构中增加了额外的间接层，pipeline中增加了一趟round-trip。如果是像twemproxy或者Codis这种支持高可用的还好，但是github上随便一翻还能找到特别多的没法做到高可用的proxy-based方案，无缘无故多个单点，这样就完全搞不明白sharding的意义何在了。
第二种方案的缺点就是集群状态发生变化的时候没法即时通知到dbClient。
第一种方案，我们其实可以直接pass掉了。因为这种方案本质上还是更适合web开发的。web开发部门众多，开发数据服务的部门有可能和业务部门相去甚远，因此需要统一的转发代理服务。但是游戏开发不一样，数据服务逻辑服务都是一帮人开发的，没什么增加额外中间层的必要。
那么，看起来只能选择第二种方案了。
将presharding与client sharding结合起来后，现在我们的改造成果是：数据服务是全局的，redis可以开多个实例，不相干的数据需要到不同的shard上存取，dbClient掌握这个映射关系。
引入新的问题
目前的方案只能满足游戏对数据服务的基本需求。
大部分采用redis的游戏团队，一般最终会选定这个方案作为自己的数据服务。后续的扩展其实对他们来说不是不可以做，但是可能有维护上的复杂性与不确定性。今天这篇文章，我就继续对数据服务做扩展，后面的内容权当抛砖引玉。
现在的这个方案存在两个问题：
针对第一个问题，处理方式跟proxy-based采用的处理方式没太大区别，由于目前的数据服务方案比较简单，采用一致性哈希即可。或者采用一种比较简单的两段映射，第一段是静态的固定哈希，第二段是动态的可配置map。前者通过算法，后者通过map配置维护的方式，都能最小化影响到的key集合。
而对于第二个问题，实际上就是上一节末提到的数据服务可用性问题。
4.2.2 可用性方案
讨论数据服务的可用性之前，我们首先看redis的可用性。
对于redis来说，可用性的本质是什么？其实就是redis实例挂掉之后可以有后备节点顶上。
redis通过两种机制支持这一点。
还是由于CAP原则，redis的replication方案采用的是一种一致性较弱的active-passive方案。也就是master自身维护log，将log向其他slave同步，master挂掉有可能导致部分log丢失，client写完master即可收到成功返回，是一种异步replication。
这个机制只能解决节点数据冗余的问题，redis要具有可用性就还得解决redis实例挂掉让备胎自动顶上的问题，毕竟由人肉去监控master状态再人肉切换是不现实的。 因此还需要第二种机制。
redis基于自带的这两种机制，已经能够实现一定程度的可用性。那么接下来，我们来看数据服务如何高可用。
数据服务具有可用性的本质是什么？除了能实现redis可用性的需求——redis实例数据冗余、故障自动切换之外，还需要将切换的消息通知到每个dbClient。
由于是redis sentinel负责主从切换，因此最自然的想法就是问sentinel请求当前节点主从连接信息。但是redis sentinel本身也是redis实例，数量也是动态的，redis sentinel的连接信息不仅在配置上成了一个难题，动态更新时也会有各种问题。而且，redis sentinel本质上是整个服务端的static parts（要像dbClient提供服务），但是却依赖于redis的启动，并不是特别优雅。另一方面，dbClient要想问redis sentinel要到当前连接信息，只能依赖其内置的pub-sub机制。redis的pub-sub只是一个简单的消息分发，没有消息持久化，因此需要轮询式的请求连接信息模型。
上一节末提到过，要想最小化数据迁移成本可以采用两段映射或一致性哈希。这时还有另一种可以扩展的思路，如果采用两段映射，那么我们可以动态下发第二段的配置数据；如果采用一致性哈希，那么我们可以动态下发分片的连接信息。这其中的动态，就可以基于新的符合Phial规范的服务来做。而这个通知机制，就非常适合采用Phial中的Notify pattern实现。而且redis sentinel的实现难度比较低，我们完全可以以较低的成本实现一个扩展性更强，定制性更强，还能额外支持分片服务的部分在线数据迁移机制的服务。
同时，有一部分我在这篇文章里也没提过，那就是落地服务所依赖的mysql的可用性保障机制。相比于再开一个额外的mysql高可用组件，倒不如整合到同样的一个数据服务监控服务中。
这个监控服务就是watcher。由于原理类似，接下来的讨论就不再涉及对mysql的监控部分，只针对redis的。
watcher解决了什么问题？
解决这些问题，watcher的职责就已经达成，我们的数据服务也就更加健壮，可用程度更高。
引入新的问题
但是，如果我们引入了新的服务，那就引入了新的不确定性。如果引入这个服务的同时还要保证数据服务具有可用性，那我们就还得保证这个服务本身是可用的。
先简单介绍一下redis sentinel的可用性是如何做到的。同时监控同一组主从的sentinel可以有多个，master挂掉的时候，这些sentinel会根据一种raft算法的工业级实现选举出leader，算法流程也不是特别复杂，至少比paxos简单多了。所有sentinel都是follower，判断出master客观下线的sentinel会升级成candidate同时向其他follower拉票，所有follower同一epoch内只能投给第一个向自己拉票的candidate。在具体表现中，通常一两个epoch就能保证形成多数派，选出leader。有了leader，后面再对redis做SLAVEOF的时候就容易多了。
如果想用watcher取代sentinel，最复杂的实现细节可能就是这部分逻辑了。
这部分逻辑说白了就是要在分布式系统中维护一个一致状态，举个例子，可以将“谁是leader”这个概念当作一个状态量，由分布式系统中的身份相等的几个节点共同维护，既然谁都有可能修改这个变量，那究竟谁的修改才奏效呢？
幸好，针对这种常见的问题情景，我们有现成的基础设施抽象可以解决。
这种基础设施就是分布式系统的协调器组件（coordinator），老牌的有zookeeper（zab），新一点的有etcd（raft）。这种组件通常没有重复开发的必要，像paxos这种算法理解起来都得老半天，实现起来的细节数量级更是难以想象。因此很多现成的开源项目都是依赖这两者实现高可用的，比如codis就是用的zk。
zk解决了什么问题？
就我们的游戏服务端需求来说，zk可以用来选leader，还可以用来维护dbClient的配置数据——dbClient直接去找zk要数据就行了。
zk的具体原理我就不再介绍了，具体的可以参考lamport的paxos paper，没时间没精力的话搜一下看看zk实现原理的博客就行了。
简单介绍下如何基于zk实现leader election。zk提供了一个类似于os文件系统的目录结构，目录结构上的每个节点都有类型的概念同时可以存储一些数据。zk还提供了一次性触发的watch机制。leader election就是基于这几点概念实现的。
假设有某个目录节点/election，watcher1启动的时候在这个节点下面创建一个子节点，节点类型是临时顺序节点，也就是说这个节点会随创建者挂掉而挂掉，顺序的意思就是会在节点的名字后面加个数字后缀，唯一标识这个节点在/election的子节点中的id。
一个简单的方案是我们可以每个watcher都watch /election的所有子节点，然后看自己的id是否是最小的，如果是就说明自己是leader，然后告诉应用层自己是leader，让应用层进行后续操作就行了。但是这样会产生惊群效应，因为一个子节点删除，每个watcher都会收到通知，但是至多一个watcher会从follower变为leader。
优化一些的方案是每个节点都关注比自己小一个排位的节点。这样如果id最小的节点挂掉之后，id次小的节点会收到通知然后了解到自己成为了leader，避免了惊群效应。
还有一点需要注意的是，临时顺序节点的临时性体现在一次session而不是一次连接的终止。例如watcher1每次申请节点都叫watcher1，第一次它申请成功的节点全名假设是watcher10002（后面的是zk自动加的序列号），然后下线，watcher10002节点还会存在一段时间，如果这段时间内watcher1再上线，再尝试创建watcher1就会失败，然后之前的节点过一会儿就因为session超时而销毁，这样就相当于这个watcher1消失了。解决方案有两个，可以创建节点前先显式delete一次，也可以通过其他机制保证每次创建节点的名字不同，比如guid。
至于配置下发，就更简单了。配置变更时直接更新节点数据，就能借助zk通知到关注的dbClient，这种事件通知机制相比于轮询请求sentinel要配置数据的机制更加优雅。
我在实现中将zk作为路由协议的一种整合进了Phial规范，这样基于zk的消息通知可以直接走Phial的RPC协议。
有兴趣的同学可以看下，leader
election的功能作为zkAdaptor的特殊API，watcherService会直接调用。而配置下发直接走了RPC协议，集成在统一的Phial.RPC规范中。zkAdaptor仅支持Phial.RPC中的Notify pattern。
watcher的实现。
5.总结目前形成的架构以及能做什么
整理下这篇文章到目前为止做了什么事情：
总结下出现的几种概念：
到目前为止的拓扑图：
系统设计中的static parts与dynamic parts
gate/mq/zk/redis/mysql
almost all custom services
这篇文章的灵感起源是，看完之后深有感触。虽然JAVA不是一门好语言，但是JAVA技术栈却发展得如此优雅。JAVA技术栈上的每一种IA都专注于解决特定的一小块问题，比如这里提到的。未来的应用框架开发者，就像是用胶水将这些基础设施粘合起来。游戏服务端程序员通常习惯于c++的小圈子，甚至有一种传教的趋势宣扬c++才是代表的游戏服务端的核心技术。有的时候，游戏程序员需要从c++的小圈子跳出来向外走一走，有可能你就不想再湮没在繁文缛节中，而是发现更大的世界。
不过话又说回来，不喜欢跳出c++小圈子的游戏服务端程序员，大部分又都对c++本身其实知之甚少，奉OOP为圭臬，各种虚继承、多继承出来的代码看到想吐。尝试用模板的各种奇技淫巧把c++写成haskell的虽然更有跳出c++小圈子的倾向，但是既然都如此用了，又何必拘泥于c++？
我在这篇文章里尽量少的插入代码，尽量描述游戏服务端定义问题、解决问题的思路。服务端用C#写的毕竟是少数，但是有了思路随便改写成其他语言都没问题。
我顺便也借着写这篇博客的机会，整理了下一些小东西放在github上。
比如提到的代码生成器组合子，
比如之前的定时器博客提到的linux内核风格定时器，以及基于定时器写的example，C#协程，都放在这里，
比如提到的行为树编译器原型和c# runtime示例，
还有学习parsec的一个小结，可以用来parse单个c#文件拿到一些描述信息的，当然纯属学习性质，有这种需求的时候最好优先用反射。
然后就是跟这篇博客相关的
一个简单的网络库，；
一个简单的基于Network的Gate，；
规范的整个底层库，；
为底层库开发的两个配套代码生成器，；
示例实现，。
github中的以演示为目的，因此相比于博客，还有不少部分是to be determined（比如详细的配置流程、MQ的集群化、mysql的故障转移集成、落地服务的实现细节等等），之后我也会继续维护。
一、不得利用本站危害国家安全、泄露国家秘密，不得侵犯国家社会集体的和公民的合法权益，不得利用本站制作、复制和传播不法有害信息！
二、互相尊重，对自己的言论和行为负责。
本文标题：
本页链接：