（PS开始应用《暗时间》里提到的理论，将skynet用自己的话来总结并写下来，这样能充分思考并转述为自己的记忆线索）

一、skynet设计的理解

（一）单个skynet节点

（1）愿景

    充分利用多核。最初想法是多进程。像咱们nodejs里多核就只能是多进程了，因为每个nodejs进程是单线程的。

    多进程是遵循unix设计哲学，工具链形式，分拆进程的形式来分拆模块，减少复杂度和耦合性，方便编程及维护。

    后来云风他们发现lua做为嵌入式脚本，写逻辑时很好用的，反正如何都要用lua，而且lua提供了沙盒，这样多进程可以变为单进程多个沙盒，这样综合了多进程和单进程多线程的优势。多线程里共享资源，在同一进程地址空间，访问更高效。

（2）核心功能（门房？）

    很精简，仅解决一个问题。

    skynet里不实现具体游戏逻辑，后者些放到一个一个动态库里（so文件）。skynet将这些so注册到自己里边，每个so一个永不重复的id，类似于数据库的autoincreament。看描述这个id是skynet自己运行时当次维护的，而不是模块配置好终身的id。模块的永久有效唯一标示为名字，skynet提供了名字服务，可以给每个模块取一个易读的名字。

（3）核心不解决什么问题

    skynet主张所有服务在同一OS进程协作完成。核心里就没管跨机通讯，单个服务的崩溃和重启也没管，云风表示这些应该由上层处理，他有责任暴露错误，而不是隐藏。

    这个设计的原因，游戏和操作系统不一样，操作系统默认不信任任何进程，各进程崩溃什么的不应影响其他进程，所以某个进程挂了，他就安葬它，而其他进程美好的生活。单游戏是为玩家服务的，某个环节出错都有可能造成玩家利益混乱，所以那里错了就整个流程（服务器）挂掉吧。没有必要让出错模块被隔离开，而其他模块却继续提供服务导出未预知行为。

    上边说的东西应该上层考虑，使用lua的沙盒就能做策略隔离。

（4）skynet运行时逻辑流

    skynet负责且只负责将一个数据包从一个服务发送到同一进程的另一个服务里。发送服务直接调发送API，skynet收到数据包后，调用接受者服务的注册的callback，即发给了接受者服务。

    skynet保证在各模块初始化时、每个独立的callback调用时，都是相互线程安全的。这样编写服务的人就不需要考虑多线程的任何问题了，只需专心处理给他的一个个数据包。

    PS：天龙的场景lua有点像这里的单个服务。不知天龙的跨线程切场景情况在这里也可以给简化为单线程？（回头看源码再研究这个问题）

（5）消息调度

TODO

（6）gate和connection

TODO

​

（二）skynet集群

    集群里最多支持255个skynet节点，每个skynet节点有一个id，成为harbor id。这个id是集群层面指定，可以人为分配，也可以由一个中央服务器协调分配。

（1）集群间通信

    skynet核心层纸负责在往外发消息时在source字段上加上自己的harbor id。而集群间的通信，是由单独的harbor服务来做的。skynet将是往集群其他节点发的消息，就转发到harbor内。harbor会跟集群内跟自己结识的skynet的harbor简历tcp链接。harbor把消息发给目标harbor。

    harbor间的通信为单向的tcp管道。

    master服务来同步全局的名字服务。每个skynet都会知道其他节点上装配了哪些服务，好路由过去。

（2）组播

    TODO

    这是很基础的概念，之前没怎么弄过http。对于自己，算是做个笔记吧。

一、socket安全验证

    socket链接是握手之后就一直连着，所以这条链接在第一包验证之后，之后这条链接不需要再验证。“第一个包”可能描述不准确，因为有时候第一包不一定就验证，可能是做路由之类。这里就不管这种情况了，只管第一个包直接验证的情况。

    可以理解为server接受到client的链接，并且验证通过（如用户及密码对了）这个client链接后。以后这个client发过来的包，server都直接做逻辑处理而不再需要做验证链接合法性。这个信任是直到链接断开的。

    如果非法客户端来模拟登陆，至少需要得到有效的id及密码，这已经是密码自身安全的事情，不涉及这里谈的链接安全性。

    如果非法客户端用正确的id及密码登陆后，发些非法包，这里的包验证应该是服务器上包处理时的包检查及逻辑检查的事，就是通常的游戏说的防刷（包频率、包里数据的合法范围等）。

二、http的安全验证

    这里只关心http的短连接。

    短连接就是每次建立链接-发包-断开。同一client的前后两次发到server的包，也相当于独立的两次，同一client的验证就需要每个http请求都要验证下。于是有了session和cookie。cookie是将client的标识放在client端，常用于server没有账户密码验证的方式。这里不讨论cookie。

    server在第一个http请求验证client后，给他分配一个session。这个session简单的可以理解为server和client约定的一个client凭证（有有效期）。之后client在每个请求里加上这个session里规定的值，例如一个合适长度的随机字符串。

    这里的session不能有让恶意用户很容易破解的规律，例如用户的id之类的。所以上边提到随机字符串之类的。    

一、回顾

    之前的登陆流程在这篇里。之前的登陆流程简述：

（1）先检查是否同服已登陆，是则两个链接都踢掉，否则进入下步；

（2）判断是否异服已登陆，是则告诉异服踢老链接，随后踢自己这的新链接。否则进入下步；

（3）当前服务器登陆相关流程走完后，向玩家在线列表汇报（写入这个玩家登陆的服务器id为我）。这时的汇报写入为redis的CAS操作，为了检查是否发生了那篇里介绍的同账号瞬间多起登陆事件。CAS操作成功，本服链接登陆完成，做后续操作。否则CAS操作失败，表示瞬时登陆的异服同账号的另一个链接的登陆流程走的快，已经完成整个流程，包括汇报进在线列表。这时的处理只用将慢拍的本服链接关闭就行了。

二、存储架构变为redis+mysql后的问题

    现在玩家上线时需要从mysql加载玩家离线数据到redis，需要考虑这个数据加载放到上边登陆流程哪一步里。

    首先数据加载有可能会失败，如果数据加载出问题，就不能让该玩家登陆。

    如果放到（2）（3）之间，就是redis的CAS之前，这样瞬间同一账号多起登陆都有可能开始进行加载数据步骤，而处理的快的那个客户端就有可能汇报登陆完成之后立即玩游戏并更新了自己在redis里的数据，处理的慢的客户端还这时还在将mysql的数据往redis的加载，会覆盖快的客户端更新的数据。

    如果放到（3）里redis的CAS之后，数据加载失败，就需要回退CAS的操作。

    可见第二种至少可以保证数据正确性。这种情况抽象下，就是第一种里没有提供事务操作的回滚（慢客户端覆盖数据后发现干了坏事却不方便回滚自己的破坏）。

    （2）这个操作当时是为了区分异服登陆并玩游戏很久了和瞬间多起登陆这两种情况的。现在想想这两种情况的处理统一为直接踢掉新旧两个链接也没什么，毕竟瞬时登陆的情况不多。

三、新流程

    根据上边的结论，新的流程为：

（1）先检查是否同服已登陆，是则两个链接都踢掉，否则进入下步；

（2）向玩家在线列表CAS报告自己登陆。如果失败告诉异服踢掉该账号老链接，自己这边踢掉该账号新链接即可。成功则进入下步；

（3）加载数据，成功就进入正常游戏流程。加载失败，就去在线列表里清掉自己。

一、纯redis集群

    如果redis不止做cache，也做持久化，那就得好好算算我们的业务规模需要多少台机器来支撑。1000w注册玩家，每台机器16G内存（为了保证效率取3/4为可用，即12G）。

    如果每个玩家1M数据，总约9765G，不算热备，需要814台机器。每台机器存储1.2w人。

    如果每个玩家16k数据，总约153G，不算热备，需要13台机器。每台机器存储77w人。

    如果每个玩家1k数据总约9.5G，不算热备，需要1台机器。每台机器存储1000w人。

    注册玩家会越来越多的……

二、mysql做持久化，redis做cache

    只说存储，一个mysql支持几T数据没什么问题。例如上边1000w注册玩家，每个玩家1M数据，总数据近9.5T，存一个mysql足够。但是如果高峰在线玩家并发到100w，需要将大部分操作规划到redis这个cache上。否则mysql仍然因磁盘IO太多吃不消。

（一）与纯redis集群相比的劣势

（1）好友需要看离线玩家的信息，而离线玩家在mysql里，如果频繁？

    把离线玩家可能被别人查看的信息不存mysql了，改用redis做持久化。

（2）GM工具改玩家消息，需要改mysql和redis的cache里。会不会容易出问题？

（二）优势

（1）redis只做cache集群了，用twemproxy管理就行了。如果redis做持久化，还是需要自己来分片，且早期就要规划好。

（2）单个玩家的数据涨到1M的时候，总用户涨到2000w~3000w，再加两个mysql。

三、redis做cache+热数据持久化，mysql做冷数据持久化

    这里其实就是将二里边的每个玩家的部分很热的数据从mysql移到redis里做持久化。但是玩家在线时，他的数据基本都算是热的。所以这个方案不是很好设计。

最后、参考

1. redis官方关于分片的文章：http://redis.io/topics/partitioning

2. twemproxy文章：http://antirez.com/news/44

    ​MongoDB为k-v数据库，他们存储方式为BSON，操作接口基本都是JSON，查询，搜索都很方便。

    ​例如mysql里一个表，id和data，data为这条记录的数据，数据为了扩展，例如不同的记录的data可能包含很多字段，且字段不一定相同，以后也会有不少类型的字段。这时我把这些不确定的字段encode成一个xml或者json或者protobuf之类的数据流存到data里。

    ​这么做记录的具体数据关联的详细数据扩展很灵活了。但是想搜索data里的各字段时，在mysql数据库里就不那么方便了，基本要遍历。

    ​这个时候将这个data备份一份到MongoDB里，就很方便了。MongoDB里的每条记录为一个key-value，value即存储我们上边的data。这时我们取data里的字段做条件查询是MongoDB直接支持的。

    ​另外MongoDB支持自动切热备，自动分片等高级功能……

    ​但是另一方面，这个东西出来的不久，现在还不敢将他作为持久化的DB。上边的例子是mysql里有份数据为生产环境的依赖数据，备份到MongoDB的数据只是为了查询。MongoDB里数据出问题是没关系的。

    现在分析的版本为0.7版。pomelo-sync，pomelo里用于解决游戏进程中需要持久化的数据在内存与存储系统之间的同步问题。

一、pomelo程序如何使用pomelo-sync

    新版本的pomelo里增强了支持用户自行扩展的能力。用户只用在app.use(plugin, opts)就可以了，具体请看pomelo的application.js里的use函数。需要这个plugin里有components成员。use函数里，pomelo将plugin的componets所指的组件load起来，并将opts传给这个plugin的components。

    pomelo-sync自身只负责实现db数据与内存数据间的定时同步，所以另一个项目pomelo-sync-plugin就将pomelo-sync封装成了一个componet。app.use(require('pomelo-sync-plugin', opts)就完成了数据同步插件的装载。

二、pomelo-sync

    pomelo-sync在构造的时候，将参数里的client（与持久化层的链接）、mapping（如各种操作的sql语句的映射表）等赋值给自己的相应成员。最后开启定时刷内存数据到持久化层的计时器SyncTimer。

    对外接口不只在dbsync.js里，还分布在lib/commands下的几个文件里。其中exec/flush/sync等在commands/server.js里。

（一）pomelo-sync.exec

    pomelo-sync.exec函数，被用户程序调用。将用户的数据放入pomelo-sync.flushQueue或者pomelo-sync.mergerMap。

（二）pomelo-sync.flush

    pomelo-sync.flush函数，将单挑数据立即持久化。

（二）pomelo-sync.sync

    pomelo-sync.sync函数，被SyncTimer调用，也可以被用户程序调用，立即将全部内存数据持久化。sync函数里调用的是rewriter.js里的sync。rewriter.sync里将pomelo-sync.flushQueue和pomelo-sync.mergerMap里的数据通过rewrite.tick刷进持久层。rewriter.tick里是通过pomelo-sync.mapping里的映射调对应的sql语句来实现的。

    几年前在天龙时，让我很感叹的策划案是，商城的玫瑰道具，玩家可以花元宝买，然后再把玫瑰扔商店得金币，这样维护游戏内的经济稳定。今天又跟现在公司的同事提到这个，为了思路清晰点，再以博客的形式来边仔细想想。

    如果游戏内没有元宝兑换金币的官方途径，玩家最便捷的获取金币的方式，是充值获得元宝，然后拿元宝去找别的玩家交易换取金币。金币的供应量会影响元宝与金币兑换比例。假设元宝与金币兑换比例的正常平均值为100:50，当服务器内金币流动量很小时，例如新服时，兑换比例为100:30；而突然涌入很多刷金工作室，金币供应量变很大，兑换比例变为100:100，这时金币贬值。

    玩家简单分为两种，RMB玩家和非RMB玩家。RMB玩家的需求是，自己的RMB换的元宝买的金币能实现自己的一些装备之类的大提升，就是购买力要强。非RMB玩家（这里指不用外挂，不利用游戏漏洞，正常打金币的玩家）的需求是，自己辛苦赚的金币能多换些元宝。

    当刷金工作室进入游戏后，金币的产生变大了。如果工作室的金币都供应流动起来，金币就贬值了。非RMB玩家利益严重受损，产生挫败感。如果工作室垄断金币市场，金币甚至升值，RMB玩家利益受损。

    这里讨论在打击外挂和打击工作室之外的手段来稳定经济系统。金币流动量突然变大，系统方面可能考虑的是金币的掉落和任务奖励的调低等。反之变少时，提高掉落和任务奖励。或者另一个途径调整道具的价格。这都挺麻烦的。

    现在可以通过玫瑰道具的买卖，来间接进行元宝与金币互兑的后。游戏内玩家间交易的金币升值，要兑换金币的玩家就选择去元宝商店兑换金币。使交易的汇率比商店的稍低。这保证了金币的价格不会高过设定值，从而保证了RMB玩家的利益。

    如果交易的金币贬值了呢？也可以说元宝升值了呢？非RMB玩家需要花更多的钱买同样的元宝。貌似玫瑰花这个道具对这种情况没有什么抑制作用。那到这里的结论是，玫瑰道具只是抑制了金币升值/元宝贬值这个单方面的经济失衡问题。

    （暂时只想这么多，以后有空再补充）

    博客断断续续写了好几年，重拾博客的第一篇是2012年9月19日写的吐槽as3的接口。这一年多每月都坚持写个2、3篇，纪念下。

    这些年在多个地方写过（我的技术博客初衷）， 1年前的决定定在c++博客园了。最近又看到些用github pages写博客的文章，有股搞一搞的暗劲。

    在github写博客的优势就是我一直想要的一个功能，写的文章有版本管理，当自己修改某些文章的时候，看下历史记录就知道修改的原因了。另外隐约感觉github应该比博客园活的久。

    但是放github之后，会有人看吗，搜索引擎能很快收录吗？不得不再次思考自己博客的初衷……

    慢慢去想吧，无论放到哪，一定要坚持更新……

    这一年多也有不少心得和经验没有写到博客里，有的可能是忙完后忘了总结，有时根本都没意识到那个东西挺值得总结的。另外这一年的博客也有些有充数嫌疑，汗，这点慢慢改正。

    特别讨厌很多博客转载别人的文章，所以我的博客里肯定是坚持原创，至少也是一番搜索了解某项技术后的总结（并给出原出处的链接且不赘述人家写完的）。

    一直在考虑要不要写点技术外的东西，例如硬件相关的。想了下，硬件也是程序员的工具（工欲善其事必先利其器）啊，工具又不一定是软件写成的tool，所以以后碰到也可以写点儿。

一、背景和目标

    当年大三的时候写了个五子棋世界，就是qq game那种大厅-房间-桌子（我只有简单逻辑的五子棋）。毕业后一直想找个时间来重构它，后来有次下决心看了下代码，有点儿不知所措，你懂的，：D，还不如重写。

    现在对go很感兴趣，准备用go来实现以前的开源梦。就先已以前的五子棋世界那种休闲游戏平台来开始练手吧。

    目标暂时不定的太大，基本实现大厅-房间-桌子-游戏就行了，慢慢重构慢慢完善。

二、服务器架构

    基本架构参照之前给公司项目做的架构。当架构有改变时，及时修改这篇博客，或者新博客与这篇相互引用和注解。

    不同的部分，加个大厅，大厅里显示房间状态，这样玩家就自己选择闲的房间去玩，这样就不需要做负载均衡的算法了。

（一）账户系统

    游戏自身不做账号密码这种用户系统，只用第三方的账户，如微博账户等来连接到我们游戏。或者更简单点，这块儿只模拟下微博等第三方用户系统的登陆了。

    第三方账户连接到我们游戏，我们本地只由自增长的uid生成器来生成一个int的uid即可，将第三方的platformUid和我们的localUid做个关联映射。

（二）大厅

    大厅可以做成短连接，玩家选择游戏及房间的时候才去大厅刷新下当前的各房间负载情况。

二、客户端

    用walk。（待详细规划）

一、玩家离线

    由于离线的状况多，常见的玩家自己拿自己的账号的离线，也有自己的账号在多个设备来挤掉线，还有就是被非法的人使用时的挤掉线。这里应该将玩家理解为一个账号，下边尽量用账号来表述。

（一）网络断开或者主动离开游戏

    这时玩家所在的服务器在玩家net.close时加入向通信redis汇报的逻辑，即通信redis里删除这个玩家的在线纪录。

（二）同服重复登陆时的kick

    首先肯定要踢掉之前登陆的链接。因为同服时新旧链接都在这个服务器上，逻辑上简单，允许新链接的登陆比较好处理，但是后边有其他考虑。

（三）异服登陆时的kick

    首先也是踢掉之前的登陆。需要在之前登陆到的服务器将该账号的链接断开并整理数据存储之后，才能允许在新的服务器登陆。

    旧服务器清理完该玩家后，向通信redis报告删除该账号的在线状态。新服务器需要知道玩家已经在旧服被kick完了才可以让玩家登陆。刚才同服时提到的允许新链接立刻登陆的问题，这里就变的比较不可控了。美好的过程是，新链接接入后挂起在新服，等异服踢完后，继续做新链接的登陆操作。但是这需要新旧服之间的同步逻辑，需要将新服玩家做个状态机为维护这种挂起或继续登陆状态。另外还要考虑这个期间玩家又在另一个服登陆。要考虑的东西很多……

    还有一种有问题的处理方式，即新服只是向老服发送踢人指令，新服自己却马上进入新链接的登陆操作。这样的问题是，即使业务逻辑简单到不会发生数据不同步问题，但登陆操作不会一定成功。新服登陆完向通信redis报告玩家在线，旧服踢完要向通信redis报告玩家离线。这两个操作异步时，如果旧服的离线报告在后，通信redis上就会错误的记录账号当前不在线……

（四）总结

    最终重复登陆问题简单处理方法：账号登陆时，只要检测到该账号同服或异服已登陆，先将旧链接踢掉，再将新链接断开。就给玩家一个提示“账号已登录，请稍后重试”，让玩家自己来多操作几次，直到旧链接被踢完。

二、同一账号的同瞬间多起登陆事件

    ​上边重复登陆的检查还有一种情况不能防止，就是瞬间的多个客户端用同一账号登陆。同服时由于nodejs的异步，异服时由于天然异步，检查该账号是否已登陆与将当前链接成功登陆并向通信redis报告这些操作不具原子性。

    ​所以在最后向通信redis写入上线状态时再次判断是否已登陆（即判断是否被瞬时并发的另一个客户端的登陆给标记为已上线了）。redis里用hsetnx代替hset，前者在数据已经被设置时操作失败。

​

PS：

    刚接触不久或者本身逻辑就复杂的东西（例如分布式）很多思考的结果不及时记录的话，后边容易忘记当初的理由，导致需要冗余的重复思考。所以现在博客写琐碎些，记载些细节的思考。

一、背景

    项目开始后，先敲定了大体可横向扩展的集群架构（这是个美好的期望），然后开始编写单进程的服务器底层和逻辑，让前边几个迭代周期的逻辑内容配合客户端跑起来了。

    接着就是将单进程的架构扩展起来，设计上细化下架构的扩展。已写在前篇《休闲手游服务器集群扩展思考》里。最近的两周在将之前单进程的服务器架构里部分模块扩展为支持这篇随笔里提到的集群架构。

    实现的过程中碰到的一些需要仔细设计的细节，原则上还是K.I.S.S。

二、全服玩家在线状态

    逻辑服务器集群的负载均衡算法还没实现。先只扩展玩家间的同服通信为异服通信（通过redis的pub/sub，以下将这个用于通信转发的redis简称为通信redis）。

    问题链：（“-->>”引出的下个问题被当前问题所依赖）

        通信发起方需要知道目标方在逻辑集群里的哪个服务器上 -->>

        玩家登陆和退出时往通信redis报告 -->>

        登陆时检查账号是否注册到我们的游戏，否就注册 -->>

（一）登陆和注册

    玩家拿到用户系统的账号来登陆我们游戏服务器。游戏服务器拿client给的这个code再去用户系统服务器做验证，通过后继续。

    检查账号是否在我们游戏注册，如果没有则注册上，映射出游戏服务器上的一个local uid。这里需要检查玩家是否在游戏注册了，所以需要一个platform uid与local uid的映射表。这个映射之前单进程服务器时与其他角色数据放在相同redis上的，现在移到全局类的redis上（以下简称全局redis，暂时是将通信redis和全局redis放一起的，等以后看压测和线上反馈再做演变）。另外用来本地注册生成local uid的自增长id也移到了全局redis上。

    ​检查完注册，得到local uid，先看是否在本服务器登陆了，否则再向通信redis查看是否登陆在其他服务器。如果已登陆，则踢掉之前的登陆。之前单进程只有同服重复登陆踢人，现在多个异服重复登陆的踢人操作。

    登陆成功向通信redis报告local uid和所在的这个logic服务器的server id。另外退出时也向通信redis报告，注销掉这条记录。

（二）异服通信

    每个逻辑服务器都与通信redis建立用于pub/sub的链接，各逻辑服务器有自己的频道。

    异服上的玩家通信时，从通信redis拿到目标玩家所在server id，让后向目标server所对应的专有频道pub数据即可。

三、压测工具

    加了这个集群扩展后，底层测试只是单元测试是不够的。反正要压力测试工具迟早要写，就先写了简单版的压测工具，来做异服通信的自动化测试。

    压测工具开始的想法挺多的，后来抛弃了一些短期不好实现的想法。现在就简单的，一个client一个Client struct，这个处理client的通信发送接收。做相同动作的client为一个Group struct。每个动作为一个Rule struct，里边组合好收到什么包后做什么事情，或者直接发些什么包。

    c++端游压测的每个Rule动作一般用lua来写的，比较方便，我们这个压测工具用go写，rule暂时也用go写，也不麻烦。

    感慨下，这种并行的应用场景，go的编程思维与具体写法比node.js更适合c/c++出身的程序员。

一、目标

    能横向扩展，架构要简单，能做到负载均衡，避免单节点负载太轻的资源浪费。

二、数据存储的DB集群

    ​数据存储类型有多种。

（一）非交互性的个人数据

    ​可通过简单的id分段。id为1~10000的玩家个人数据存储在db1，id为10001~20000的玩家个人数据存储在db2，以此类推。

（二）交互性数据

    ​如好友关系等。

（1）如果好友关系可以为单向，那么可以将关系存到个人数据里。

（2）如果好友关系不能为单向，那么需要保证每条关系保持在要么没有，要么两人都认同，记数据上一直，互相有关系。那么需要保证相关的关系操作的一致性。这样可能只保存一份每两个人之间的关系，k-v存储时需要方向查找，不知是否能实现。

（三）全局数据

    ​如全局排行榜之类的。这种放在单独的库里里，专门做全局数据的存储。当到一定规模时，按全局数据的类型再分库。

    ​家族、帮会等，也放单独的库里。如果需要扩展，再按家族id、帮会id来分库。

三、逻辑服务器集群对DB集群的访问

    ​DB集群的路由规则配置到逻辑服务器的config里。当需要热扩展DB时，启动新DB后，给各logic服务器发送GM指定，reload路由规则的config。

    ​DB集群路由规则的config，可以放在一个公共地方，各logic服务器接到GM指令后，去公共地方拉取新的config然会reload。

四、逻辑服务器集群

    ​为了架构的简单，可以每个逻辑服务器进程上都有所有逻辑，扩展时，以扩展逻辑服务器进程数量来达到。

（一）各逻辑服务器上玩家分配

    ​逻辑服务器集群之间的交互。如果逻辑服务器的使用，也像个人数据存储的DB那样id分段——只让1~10000的玩家登陆logic1，10001~20000的玩家登陆logic2时，这很简单，但各id断的玩家活跃度不定的，做不到负载均衡啊。

    ​所以是根据当时的负载情况，来推荐玩家登陆闲的逻辑服务器的。这样需要有个全局映射，知道哪个玩家登陆在哪个服务器上。可以将玩家当前所在的服务器id记录在该玩家的个人数据所在的db里。

（二）逻辑服务器间的通信

    ​目前项目持久化使用redis，最快出东西，就先考虑redis的优势。

    ​逻辑服务器间的通信，通过全局数据存储的redis来做pub/sub转发吧。

    ​redis的pub和sub的实时性不够时，​将有实时性需求的玩家都转到一个专门做强实时性的特殊逻辑服务器。

五、PS

    ​公司的项目是Node.js+Redis，业余时间打算用Go写个服务器引擎。

    ​这篇考虑发到精华区，可以得到很多的批评建议。

一、为何想学lisp

    ​最初了解lisp是从《黑客与画家》里，里边的黑客强烈推荐程序员用lisp，并有部分讲《为什么lisp语言如此先进？》，书是阮一峰翻译的，这节在他的博客也有节选：

    ​http://www.ruanyifeng.com/blog/2010/10/why_lisp_is_superior.html

    ​总结一下：

a. 越近代的语言越像lisp；而当前最新潮的语言也只是实现了lisp作者在1958年的设想，因为lisp设计目的是数学理论演算而不是语言这种本质上的一种技术。技术会过时而数学不。今天最高级的主流语言，也只是刚刚接近lisp的水平。虽然已经接近，但还是没有lisp那么强大。

b. 等等，其他不一一摘抄。

    ​其中一点提到，“一行lisp代码相当于20行C代码”。lisp会缩短开发周期，而且还是c能做lisp所有事情的前提下。文中举例说，如果你用其他语言跟别人lisp语言的公司竞争，同样的功能你就比别人慢很久才能开发完，竞争就出于劣势。

    ​其他在网络上看到的lisp相关言论：

    ​起名为“格林斯潘第十定律”（Greenspun's Tenth Rule）：“任何C或Fortran程序复杂到一定程度之后，都会包含一个临时开发的、只有一半功能的、不完全符合规格的、到处都是bug的、运行速度很慢的Common Lisp实现。”

二、学习过程中

    ​另外还有个原因，最近想了解函数式编程，想了解下支持分布式原语的erlang，先学哪个还是纠结了下的。 后来考虑到新到的项目中想设计成分布式扩展方便的服务器架构，就优先学下erlang。先花几天把《Erlang程序设计》给看完了，看的很激动，但是考虑到项目人员现状及将来的维护，项目没用erlang，用了node.js。

    之后又花几天把许式伟他们写的《Go语言编程》看完了。go语言确实不错，以后可以考虑用这个写个游戏服务器引擎什么的。本想立即就开动，但是项目属于开始搭架子阶段，需要思考的时间挺多，回家可以利用的时间不多，专心写开源项目不现实。

    ​于是回家的时间先学Common Lisp（以下简称cl），现在正在看田春翻译的《实用Common Lisp编程》，看到12.6映射。

    ​cl很多东西跟类c的语言差别就比较大了，看的进度还是挺慢的。看着看着，一边惊叹他强大的表现力，一边有点害怕太庞大，以后实用起来不顺利。

    ​如果找份cl的工作，国内大小公司估计都不大好找。除非能在一个高手云集的团队里，大家又都喜欢cl，而且我们有话语权……

    ​所以将来cl在为了更好的思考编程之外，很可能只是用来写些脚本或者自己的玩具什么的。近期的应用可能是生成javascript代码。

    ​等cl学的不错了，可以做些个人项目的快速开发……

    ​

三、我了解Common Lisp一些资料

    ​建议一下书籍，按阅读顺序（在知乎看到的，别的地方推荐也大同小异）：
《Structure and Interpretation of Computer Programs》（SICP）可以启发思想，尤其是函数式编程入门；
《Practical Common Lisp》和《Land of Lisp》也适合初学者；
《On Lisp》主要讨论macro的使用；
《Let over Lambda》在《On Lisp》基础上更深入讨论宏。

     ​《On Lisp》和《Practical Common Lisp》（中译为《实用Common Lisp编程》） 由田春翻译完成。我个人先买了SICP，但是里边是讲Scheme，看了几节怕到时学lisp会混乱，就转先实用lisp这本了。

    ​另外我用的实现是Steel Bank Common Lisp。

 四、附上这段时间了解的函数式语言个人简介

    ​这条自己的理解，纯粹为了自己做个笔记。

    haskell貌似比较新，应用不多，别说是分布式，就是普通应用也不多。haskell是纯函数式。而lisp不是纯的，还可以以别的方式来编程。

    ​erlang倒是主打分布式。erlang内置了多台机器之间的通讯原语，程序员只用关心业务逻辑就可以了。

    ​lisp主要是一种全新的看待软件开发的视角。

    ​​go也支持闭包。

一、客户端与服务器的通信

    客户端的通信在pomelo-client里封装了。

    服务器与客户端的通信在connector里。底层提供websocket、tcp和socket.io三种方式的通信。

（一）connector组件（components/connector.js）

    组件构造函数里会this.connector从opts里取connector，或者默认为connectors/sioconnector.js。（connector的实现sioconnector和hybridconnector）

    组件的start里会将this.server\this.session\this.connection分别映射到app的对应的组件上。

    组件的afterStart里this.connector.start，并监听this.connector的'connection'事件。

        'connection'事件处理为：

        将connection关联一个session，监听socket的message事件，接受到message时decode message，再将message交给server组件的handle，处理完回调里再将返回信息在connector组件的send里处理。

        另外监听session的'bind'事件，处理函数为，调用connection.addLoginedUser。

    组件里的send，encode reponse的message，然后交给schedule组件的schedule。

（二）hybridconnector的实现

    connectors/hybridconnector.js以及connectors/hybird。hyrbird实现了原生socket和websocket两种。

    hybridconnector.start里会this.tcpServer=net.createServer，然后把以这个tcpServer为参数创建一个switcher。之后在switcher的'connection'事件里将tcpsocket装进hybridsocket。

（1）hybrid/switcher.js

    switcher构造函数接受一个server参数，并创建this.wsprocessor和this.tcpprocessor。

    switcher监听参数server的'connection'事件，事件处理函数里监听原生socket的'data'事件，判断data是否有http头，如果有，则调用wsprocessor.add，这个add会向外emit 'connection'（事件参数为原生socket），并向socket emit 'data'事件；否则非http，则调用tcpprocessor.add，这个add会以刚才的原生socket为参数创建一个tcpsocket，同时向tcpprocessor emit 'connection'（事件参数为原生tcpsocket）、向这个原生socket emit 'data'事件。

    switcher也监听了this.wsprocessor和this.tcpprocessor的'connection'事件，处理为向switcher自己emit 'connection'。总结，switcher的职责，将socket的字节流data拼成包，以'message'事件向外emit一个个的完成包msg。

    刚才提到的tcpsocket.js这里处理原生socket的操作。监听了原生socket的'data'、'end'、'error'、'close'事件。例如在'data'处理时，当读入的流长度够一个包的body后就向tcpsocket emit 'message'。

（2）hybridsocket.js

    将socket和websocket封装为统一接口。构造函数里接受一个id和socket参数。

    hybridsocket监听tcpsocket的'message'事件，将msg decode，之后处理。例如Package.TYPE_DATA类型的msg，就将这个msg再向hybridsocket自己emit一个'message'事件，其他可能是'handshake'或'heartbeat'事件。

（三）server组件

    官方描述如下“模块使服务器具备处理客户端请求的能力。该模块主要实现了filter服务，根据当前服务器类型，加载对应handler/目录下的代码，并决定一个请求应该是在当前服务器处理还是应该路由给其他服务器处理。”，下面看看代码流程。

    组件的start里初始化filter和handler。

二、服务器之间的通信

三、框架调用

四、session

（一）session组件（components/session.js）

    session组件直接用的common/service/sessionService。

（二）sessionService

（1）Session（object）

    Session里维护的socket和user信息的之间的对应关系。每个socket有个对应的Session，验证用户身份后就将他们绑定。

    Session构造函数接受参数socket id\frontendId\socket\service。

    Session通过bind\unbind函数将uid绑到this.uid里，并emit 'bind'\'unbind'事件。

    Session的set\get函数来给Session设取值，由this.settings维护。

    Session的send\sendBatch都是直接通过构造时传入的那个socket来操作。

（2）MockLocalSession（object）

（3）SessionService（object）

    负责对Session的管理。构造函数里将this.sessions和this.uidMap初始为空表。

    SessionService的create负责new Session，并放到this.sessions里。

    bind\unbind函数负责将传入的sid\uid对应绑定到this.sessions\this.uidMap里。uidMap里每个元素是个数组，所以每个uid可以对应多个session？（这个以后再具体了解下）

    sendMessage\sendMessageByUid根据sid\uid往对应的session或sessions发消息。

    其他函数不一一列举了。

（三）session的使用

    看了下chatofpomelo里，是在connector/handler/entryHandler.js里的enter函数，直接用了session.bind。简单用法就是在自己项目的验证uid后自己绑定。

五、pomelo-rpc

（一）rpc-client

    client.create\mailstation.create\mailstation.mailboxFactory挂载mailbox\

    client.start(callback)\mailstation.start&callback

    client.addProxies(remote-calls)\proxy.create\

（二）rpc-server

    lib/rpc-server/server将远程调用处理下，加到opts.services里，然后通过gateway来listen端口和处理message。

    由于才接触nodejs几天，看源码时各种细节和设计方法都得熟悉下。结合chatofpomelo-websocket，先从pomelo的使用入口开始看。

一、chatofpomelo的开启流程

    Pomelo.createApp出来Application，然后Application.start就开启了。

    createApp时会调Application.init来做初始化。

    init里调AppUtil.defaultConfiguration来读入默认配置。例如从master.json里读入master配置（Application.master），从servers.json里读入服务器集群各进程的type、host和port配置（可以通过Application.get("__serverMap__")获取）。

二、组件的挂载

    组件放在components目录下。各组件可以通过Pomelo.components或者直接通过Pomelo来按名取。也可以通过Application.components来按名取（每个组件的名字在自己的name属性里，通常为js文件名加前后双下划线，例如connector.js的组件名为“__connector__”）。

    下面看下组件的挂载和运行。

    Pomelo里会遍历componets目录里的各个js文件，然后require到Pomelo里和Pomelo.components里。

    Application.start里先调用AppUtil.loadDefaultComponents，loadDefaultComponents里会根据Application.serverType来Application.load需要的components。

    Application.load里会将Pomelo里的components放到自己的components里。

    Application.start/stop/afterStart等方法会统一执行各components里的对应start/stop/afterStart等方法。

三、ps

    ​这篇发表后，在google里搜了下（我的一点恶趣味：经常发表随笔后会看看搜索引擎收录了没）“pomelo 源码分析 组件”，发现了pomelo官方wiki里关于组件的说明，奇怪之前准备看组件时没搜到。分析源码之前也浏览了下官方wiki，应该是偏向于了解大概了，各细节没了太大印象。

    ​不过官方已经有了也没关系，随笔给人参考的价值变小后，就当自己的笔记吧。

    ​另外网上也有些pomelo的源码分析了，但是看了眼，跟我想要的不太一样。

附官方组件wiki：

1. Pomelo-Framework里的组件部分：https://github.com/NetEase/pomelo/wiki/Pomelo-Framework

2. Pomelo-组件：https://github.com/NetEase/pomelo/wiki/Pomelo-%E7%BB%84%E4%BB%B6

一、node.js能做啥

    http://www.infoq.com/cn/articles/what-is-nodejs

二、杂项问题

1. http的长连接是不是也是只能req/rep模式，能实现服务器端push吗？

    http的长连接即HTTP keep-alive（HTTP1.1里加入），这个原生的只是为了更少的建立和关闭tcp链接，可以减少网络流量；因为已建立的tcp握手，减少后续请求的延时等。这个http长连接不支持全双工通信。

    http实现“服务器推”的技术，一是借助客户端Flash XMLSocket或者Java Applet套接口来实现；另一种是comet技术。（还有一种遭罪的客户端以一定间隔向服务器发出请求的轮询就不提了）

    comet有两种：

        （1）基于AJAX的长轮询（long-polling技术）

        （2）基于 Iframe 及 htmlfile 的流（streaming）方式

    这两种方式看描述已经离手游服务器差远了，就不去招惹它们了吧。

2. 大规模网站的架构？怎么做到水平扩展的？

    网站的需求跟游戏不一样，网站都是http就够了，req/rep即可，没有交互等广播同步之类的复杂状态。

    （pomelo里表示游戏的业务模型很难做到传统网站那种无限水平扩展）

3. websocekt是什么？

    html5开始提供的，为了使浏览器和服务器间进行全双工通讯的长链接协议。websocket协议本质上是一个基于TCP的长连接协议。与传统C/S长连接的区别在于，websocket链接开始时的握手协议，客户端首先要向服务器发起一个HTTP骑牛，这个请求和通常的HTTP请求不同，包含了一个附加信息"Upgrade:WebSocket"表明申请协议升级，服务器回应后，即握手完成，websocket链接建立起来，双方自由通信，直到一方关闭链接。

    websocket相对于http的优点，除了全双工通讯，还有服务器与客户端交换的header信息很小。

    websocket与传统socket的区别，前者有帧协议，不需要上层做拼包了。

4. redis可以直接搞集群吗？

    数据量太大时，redis的持久化会影响性能，解决方案时用个slave专职做持久化。另外redis容灾和传统web应用的减压，就开多个slave，用于分担读的压力。

    当库到一定数量时，可以用分库分表来水平扩展。 

5. node.js能用c++扩展吗？

    v8和node都是c++写的。

三、网易pomelo能干些啥

    分布式服务器，方便扩展。另外实现了很多游戏常用模块，如aoi等。

四、公司的node.js框架有哪些不能做的

1. websocket实现了吗？

    实现中。

2. 方便分布式扩展吗？

    貌似没有pomelo那么方便。 

五、总结

    ​node.js做手游服务器的开发还是挺方便的，pomelo已经做很多事情……

N、参考

1. Comet：基于 HTTP 长连接的“服务器推”技术：http://www.ibm.com/developerworks/cn/web/wa-lo-comet/

2. WebSocket：http://zh.wikipedia.org/wiki/WebSocket

3. 使用 HTML5 WebSocket 构建实时 Web 应用：http://www.ibm.com/developerworks/cn/web/1112_huangxa_websocket/

4. pomelo：https://github.com/NetEase/pomelo

5. HTTP长连接：http://www.blogjava.net/xjacker/articles/334709.html

6. Redis复制与可扩展集群搭建：http://www.infoq.com/cn/articles/tq-redis-copy-build-scalable-cluster

一、需求

    我方游戏服务器为一套nodejs框架下开发的，手机App前端为javascript。现在需要将游戏接入facebook，要求能用facebook登陆我方游戏，并可以取到玩家的facebook好友等信息、可以向好友送礼，还可以向玩家facebook增加游戏状态。

    如果为前端接入，需要封装出js的接口。

二、接入方式

    需求里涉及到了玩家间的利益交互，如这里的可以向好友送礼。需要确认游戏里这些利益交互（现在的利益可能较弱，但需要考虑将来的利益交互规划）被外挂刷后是否对游戏有影响。

    如果影响较大，例如刷了很多物品，让游戏失去平衡——RPG里可能是装备特牛，休闲游戏可能是道具很多，更有利于冲击排行榜等。就需要将facebook的接入方式定为server-side接入。如果影响较小，就无所谓，可以像单机游戏那样在前端做接入，facebook的好友信息等由前端传到我们服务器。

（一）server-side接入

    官方的https://developers.facebook.com/docs/sdks/ 里收录的第三方nodejs的sdk在https://github.com/amachang/facebook-node-sdk。

    这种是nodejs开的本地网站，然后本地网站可以开个网址做facebook的接入验证，之后取玩家的facebook信息，可以调封装好的facebook API。效果可以开代理看下http://claw-fb-off.herokuapp.com。

    但是不知我们服务器的nodejs和前端App的js之间是否支持这种网页式的交互。咨询了nodejs框架组的同学，表示不行，我自己没做过这方面的东西，所以还是要请游戏组同学看看。

    另外咨询了众多项目组，做过接入的都是前端接入，还没有做过server-side接入的。

（二）client-side接入

1. 官方提供native IOS和Android API的SDK。

2. 另外也提供javascript SDK（https://developers.facebook.com/docs/reference/javascript/），貌似也是网页形式，不知我们前端是否支持？

3. EziSocial-Plugin为C++编写，但是这个是收费的，游戏组确认要用吗？

    ​https://github.com/yangsf5/claw-gse/blob/master/src/claw/gse/top_n.h

    ​​

    ​项目里shared memory存放的数据结构，现在需要将其同时用于server与client之间的相应数据交互。server与client之前的协议格式为protobuf。

    ​为了只维护一份代码，准备将之前用于shared memory的结构转化为protobuf，然后两处都用这个protobuf。

    ​搞了一会儿，才想起shared memory里只适合存定长的非指针结构。

    ​汗，这个几年前就经历过，那个时候是学生时代做五子棋世界的时候，貌似是想往shared memory里存放std::map。

    ​当时水平太低，报错了就放弃了stl的容器，写些了中规中矩的结构体。

    ​这次就顺便搜下当年那个问题的解决方法。找到个说的挺好的：http://www.cnblogs.com/fullsail/archive/2013/01/20/2868898.html。

    ​大意就是，stl里容器会动态分配内存，而且new的东西在自己的进程空间里，别的进程访问时必然是个不对的指针。需要将stl的分配器定制为从共享内存里分配空间，或者其他几个链接里提到的方法。

    ​回到我现在遇到的protobuf这个问题，protobuf里有些如repeated或者string等会动态new，这个如果做内存分配的定制，还得重改protobuf的代码，复杂度比较高。

    ​加上项目里的这单个协议格式制定的需求只是临时的，就更没必要了。最终放弃protobuf结构直接映射到共享内存的企图。

    ​

    自己工作机在vc点incredibuild编译时总是显示fail to create process，周围同事却都没问题。这里记下解决的过程。

一、fail to create process

    ​这个错误提示，第一反应就是用户没权限，查看了用户之后，提示这个用户就是管理员。后来各种倒腾都无果。

    ​权限的问题一时没解决，想别的办法……

    试出一个办法：点开任务栏右下角的IncrediBuild Agent，右键选择Build->open后打开的Batch Build里编译是完全没有问题的，没有那个创建进程失败的问题。

     ​所以想，是不是因为vc的插件运行时的编译配置有问题，而在Agent独立进程里的Batch Build里的编译配置比较纯净（例如不用搞那个cmake之类的检查）。

    于是找到Agent开启Batch Build时的进程为BatchFile.exe，但是在自己写的bat里单独启动BatchFile，启动后弹出Batch Build，选择编译后却也还是创建不了进程错误。

    偶然在vc的工具栏的IncrediBuild选项里也发现了Batch Build选项，弹出的Batch Build也是不能创建线程。再次扫兴。

    ​所以想，是不是因为做为vc的插件和bat里启动运行时没有创建进程的权限。而在Agent独立进程里运行时能拿到权限？

    ​最后某此搜什么东西，憋见一个说法，“右键菜单win7管理员身份运行”。如果就特么搞定了。 

    解决办法大概是：win7启动vc时以管理员身份运行，程序鼠标右键有那个选项。另外也可以看看快捷方式里设置。之后从vc里load你的项目。更方便的是将你的vc程序，打开属性的兼容性标签，特权等级里勾上以管理员身份运行此程序。（设置之后我在TC里不能直接双击启动**.sln，只好右键选择vc来启动）

    ​随后想是不是TotalCommand里起的进程没管理员权限，后来试了试不是这样的……

    ​总结，我的win7用户不是真宗的管理员，虽然控制面板里提示了是！

二、其他问题

    ​有时编译完后不能自动stop build，还得手动点。

    ​这个看看进程管理器里好多僵死的build相关进程，全干掉。

   单步到崩溃地点，有数组取数据和拷贝操作，猜测数组越界导致的栈溢出。就开始找越界检查工具。

    vs自身带的/GS只是在栈溢出时蹦个异常，不会给你定位崩在哪。所以找了会儿别的工具，boundschecker还没找到下的地方，IBM的purify跨平台但是收费，另外免费好用的就是linux下的valgrind了。这几种内存检查工具都可以检查内存泄露和越界之类的。只是项目现在赶进度，linux平台的编译还没时间解决，内存统一检查就作罢。

    开始看看能不能查dump。dump不是原生的dmp而是历史代码里重存为别的了。vc调试不很熟练，就索性把重存dump那块儿的catch给干掉了。直接让编译器崩到代码块儿再看看能不能看出什么问题。

    崩停到具体代码行了，很惊喜，赶紧看看各变量内存状况，问题数组是一个指针数组，这次惊喜的发现之前单步的那个下标对应在数组元素指针跟别的不一样，为0xcdcdcdcd，确认了下为vc下为未初始化的指针。

    这样就好查了，问题定位到了，后边的就不啰嗦了。

    最终问题是，同事给一个类新加了几个指针成员，但是这几个没有new出来初始化之。唉……只能感叹下敏捷开发那本书里说的，架构师要参加编码，我觉得要加点儿，就是架构师要参与编码还要参与测试调试自己的代码。

    初步调试，发现某个类的构造函数进了，但是在左花括号的地方就卡住了，没有往后走。

    一开始挺惊奇，过会儿就想到，类的构造函数里会被编译器插入一些没有显示初始化的成员的初始化语句。所以讲F10改为F11调试。

    慢慢似乎找到问题函数了，正准备再重开调试继续跟时，朋友表示按下vc的暂停键，照做，“我擦——”之后是崇拜的口水。

    问题原因：while的退出变量没有自增，导致死循环了。

    总结：

        程序卡在哪儿，基本就是死循环或者死锁。死循环的发现，可以看cpu占用来佐证。问题定位，暂停调试。

        死锁的定位，可以看stack，里边应该有wait之类的。

二、msvc
1.【msvc调试】server初始化时卡在某个点：http://www.cppblog.com/yangsf5/archive/2013/06/21/201195.html

三、golang

1. json文件映射到内存失败

    json文件里的字符串必须用双引号。官方标准json的字符串就只能双引号，只是js这种允许单引号，所以之前js的程序里可以解析单引号的json配置文件。

1. 链接libprotobuf.lib时，报与系统某库冲突，vc建议忽略系统库。这个有可能会出现别的问题。解决办法就是将protobuf的编译“运行库”设置和自己工程的设置成同一个，例如均为/MDd时就ok了。

   这个还是linux下gcc舒服。

2. IncrediBuild编译问题：http://www.cppblog.com/yangsf5/archive/2013/06/25/201288.html

3. Debugging information for *.exe cannot be found or does not match：

    ​​http://www.cnblogs.com/ustcwhc/archive/2012/04/05/2432829.html

一、简介

    这个项目刚起步，将来有可能会演变为公司的服务器框架。博客里暂且称呼为X项目。

    语言为c++，之后将此服务器的设计演变尽量记录下来，为一个系列，以“X项目C++服务器”为统一标题开头。

二、架构设计

（一）多进程通信方案

    zeromq

（二）协议方案

    protobuf 

（三）存储

    redis

（四）脚本

    luaplus

（五）日志

    glog

三、自动构建部署

    自动构建等为敏捷开发提供保障。

    之前经历的那些项目（其中包括业内比较有名的2个大型项目）在自动构建部署方面基本为0，开发效率不高，这次新项目准备从一开始就做这方面的准备。

（一）单测

    单测框架考虑google的gtest。

一、预编译头

    当工程大了，单机编译速度会很慢。预编译头会提高很大的速度。相关原理这里不赘述，网上很多。（或者老夫有空的时候再补充）

​

二、cmake设置gcc的预编译头

    一开始google到一个国内同行写的cmake宏，用了下，貌似不是很好用。另外作者也表示还是有bug。

    后来找到cotire。目前使用良好。

三、cotire（compile time reducer）

    项目地址https://github.com/sakra/cotire。具体使用方式github里对应项目主页已经写的很清楚了（主页man看不明白的可以去看他的src里那个例子），这里只做下快捷备忘。

    步骤：

1. clone这个git。

2. 将cotire里的CMake/cotire.cmake拷到咱们自己工程的顶层CMakeLists.txt同级目录下。

3. 往这个顶层CMakeLists.txt里设置一个变量并include：

    set (CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/CMake")

    include(cotire)

4. 在具体的CMakeLists.txt的add_executable后边再cotire下，如：

    ​add_executable(MyExecutable ${MyExecutableSources})
    ​target_link_libraries(MyExecutable ${MyExecutableLibraries})
    ​cotire(MyExecutable)

5. 上边是自动寻找预编译头，也可以自己设置，例如我们从vc跨平台过来的项目，显示设置stdafx.h，只用在cotire前边设置下即可：

    ​set_target_properties(MyExecutable PROPERTIES COTIRE_CXX_PREFIX_HEADER_INIT "stdafx.h")
    ​​cotire(MyExecutable)