《高效程序员的45个习惯》读书笔记【思维导图】

《高效程序员的45个习惯》这是一本好书,书中的观点直白、朴素,极富实践性!当然最重要的,还是要在实际项目中身体力行!

下面摘取书中要点,花了大半天时间做成思维导图,以方便随时查阅。

高效程序员的45个习惯

1 宣言

1.1 个体和交互胜过过程和工具

1.2 可工作的软件胜过面面俱到的文档

1.3 客户协作胜过合同谈判

1.4 响应变化胜过遵循计划

2 原则

2.1 (一)态度决定一切

2.1.1  做事

1)指责不会修复Bug,把矛头对准问题的解决办法,而不是人

2)一个重大的错误应该被当作是一次学习而不是指责他人的机会

2.1.2  欲速则不达

1)不要坠入快速的简单修复之中,要投入时间和精力保持代码的整洁

2)不要让开发人员孤立的编写代码

3)阅读代码的频率越高越好

4)代码复审不仅助于代码更好理解,也是发现Bug最有效的方法之一

5)防止代码难懂的重要技术就是单元测试

6)所有大型系统都非常复杂,没有一个人能完全明白所有代码,除了深入 了解所负责的那部分代码,需要从更高层面来了解大部分代码,理解系统 各个功能块之间是如何交互的

7)实际工作中,可以先快速修复问题,即为了应对紧急情况,但事后一定好细致分析

2.1.3  对事不对人

1)询问你的队友,并提出你的顾虑

2)礼貌待人,负面的评论和态度会扼杀创新

3)必须把重点放在解决问题上,而不是极力证明谁的主意更好

4)能容纳自己并不接受的想法,表明你的头脑足够有学识

5)设计充满了妥协,工作中不感情用事是需要克制力,展现成熟大度来

6)团队能公正地讨论一些方案的优点和缺点

2.1.4  排队万难,奋勇向前

1)动手去做比光抱怨好得多

2)当发现问题时,不要试图掩盖问题,要诚实、勇敢说出实情,并与团队一起寻求好的解决办法

2.2 (二)学无止境

2.2.1  跟踪变化

1)迭代增量式的学习:每天计划用一段时间来学习新技术

2)了解最新行情:阅读博客、maillist等

3)参加线下技术活动

4)参加研讨会议

5)阅读好书

6)不需要精通所有技术,但要清楚知道行业的动向

7)明白为什么需要这项新技术,它试图解决什么样的问题?它可以被用在什么地方?

2.2.2  对团队投资

1)一个学习型的团队才是好的团队

2)每周要求团队中的一个人主持讲座,介绍新技术、工具或者书籍

3)坚持有计划有规律地举行讲座:持续、小步前进才是敏捷

2.2.3  懂得丢弃

1)学习新技术时,多问问自己,是否还在沿用旧的态度和方法

2)新技术会让人感到一点恐惧,但你的确需要学习它

2.2.4  打破砂锅问到底

1)为了解决问题,你需要知道许多可能的影响因素

2)当找人询问任何相关的问题时,让他们耐心地回答你的问题

3)不能只满足于别人告诉你的表面现象,要不停地提问直到你明白问题的根源

2.2.5  把握开发节奏

1)许多不成功的项目中,基本上都是随意安排工作计划,没有任何的规律

2)敏捷项目会有一个节奏和循环,让开发更加轻松

3)最大的节拍就是迭代时间,一般是1-4周,确保每个迭代周期的时间相同很重要

4)项目开发需要有一致和稳定的节奏

5)在每天结束的时候,测试代码,提交代码,没有残留代码

6)不要搞得经常加班

2.3 (三)交付用户想要的软件

2.3.1  让客户做决定

1)开发者需要知道哪些是自己决定不了的

2)具体到游戏行业,客户分两类,一类是项目策划,他们是需求的提出者 故在设计开发前,需要与之作深入的沟通,明确他们的意图;一类是玩家, 他们是最终使用者,开发者可以站在玩家角度去分析策划案的价值和作用

2.3.2  让设计指导而不是操纵开发

1)时刻谨记,此阶段提出的设计只是基于你目前对需求的理解 而已,一旦开始了编码,一切都会改变

2)敏捷开发中,少用文字,多用图表来表达设计意图,常用序列图和类图

3)设计满足实现即可,不要过于详细

4)好的设计就是能适应变化的需要

5)先设计类的职责,再设计其方法和数据类型

1.类名

2.职责:应该做什么

3.协作者:要完成工作它要与其他们什么对象工作

6)白板、草图、便利贴都是好的设计工具,复杂的建模工具只会让你分散精力

2.3.3  合理的使用技术

1)这个技术框架真能解决问题吗

2)你将会被它拴住吗

3)维护成本是多少

4)不要开发你能下载到 东西

5)首先决定什么是你需要的,接着为这些具体的问题评估使用技术

2.3.4  保持可以发布

1)提交代码流程

1.确保自己编写的代码通过单元测试

2.检出最新代码,并再次运行测试

3.提交代码至版本管理服务器

2)持续集成系统就是在后台不停地检出、构建和测试代码的应用

3)保证你的系统随时可以编译、运行、测试并立即部署

4)如果不得不让系统长期不可以发布,则需要做一个分支版本

2.3.5  提早集成,频繁集成

1)决不要做大爆炸式的集成

2)代码集成是主要的风险来源,提早集成,持续面有规律地进行集成则可避免

3)集成和独立不是互相矛盾的,可以边进行集成,边进行独立开发

2.3.6  提早实现自动化部署

1)一开始就实现自动化部署应用

2)在不同的机器上用不同的配置文件测试依赖的问题

2.3.7  使用演示获得频繁反馈

1)每隔一周或两周,邀请所有客户,给他们演示最新完成的功能,积极获得他们的反馈

2)用Bug系统记录跟踪所有系统Bug

3)在游戏项目里,每完成一个迭代版本,尽早给策划同事及制作人演示,甚至在整个项目组测试演示 ,并收集大家反馈的Bug和建议

2.3.8  使用短迭代,增量发布

1)迭代开发是在小且重复的周期里,完成各种开发任务:分析、设计、实现、测试和获得反馈

2)游戏项目中,迭代时间最好是以一周为单位

2.3.9  固定的价格就意味着背叛承诺

1)需要根据业务复杂度、团队成员的能力水平、市场环境就诸多因素来评估项目的开发周期 这是一件很考验管理者(包括开发者)的经验与技术水平

2.4 (四)敏捷反馈

2.4.1  守护天使

1)敏捷就是管理变化的,而代码则是变化最频繁的东西

2)所谓守护天使即自动化的单元测试+后台自动构建

2.4.2  先用它再实现它

1)编程之前,先写测试

2)先写测试可以站在用户的角度来思考,并有利于消除过度复杂的设计

3)使用TDD作为设计工具

2.4.3  不同环境,就不同问题

1)在各种支持的平台和环境中运行测试用例

2.4.4  自动验收测试

1)为核心业务创建验收测试用例,这不同于单元测试

2)在游戏项目中,要分别为客户端和服务器创建验收用例,客户端侧重于表现效果验收, 服务器侧重于业务逻辑验收

2.4.5  度量真实的进度

1)每个工作日,团队成员要重新评估完成一个任务还需要多少小时

2)我的做法是每天在上班的路上想好当天要做的事情,在正式开工前,用google日历列出一天的任务列表, 列表的条目是具体可操作的工作,粒度的划分需要一定的经验,评估完工时间的单位是小时

2.4.6  倾听用户的声音

1)没有愚蠢的用户,只有自大的开发人员

2)每一个抱怨的背后都隐藏一个事实:找出真相,修复真正的问题

2.5 (五)敏捷编码

2.5.1  代码要清晰地表达意图

1)代码清晰程度的优先级应排在执行效率之前

2)编写清晰的而不是讨巧的代码

2.5.2  用代码沟通

1)不要用注释包裹你的代码

2)注释包含的信息:目的、输入、输出、异常,使用RDoc、javadoc、ndoc工具规范化注释

3)注释要说明为什么写代码,而不是解释代码做了什么

2.5.3  动态评估取舍

1)考虑性能、便利性、生产力、成本和上市时间,如果性能足够,则将注意力放在其他因素上

2)过早的优化是万恶之源

2.5.4  增量式编程

1)如果不对自己编写的代码进行测试,保证没问题,就不要连续几小时编程

2)写了几行代码之后,可以进行一次构建/测试循环,在没有得到反馈前,不要走太远

2.5.5  保持简单

1)除非有不可辩驳的原因,否则不使用模式、原则和高难度技术之类的东西

2)简单的解决方案必须要满足功能需求,不要过分简单

2.5.6  编写内聚的代码

1)要避免创建很大的类或组件

2)考虑实现一个简单的功能变化需要变更多少代码

2.5.7  告知,不要询问

1)开发人员绝对不应该基于被调用对象的状态做出任何决策,更不能去改变该对象的状态, 这样的逻辑应该是被调用对象的责任,而不是你的,即符合依赖倒置原则

2)要将功能和方法分为“命令”和“查询”两类

3)用发送消息或事件来代替调用函数

2.5.8  根据契约进行替换

1)通过替换遵循接中契约的类,来添加并改进功能特性

2)多使用委托而不是继承

2.6 (六)敏捷调试

2.6.1  记录问题解决日志

1)维护一个保存曾遇到的问题以及对应解决方案的日志

2)记录发生问题时应用程序、应用框架或平台的特定版本

2.6.2  警告就是错误

1)找到一种方式让编译器将警告作为错误提示出来

2)解释性语言通常也有标志,相用相关标志,然后捕获输出

2.6.3  对问题各个击破

1)不要试图马上了解系统所有细节,要想认真调试,就必须将有问题的组件或模块与其他代码分离出来

2)用原型进行分离

2.6.4  报告所有异常

1)处理或是向上传播所有的异常

2)不是所有的问题都应该抛出异常

3)报告的异常应该在代码的上下文中有实际意义

4)记录运行日志

2.6.5  提供有用的错误信息

1)提供详细的运行日志,记录运行状态

2)区分错误类型:程序缺陷、环境问题、用户错误

2.7 (七)敏捷协作

2.7.1  定期安排会面时间

1)立会:大家到公司的30-60分钟进行

1.昨天有什么收获

2.今天计划要做哪些工作

3. 面临着哪些困难

2)立会时,只能给予每个参与者很少的时间发言,如:两分钟

3)采取立会的形式需要管理层的承诺和参与

4)立会时间不要超过30分钟,10-15分钟比较理想

5)立会时,要注意报告的细节,只给出具体的进度,但不要陷入细节之中

2.7.2  架构师必须写代码

1)作为设计人员,不能理解系统具体细节,就不可能作出有效的设计

2)只通过一些高度概括的、粗略的设计图无法很好地理解系统

3)鼓励程序员参与设计,优秀的设计从积极的程序员那里开始演化

2.7.3  实现代码集体所有制

1)在团队中实行任务轮换制,让每个成员都可以接触到不同部分的代码

2)注意有些场合是不能采用代码集体所有制的,这时候,人多了反而容易误事

2.7.4  成为指导者

1)教学相长

2)分享自己的知识、经验和体会

2.7.5  允许大家自己有办法

1)作为指导者,应该鼓励、引领大家思考如何解决问题

2)用问题来回答问题,可以引导提问的人走上正确的道路

2.7.6  准备好后再共享代码

1)绝不要提交尚未完成的代码

2)完成一项任务后,应该马上提交代码

3)保证所有代码通过单元测试

4)使用持续集成是保证源代码控制系统没有问题的一种良好方式

2.7.7  做代码复查

1)代码刚完成时,是寻找问题的最佳时机

2)让不同的开发人员在每个任务完成后复查代码

3)运用静态代码检查工具,如:Similarity Analyzer、Jester

4)注意每次复查的代码量不宜过大,保持每次在1k Line以下

5)代码复查内容

1.代码能否被读懂和理解

2.是否有任何明显的错误

3.代码是否会对应用的其他部分产生不良影响

4.是否存在重复代码

5.是否存在可以改进或重构的部分

2.7.8  及时通报进展与问题

1)发布进展状态、新的想法和目前正在关注的主题,不要等别人来问题项目状态如何

2)每日立会让每个人都能明确了解最新进展和形势

3)可以作日报和周报来反馈项目进度

3 工具

3.1 Wiki

3.2 版本控制

3.3 单元测试

3.4 自动构建

4 宗旨

4.1 以人为本

4.2 团队合作

4.3 快速响应变化

4.4 可工作软件

5 核心:Just Do It!!!

【声明:若有摘录,请注明来自http://gameislife.info/archives/133】

每月自评之一:2013年1月

(一)我读
     本月阅读过的书籍:

     (1)《程序员的职业素养
          1)推荐指数:四星
          2)简评:Bob大叔的职业生涯经验总结,现身说法,可信可敬!
     (2)《Lua游戏开发实践指南
          1)推荐指数:三星
          2)简评:想用Lua作游戏脚本开发的同学值得一读!
     (3)《Unity3D游戏开发技术详解与典型案例》
          1)推荐指数:二星半
          2)简评:U3D引擎基础开发技术要点全览,虽全但不够深!
     (4)未阅读完书目列表
          1)《中国文脉》、《第五项修炼》、《唐浩明评点曾国藩家书》
(二)我看
     本月看过的电影:
     (1)《时空线索 Deja Vu
          推荐指数:三星半
     (2)《人再囧途之泰囧
          推荐指数:三星
     (3)《普罗米修斯 Prometheus
          推荐指数:三星
     (4)《城中大盗 The Town
          推荐指数:三星半
     (5)《洛城机密 L.A. Confidential
          推荐指数:四星
          推荐指数:四星半
          推荐指数:四星半
(三)我听
     本月新收听过的各类音视频资料:
     (1)【Unity3D引擎开发介绍】
          公司GDOC论坛上,技术牛人同事hover的精彩分享
     (2)【静雅思听】
               在podcast上收听这个节目,收获各类人文知识
     (3)【东吴相对论】
               在podcast上收听,在谈话中获益
     (4)【晓说】
               听高晓松在优酷上的Talk Show,过瘾!既长见识,又引人思考
     (5)【锵锵三人行】
               podcast上收听,听窦文涛同学各种闲扯
     (6)【我是歌手】
               去年浙江卫视的【中国好声音】有些虎头蛇尾,今年湖南卫视的这档节目看了前三期,第一期在看到七位神秘歌手现身时最过瘾,节目有创新,持续关注后续的创新点。BTW,再见齐秦,让我百感交集!
     (7)《建一只强大的小团队
          由来自亚马逊的中国研发经理陈皓兄的分享,看似偏激,却很有道理,跟我的管理理念很相符
          由来自Apach开源社区的快奔四的方越大哥的分享
(四)我用
     本月新使用的软件工具:
     (1)ReSharper
          用C#写U3D脚本时使用了它,在一个Team多人开发时,可用它统一规范组内的编程规范,另外,它还可以帮助在写代码时,作一些适度的重构
     (2)XAMPP
          用wordpress搭建个人blog时用到了它,先用它在搭建本地服务器测试环境,果然是利器,很傻瓜,很强大,很好用!
(五)我藏
     本月摘录收藏的各类帖子和文章:【72篇】
     (1)Unity3D:36篇
     (2)C#:5篇
     (3)Lua:3篇
     (4)敏捷开发:2篇
     (5)服务器架构:3篇
     (4)开源:2篇
     (5)行业观察:5篇
     (6)产品:5篇
     (7)游戏引擎:4篇
     (8)通用编程:4篇
     (9)Web:2篇
     (10)算法:3篇
     另外,收录下面两个开源组件:
     (1)【pomelo】
          密切关注网易公布的这个开源服务器框架,并在2月份安排时间来研究学习其源代码,顺便学习JavaScript和node.js
     (2)【SPP(SNG通用逻辑层框架)
          公司内部开源的一个服务器逻辑框架,在2月份安排时间来研究学习其源代码
(六)我做
     (1)新项目完成年终前的里程碑版本
     (2)搭建完成个人独立blog,作为长期记录个人成长、所思所想之地
          1)使用流行的WordPress作为网站框架
          2)在godaddy上申请独立域名,一年不到3$;
          3)用的衡天小张代理的香港主机空间,一年150RMB,300M空间,每月6G流量,差不多够用了,既省却了备案的烦恼,也比美国主机快一些;
(七)我玩
     (1)NBA2K13+NBA2K online
          体验NBA2K13的各种模式,做得真的不错!
(八)我思
          新年的第一月转眼即过,如果你不去记录,你的生活和周遭发生的一切,都会让你浑然不觉!因此,新年伊始,即较为严格地按新年计划来执行,所幸的是,能在工作之余抽出时间来充电:读喜欢的书、看喜欢的电影、玩喜欢的游戏;不幸的则是,依然独自一人在外地工作,不能陪在怀有身孕的老婆身边,而偏偏这个月家里发生了诸如装修新房、除臭虫等琐细家务事,可怜老婆挺着大肚子上下奔波,虽然有我妈在一旁照料,但终归还是由老婆一个人来面对处理。而千里之外的我,唯有电话叮嘱,却丝毫无能为力,念及于此,愧疚难当!幸好,过年在即,再过两天,就可以回家陪伴家人,年后也有一段时间陪伴照料老婆,并且一起企盼着小宝宝的健康出生,初为人父,当然兴奋莫名:)
          另外,这个月跟大宝和Peter的交流,也让我获益良多!大宝对于游戏运营的理念,Peter对于游戏制作人所备五项技能的理解,我都深以为是。
          在工作室年会上,同事konthiga的发言深深引起了我的共鸣!游戏开发的确是一项脑力消耗和体力消耗都十分惊人的工作,这个行业的竞争状况远非传统行业所能比,甚至,我认为它是互联网行业竞争最残酷的一个分支,各种热钱都往里砸,各种人才都往里跳,而且,它还是天朝为数不多的全球性的竞争行业。如此种种,都对身处这个行业的人,提出了更高的要求。因为,指不定,短则1-2年,长则3-5年,行业就会发生巨大的变化,其时,你的饭碗能不能保住都很难说。更何况,你还残留一些理想,在这其中实现你小小的童话:)
          须知:在不惑之前,尚能做出几款游戏?能成功者,又有几何?
【声明:若有摘录,请注明来自:http://gameislife.info/archives/121】

WebGame游戏开发现状浅析

(一)产品设计

    1)新手设计无脑化、傻瓜化
        1. UI操作简单、直观、便捷;
        2. 短时间使玩家角色获得快速成长;
    2)针对付费的设计
        1. 第一时间让玩家产生付费的冲动;
        2. 付费点遍及游戏各个系统;
    3)内挂设计,减少外挂影响
        1. 自动寻路、自动拾取物品、自动战斗、自动补充HP/MP等;
        2. 自动换装(或者提示玩家换更强的装备);
    4)提供玩家最大的满足感和爽快感
        1. 更好的游戏代入:游戏题材的选择,游戏世界观的设计等
        2. 深挖数值,但又不能使游戏系统过于复杂,即玩家能快速理解游戏玩法内容;

(二)技术研发

    1)提供跨服PK的功能,即不同大区的玩家能够同场竞技;
        技术关注点:不同大区的服务器是否部署在同一IDC?存储服务器数据分区部署 or 全Cluster共享?
    2)支持一机多服部署
        即同一台物理机器部署多个游戏世界
    3)形成一套核心研发机制和稳定的开发框架、基础库,保障核心功能快速复制

(三)运营推广

    1)快速开服,满足玩家“滚服”需求:《龙将》和《神仙道》做到了1天1服或1天2服,所谓“滚服”,即玩家会在不同服务器体验,目的是争取在新的服务器更高的排名和更大的满足感;
    2)开服第一周的收入是该服最主要的收入,也决定了运营商是否加大推广的力度;
    3)流量就是金钱,一般运营商的成本是每个人1-2元每人的流量成本;
    4)运营商可以提供机器,也可能让开发者自己租用机器和带宽,它只提供一个域名;

(四)其它

    1)核心玩家群特征:低粘性、高ARP值,即纯粹互联网用户,游戏只是其网络生活的一种典型应用;
    2)3–6个月完成一款RPG类webgame的全部开发,即正式付款公测;

WebGame游戏服务器技术要点

(一)服务器技术实现方案选择的问题?

(1)选择标准WebServer+CGI开发(偏轻)
【优点】
    1)快速开发:WebServer都是现成的,如:Nginx和Apache;CGI程序能也快速编程;
    2)灵活开发:整个后台服务可由多个CGI程序组成,一个CGI程序可以对应一项或多项业务功能,增加新功能时则增加新的CGI程序即可;
    3)不停机更新:部署新的CGI程序,不影响已运行的CGI程序;
    4)可适合处理SNS类玩家异步(离线)交互数据的情形;
【不足】
    1)CGI程序如果过多,可能会加大维护的难度;
    2)业务需求如果要涉及到多个CGI程序之间的通信,即有状态的关联依赖,可能会有较复杂的逻辑和可能的性能瓶;
(2)选择自定义通信服务器+GameSvr开发(偏重)
【优点】
    1)可应对复杂业务逻辑的处理,如:业务需求之间的关联依赖较深等;
    2)可轻松处理玩家之间同步数据的需求;
【不足】
    1)开发复杂度较大,需要较多的开发资源;

(二)游戏服务器Cache设计方案

【背景】
    1)游戏服务器cache数据可大大缓解数据存取时压力;
    2)多台分布式游戏服务器作Cache,可有效利用硬件资源;
【实现方案】
    1)基于共享内存的对象池设计;
【注意事项】
    1)数据一致性:对于SNS强交互类游戏,需要作多玩家修改同一数据的设计;
    2)数据同步的时机:根据业务数据的重要程度,分级设计同步时间,越重要的数据,同步时间越短;

(三)游戏服务器数据分类设计方案

【基本思想】
    把业务数据按重要程度进行分类,每类数据采用不同的存储和逻辑处理策略;
 
【应用说明】
    SNS类游戏需要重点考虑

(四)游戏服务器全局锁的设计

【背景】
    1)同一玩家数据会被多玩家修改;
    2)某一Cache数据会被多个应用修改;
【方案一】:热点数据分布在各个游戏服务器的Cache中
    1)数据被修改点(热点数据)设置一个全局Seq,如:玩家数据修改,则在玩家身上设置一个Seq;
    2)当Client读热点数据时,则直接返回数据给Client,并将Seq一齐带上;
    3)当Client写热点数据时,会在写数据请求里带上上次请求获得的该热点数据的Seq,热点数据的处理逻辑先比较写数据请求的Seq,是否与当前热点数据的Seq一致,若不一致(该请求来之前已被其它Client修改过),则有如下两种异步处理方案:
        1. 直接报错给请求Client,此时Client可能需要提示玩家重新刷新浏览器;
        2. 返回当前最新热点数据给请求Client,Client需要重新处理一遍之前的业务逻辑,再提交写数据请求;
    4)每次写热点数据成功后,热点数据本身的Seq加1;
    5)数据修改的逻辑统一在热点数据所在的游戏服务器处理;
【方案二】:热点数据集中在一个全局公共服务器的Cache中
    实现方法与【方案一】类似
【两个方案的比较】
    1)【方案一】:Cache分布在每台游戏服务器中,可以有效利用硬件资源,但SS交互逻辑复杂一些;
    2)【方案二】:可以减少一些SS协议的交互,但需要单独的全局Cache服务器;
【注意事项】
    1)需要分别考虑玩家在线和离线数据的修改;

 (五)如何有效利用机器的多核CPU

1)多个通信服务器+1个游戏服务器;

    2)多个通信服务器+多个游戏服务器;
 

(六)如何评估网络I/O的瓶颈

    1)网卡(1000M bit/100M bit)本身的极限处理能力:理论处理包的数量:网卡带宽[1000M bit]/(最小包大小[64Byte] * 8);
    2)游戏业务对包的数量较包的大小更敏感,因为每个网络包在CPU处理时,会产生IO中断,因此,常用的策略是,合并多个请求包为一个包,提高带个包的信息量;
 

(七)深入了解MySQL的存储性能

    1)Mysql5.5+InnoDB1.1;
    2)Mysql的Cache解决方案;
【声明:若有摘录,请注明来自http://gameislife.info/archives/109】

Nginx下用C/C++开发FastCGI程序

(一)关于环境搭建
1)分别安装Nginx1.08+FastCGI2.41,这个过程中可能需要安装pcre库;
2)安装C语言版本的spawn-fcgi-1.6.3;
3)安装C语言版本的fcgiwrap,这是不是必须,但它可以使应用程序像传统CGI的方式工作,即即时执行,即时释放;
(二)Nginx配置成FastCGI
location ~ \.cgi$ {

root cgi-bin;
fastcgi_pass 127.0.0.1:9000;
#fastcgi_pass unix:/var/run/nginx/nginx-fcgi.sock;
rewrite (.*).cgi /$1 break;
fastcgi_index index.cgi;
include fastcgi.conf;

}

参数说明如下:
1. 【root】:为cgi程序存放的相对目录,即相对于Nginx的安装路径,我的Nginx存入在/usr/local/nginx/sbin下,则上述配置的cgi程序则存入在/usr/local/nginx/cgi-bin下;
2. 【fastcgi_pass】:cgi程序部署的机器IP和应用监听端口,此处也可以配置成unix本地socket,这里需要特别指出的是,用spawn-fcgi包装器运行的应用程序的监听IP和端口必须与这里配置的保持一致;
3. 【rewrite】:应用程序忽略.cgi后缀名;
(三)应用程序的工作方式
  • 传统CGI方式
利用上面提到的fcgiwrap作为默认应用程序用spawn-fcgi包装器在后台运行,这样它会把请求的cgi程序像传统的cgi那样执行,即当次请求执行完后,就释放掉,就是所谓的fork-exec模式;
  • FastCGI同步方式
自已编写的cgi应用程序直接用spawn-fcgi包装器在后台运行,这样它会像一个常驻内存的cgi程序;
  • FastCGI异步方式
1. 自己实现一个解析http协议的框架,并应用程序以so的形式在框架中运行,公司的qzhttp用这一原理实现的;
2. 修订spawn-fcgi源码,使之能支持异步消息通信;
 
(四)注意事项
      若应用程序使用shmget等函数操作操作系统的共享内存,则在用spawn-fcgi作为包装器启动应用程序时,需注意启动的权限,即-u 选项指定的用户即为共享内存创建时的用户,否则访问共享内存将为失败; 

《Lua游戏开发实践指南》读后感

书籍地址:http://book.douban.com/subject/20392269/

一句话点评该书:想用Lua作游戏脚本开发的同学值得一读!

(一)本书特点

市面专门讲Lua的中文书籍很少,窃以为,一方面可能觉得Lua比较简单,可深入讲的东西并不多;另一方面,说明Lua的开发者数量,(尤其是国内)还是一个比较小众的群体,出版商们也无利可图。回到这本书,它不同于一般纯粹讲Lua语言本身的书籍,如:《Lua程序设计》等,而是专注于讲解Lua在游戏领域的应用,从书中列出的几个例子来看,可以看得出作者在游戏行业是有比较丰富的经验的。下面摘取了书中的一些要点,与诸君分享之:)

(二)要点分享

(1)Lua在游戏开发的应用场景

1)编辑游戏的用户界面

我的理解:GUI图形绘制等基础功能还是要由宿主语言来完成,如:C/C++,Lua可以负责GUI的排版、布局等逻辑处理;

2)定义、存储和管理基础游戏数据

我的理解:游戏对象各配置数据如果比较简单的,均可以用Lua代码直接描述,用以代替文本文件,并省却解析的代价。复杂一点的,可以结合excel(保存为cvs文件),并利用Lua强大的文本解析功能来完成。

3)管理实时游戏事件

我的理解:玩家与游戏的交互都是通过鼠标、键盘等外设来完成,而在游戏设计中,普遍的做法是用事件机制来驱动完成。在Lua中可以通过定义LuaGrue函数与C/C++等宿主语言进行交互调用来形成一整套完整的事件系统。具体实现时,宿主语言实现捕获鼠标、键盘各类事件的底层接口,而事件触发后具体做什么,以及事件之间可能的依赖关系等逻辑,则由Lua来完成;

4)创建和维护开发者友好的游戏存储和载入系统

我的理解:在单机游戏中的游戏存档等数据,也可以很方便的用Lua来直接描述;

5)编写游戏的人工智能系统

我的理解:作者说的在AI中应用Lua,我觉得应用场景应该是在一些比较小的单机游戏中,而在大型多人在线的网络游戏中,恐怕还是需要性能更高的C/C++来实现。当然,作者也讲到,一个灵活的做法是,先用Lua来快速实现原型,遇到性能瓶颈了,再用C/C++来替换。

作者在讲到Lua在游戏开发团队中的应用分工时说,“程序员负责将Lua整合到游戏开发环境中,游戏设计师(策划)是脚本语言的主要使用者,因为他们和上层的游戏设计和数据直接打交道,美术师也会经常使用Lua,进行诸如界面布局、设计和3D场景中各种模型的摆放之类的工作。”看到这里时,不禁感叹,我们与国外游戏开发同行的水平差距:人家认为游戏策划和美术人员写脚本是理所当然的事情,而咱们这里,却认为这些不都是程序员该干的活吗?开发理念的高低直接导致了开发成果的巨大差异!

(三)本书的不足

(1)书中讲的Lua版本是5.0,而现在最新的已是5.2.1了,与C语言通信的API也有了一些变化;

(2)没有讲Lua的一个重要特性:协程,协程在异步编程中应用广泛,不但能简化传统异步编程的代码编写,而且还能有效的提高性能;

《程序员的职业素养》读书笔记

书籍地址:http://book.douban.com/subject/11614538/

一句话点评该书:Bob大叔的职业生涯经验总结,现身说法,可信可敬!

(一)专业主义

(1)“专业主义”就意味着担当责任;

(2)所谓专业人士,就是能对自己犯下的错误负责的人,哪怕那些错误实际上在所难免;

(3)你写的每一行代码都要测试。如果你希望自己的软件灵活可变,那就应该时常修改它!

(4)每个专业人士必须精通的事项;

1)设计模式:必须能描述GOF书中全部24种模式,同时还要有POSA书中多数模式的实战经验;

2)设计原则:必须了解SOLID原则,而且要深刻理解组件设计原则;

3)方法:必须理解XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计等;

4)实践:必须掌握测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程;

5)工件:必须了解如何使用UML图、DFD图、结构图、Petri网格图、状态迁移图、流程图和决策表;

(5)坚持学习。

不写代码的架构师必然遭殃,他们很快会发现自己跟不上时代了;不学习新语言的程序员同样会遭殃,他们只能眼睁睁看着软件业径直向前,把自己抛在后面;学不会新原则和技术的开发人员必将沦落,他们身边的人都是益卓越;

(6)业精于勤。

我常用的一个技巧是重复做一些简单练习:不妨早晚都个10分钟的卡塔吧!学习的第二个最佳方法是与他人合作。

(7)每位专业软件人员都有义务了解自己开发的解决方案所对应的业务领域;

(8)雇主的问题就是你的问题,每次开发系统,都应该站在雇主的角度来思考,确保开发的功能真正能满足雇主需要;

(二)说“不”

(1)专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说“不”!

(2)最要说“不”的是那些高风险的关键时刻。越是关键时刻,“不”字就越具价值。

(3)许诺“尝试”,就意味着你承认自己之前未尽全力,承认自己还有余力可施。如果承诺尝试,你其实也在承诺将改自己原来的方案。你是在承认原来的方案中存在不足。

(三)说“是”

(1)做出承诺包含三个步骤:

1)口头上说自己将会去做;

2)心里认真对待做出的承诺;

3)真正付诸行动;

(2)识别“缺乏承诺”的征兆,注意搜寻如下词语:“需要/应当”、“希望/但愿”、“让我们”

(3)真正的承诺是,你对自己将来做某件事做清晰的事实陈述,而且还明确说明了完成期限;

(4)如果你无法兑现承诺,那么最重要的就是尽早向你的承诺对象发出预警、越快越好,越早越好;

(5)专业人士不需要对所有请求都回答“是”。不过,他们应该努力寻找创新的方法,尽可能做到有求必应。当专业人士结出肯定回答时,他们会使用承诺用语,以确保各方能明白无误地理解承诺内容;

(四)编码

(1)编码原则

1)首先,代码必须能够正常工作;

2)代码必须能够帮你解决客户提出的问题;

3)代码必须要能和现有系统结合得天衣无缝;

4)其他程序员必须能读懂你的代码;

(2)如果感到疲劳或心烦意乱,千万不要编码。强而为之,最终只能再回头返工。相反,要找到一种方法来消除干扰,让心绪平静下来;

(3)结对是应对中断的一种好方法,另一种有帮助的方法便是采用TDD;

(4)广泛阅读包括软件、政治、生物、航天、物理、化学、数学等,能激发创造力:“创造性输出”依赖于“创造性输入”,创造力会激发创造力;

(5)软件开发是一场马拉松,而不是短跑冲刺。你无法全程一直以最快的速度冲刺来赢得比赛,只有通过保存体力和维持稳定节奏来取胜;

(6)管理延迟的诀窍,便是早期检测和保持透明;

(五)测试驱动开发

(1)TDD的三项原则

1)在编好失败单元测试之前,不要编写任何产品代码;

2)只要有一个单元测试失败了,就不要再写测试代码,包括无法通过编译;

3)产品代码恰好能够让当前失败的单元测试成功通过即可,不要多写;

(2)TDD是专业人士的选择。它是一项能够提升代码确定性、给程序员鼓励、降低代码缺陷率、优化文档和设计的原则。

(六)练习

(1)专业人士都需要借助专门训练来提升自己的技能;

(2)保持不落伍的一种方法是为开源项目贡献代码;

(3)我的理解:练习就像是学生时代的课后作业,日事日毕,练习内容可包括:经典算法、常用数据结构、设计模式等;

(七)验收测试

(1)做业务的人和写程序的人都容易陷入一个陷阱,即过早进行精细化;

(2)验收测试定义为业务方与开发方合作编写的测试,其目的在于确定需求已经完成;

(3)业务分析员测试“正确路径”,以证明功能的业务价值;QA则测试“错误路径”、边界条件、异常、例外情况;

(4)实现某项功能的代码,应该在对应的验收测试完成后开始;

(5)验收测试不是单元测试。单元测试是程序员写给程序员的,它是正式的设计文档,描述了底层结构及代码的行为;验收测试是业务方写给业务方的,它们是正式的需求文档,描述了业务方认为系统应该如何运行;

(6)整套持续集成系统应该由源代码管理系统来触发。只要有人提交了代码,持续集成系统就会开始构建,并运行所有的测试,测试结果会用电子邮件发送给团队所有人;

(八)测试策略

(1)开发小组要把“QA”应该找不到任何错误“作为努力的目标;

(2)QA在团队中扮演的是需求规约定义者和特性描述者;

(3)专业开发人员遵循测试驱动开发的要求来创建单元测试。专业开发团队使用验收测试定义系统需求,使用持续集成保证质量稳步提升;

(4)测试金字塔,由下至上的顺序是:单元测试–>组件测试–>集成测试–>系统测试–>人工探索式测试,其中单元测试是基石。

(九)时间管理

(1)站立会议的核心:

1)我昨天干了什么?

2)我今天打算做什么?

3)我遇到了什么问题?

(2)迭代计划会议用来选择在下一轮迭代中实现的开发任务;

(3)凡是不能在5分钟内解决的争论,都不能靠辩说来解决。这类争论依据的不是事实,而是信念。唯一出路是,用数据说话。

(4)用番茄工作法管理时间。(呵,没想到Bob大叔也用这个)

(5)睡眠的重要性怎么强调都不为过,保证7小时睡眠!

(6)要避免的行为:优先级错乱、死胡同、泥潭;如果你掉进入坑里,别继续再挖!

(十)预估

(1)专业开发人员不随便承诺,除非他们确切知道可以完成;

(2)专业开发人员能够清楚区分预估和承诺。只有在确切知道可以完成的前提下,他们才会给出承诺。此外,他们也会小心避免给出暗示性的承诺。他们尽可能清楚地说明预估的概率分布,这样主管就可以做出合适的计划;

(3)预估实践方法之三元分析法,即划为乐观预估O、标称预估N、悲观预估P,结果u=(O+4N+P)/6;

(4)预估实践方法之德尔菲法:一组人集合起来,讨论某项任务,预估完成时间,然后重复”讨论–预估“的过程,直到意见统一;

(5)预估是非常容易出错的,控制错误的方法之一是大数定律:把大任务分成许多小任务,分开预估再加总。

(十一)压力

(1)即使有压力,专业开发人员也会冷静果断。尽管压力不断增大,他仍然会坚守所受的训练和纪律,他知道这些是他赖以战胜由最后期限和承诺所带来的压力感的最好方法;

(2)在压力下保持冷静的最好方式,便是规避会导致压力的处境;

(3)避免压力的方法

1)不做不切实际的承诺;

2)让系统、代码和设计尽可能整洁;

3)在危机中依然遵守纪律原则;

(4)应对压力

1)避免孤注一掷的想法,鲁莽仓促只会把你带入更深的深渊。相反,要放松下来,对问题深思熟虑。

2)和团队、主管沟通;

3)坚信并依靠你的纪律原则;

4)结对寻求帮助;

(十二)协作

(1)不正常的团队最糟糕的症状是,每个程序员在自己的代码周边筑起一道高墙,拒绝让其他程序员接触到这些代码;

(2)专业开发人员是不会阻止别人修改代码的;期望拥有代码的是整个团队,而非个人;

(3)专业人士结对工作,是解决程序间合作的最有效方法,也是分享知识的最好途径;

(4)最有效率最有效果的代码复查方法,就是以互相协作的方式完成代码编写;

(十三)团队与项目

(1)形成团队是需要时间的。团队成员需要首先建立关系。他们需要学习如何互相协作,需要了解彼此的癖好,强项、弱项,最终,才能凝聚成团队。否则,那就是团伙,而非团队!

(2)最理想的团队是12人,7名程序员,2名测试人员,2名分析师和1名项目经理;

(3)创建有凝聚力的团队,然后不断地把新项目分派给他们,而不是围绕项目来构建团队;

(4)团队对项目更难构建。因此,组建稳健的团队,让团队在一个又一个项目中整体移动共同工作是较好的做法;

(十四)辅导、学徒期与技艺

(1)所谓大师

已经领导过多个重要软件项目的程序员。一般说来,他们已经拥有10年以上的从业经验,曾在多个不同类型的系统、语言和操作系统上工作过。他们懂得如何领导和协调多个团队,他们是熟练的设计师和架构师,能够游刃有余地编程。

(2)专业主义价值观和技术敏锐度需要进行不断地传授、培育、滋养和文火慢炖,直至其深植入文化当中;

【Bob大叔使用的开发工具】

使用Git来管控源代码,使用Tracker来管理Bug,使用Jenkins来进行持续构建,使用IntelliJ作为集成开发环境,使用XUnit来做单元测试,使用FitNesse来做组件测试

【附Bob大叔不完全Resume】

(1)1968年自学计算机编程,时年15岁,学习PDP-8汇编器、FORTRAN、COBOL、PL/1;

(2)1970年,没有上大学,被ASC公司聘为程序员,时年17岁;

(3)1973年,20岁与妻子Ann Marie永结连理,妻子那年刚18岁过去3天。Bob大叔深情地说:“38年来,她一直是我坚定不移的伴侣,是我的舵和我的帆,是我的爱与生命。我期待同她携手再走40年!”看来,一个卓越的程序员,也一定是一个深爱妻子与家庭的人!这点倒是与我不谋而合!大笑

(4)到目前为止,Bob编了42年的程序,与妻子育有二女一子!

2012,回顾与展望!

传说中的2012,转眼就要过去了,玛雅末日预言最终还是止于坊间的笑谈!

岁末将至,是有必要总结一下的!还是按照常规的家庭与工作二大topic吧。

【家庭篇】

2012无论是我的小家,还是整个大家庭,都是极不平凡的一年。

小家。亲爱的老婆怀小宝宝了。明年开年不久,咱们小家又会添加新的快乐与希冀。老婆怀孕与我们计划还是一个小小偏差的,原本是等今年9-10月份度完蜜月再怀的,没想到,这个小宝宝就这么迫不及待的来临。欧洲之行的蜜月也中途夭折,有点对不住老婆!因为,去年新婚不久我就去了外地长驻,现在漫长的怀孕周期中,我也不能长时间陪她左右。她刚刚从GF升级成Wife,又马上成Wife升级到Mother,心理的变化对她来说,也有点突然。难为你了,亲爱的!两地分居的问题,来年一定要好好妥善解决的,这个我已经下定了决心,我一直以为,家庭幸福是追求事业成功的基础和前提!

大家。八叔、大伯和堂叔的相继去世,是家族中最大的事件。尤其是八叔,48岁就英年早逝,辛苦忙碌了半辈子,这些年一直在外地做生意,家里的经济状况也刚刚有所改善,4个子女也都长大成人,却突得急病,撒手西去,对于我的这4个堂弟堂妹来说,已是无法抹去的伤痛。所谓,“子欲养而亲不待”,世间最痛苦的事已莫过如此!

【工作篇】

今年是整整离家在外地工作了一年,做了两个项目。前一个是webgame。(这也是我第一次做webgame,之前的做的项目是端游,自己也很想尝试这类轻量级的游戏。)从技术角度来看,页游的后台服务器技术与端游基本相似,只是游戏类型的不同,可能在架构部署层面有些区别。(可以点这里)而页游前台则是用Flash AS3来实现。由于之前一直做服务器,从这个项目开始,也开始学习前端的技术,毕竟技术东西本质上是相通的。学习AS3、Flash CS、FlashBuilder,拓展了自己的技术视野。项目7月已经上线对外测试,经历了几次放号测试,服务器也趋于稳定,期间的收获还是不少的,此处就不一一赘述了。

第二项目也是现在正在做的,项目是休闲类的跨平台游戏,采用U3D引擎。从9月开始作原型论证,到目前为止,已经实现了比较完整的带有核心玩法的版本。自己除了负责后台服务器的架构设计与实现外,也参与了客户端核心算法逻辑的开发。学习U3D、C#,进一步拓展了自己的技术视野,掌握好游戏客户端开发的核心技术,也是我的兴趣和目标所在。

【2013不完整checklist】

【家庭篇】

(1)带老婆和小Baby(如果情况允许的话)去境外旅游一次;

(2)尽量多抽时间陪家人,周末户外自驾游;

(3)争取至少每两个月和朋友们聚一次;

(4)和老婆一起健身,晨练or晚上跑步or周末爬山等;

(5)学习育儿之道;

【工作篇】

(1)建立一个有独立域名的个人网站,作为长期记录个人所思所想之地;

(2)坚持每月阅读四本书籍(不限于技术);

(3)推出每月自评系列,以定期总结所学所得,内容包括:看过的书籍+文章+电影;用过的软件工具;收藏的网站;以及最新行业资讯、社会热点所思等;

(4)认真读一个经典开源项目,如:Linux0.1内核;

(5)完成一个个人游戏,并开源,初步想用U3D来做;

动作类网游技术难点分析

1 背景

动作类游戏(ACT)在百度百科上的定义是:由玩家所控制的人物根据周围环境的变化,利用键盘或者手柄、鼠标的按键做出一定的动作,如移动、跳跃、攻击、躲避、防守等,来达到游戏要求的相应目标。单机代表作有:《波斯王子》、《鬼泣》、《真三国无双》、《战神》等,而网游代表作有:《DNF》、《龙之谷》、《怪物猎人OL》等。

从技术层面来说,与传统MMORPG不同的是,动作类网游对于操作响应的网络时延要求极高,要保证较好的体验效果的话,一般要求时延小于150ms。如果网络时延较大的话,会带来对战双方(或多方)数据不一致的问题,即所谓的数据同步问题。因此,数据同步问题是动作类网游的首要问题,也是最大的问题。

下面将先描述数据同步问题的具体表现,再尝试分析目前业界常用的解决办法,最后简要讲述公司两个自研项目的实施方案。

2 问题聚焦

下面列举的这些同步问题,也是大部分网络游戏共有的一些典型问题,如果处理不好,又会在动作类网游中进一步放大,从而极大的影响玩家体验。

2.1 位置不同步

比如在T1时间,第三世界的玩家B看第一世界的玩家A在射程内并发起攻击,但此时玩家A正在跑出射程,当服务器收到玩家B的攻击请求,会判断玩家A已经在射程外了,如果服务器拒绝B的攻击,则会让B觉得很困惑,为什么明明在攻击范围内,却攻击不到呢?

 

2.2 动态阻挡

所谓动态阻挡是指角色、怪物和建筑这些实体不可重叠。动态阻挡让玩家感觉更具有真实性,并且在多人PK中,可以利用动态阻挡进行卡位,制造人墙,丰富游戏的玩法。

动态阻挡本身就会有很多碰撞问题,再加上网络延迟,会有各种各样的问题产生。

碰撞情形1:玩家A在P1点请求要去P2点时,玩家B也有可能在P3点请求要到P2点,但最终只能有一个人到P2的位置,如何避免拉扯呢。

 

碰撞情形2:玩家A在P1点请求要去P2点,玩家B在P3点请求要去P4点,路径有交叉,要让他们碰还是不碰呢?

 

 

 

碰撞情形3:玩家A在P1点请求要去P2点,玩家B在P3点要去P4点,这种情形也会有碰撞发生。

 

 

碰撞情形4:玩家A要通过一个只能容纳一个人的关隘,玩家B要阻止玩家A通过,但是由于网络延迟,当A通过时,并没有发现B已经在卡住关隘,服务器是相信A,允许通过呢,还是相信服务器自己,要拖拽A呢?

 

 

碰撞情形5:玩家A要通过城门,但是由于网络延迟,当A通过时,并没有发现城门已经关闭了,服务器是相信A,允许通过呢,还是要拖拽A呢?

2.3 技能事件

考虑冰冻情形,在T1时间,玩家A对玩家B施放冰冻,在T2时间,服务器收到报文,并下发冰冻确认,玩家B在T3时刻才收到自己被冰冻的消息,

如果在T3时间前,B没有收到被冰冻消息,进行移动,而移动报文又在T2时刻到达服务器,如果按照逻辑,服务器拒绝处理B的移动请求,那么就会产生B在第一视角的位置和服务器的位置不一致的现象,就会产生拖拽,如何避免拖拽呢?

 

其他诸如击晕,减速,恐惧,死亡等等,都类似冰冻情形,不再赘述

3解决方案

3.1 帧同步

  • 原理

玩家在发起战斗后,每隔一定时间在玩家的战斗动作序列中设置一个逻辑关键帧,在关键帧这个点,本机必须收到来自所有参与者反馈后才可继续执行其余的动作序列,否则,就进行锁帧、等待。这样就通过频繁对时(即在每一个关键帧节点上对齐),便可以像编写串行单机指令一样来进行多个客户端的事件指令同步了。

如下图所示:

 

  • 优点

简单易实现,不会出现任何的不一致性。在延迟小(< 100ms)且稳定的环境下非常合适。此外,在实时性要求不高的玩法(比如回合制玩法)中也非常合适。

  • 缺点

游戏节奏受最慢的那个玩家客户端影响巨大。一人卡机,所有人受影响。恶意玩家可以用伪造大延迟的方式来获得好处,从而破坏游戏公平性。

 

3.2 客户端承担消耗运算

  • 原理

游戏比较消耗CPU的运算均放在玩家本地客户端执行,如:角色移动物理判定、战斗物理判定、AI逻辑判定等等。服务器只对影响玩家利益的关键信息作验证。

  • 优点

保证了游戏操作手感,避免了本机操作延时。

  • 缺点

运算逻辑存放在客户端,会带来较大的外挂风险。

 

3.3 游戏策划上的优化

  • 原理

在游戏设计层面,来隐藏玩家的延迟感。比如:延长出招/收招动作时间、降低动作判定精度、给技能加公共CD、避免战斗受击时发生位移等等。

  • 优点

无任何技术风险,绿色、环保、安全,代价最小。

  • 缺点

可能会影响战斗的爽快感。

 

4 公司内项目的一些做法

《QQ堂》和《炫斗之王》都是公司自研的动作休闲类游戏,在与其相关负责同事作了一些简要交流后,将他们的做法小结如下:

  • 客户端之间采用P2P通信

这对于在同一局域网内(如:网吧)的玩家,网络延迟很小。只有当两个Peer连结不同时,消息包才通过服务器中转;

  • 客户端先表现,服务器后检验

玩家角色在移动、战斗出招等操作时,客户端在发出请求包的同时,先自行在本机表现,继续后面的游戏逻辑,而无需等到服务器验证通过后才开始。

  • 客户端的校验逻辑同时在服务器再运行一遍

这也是惯用做法,即所谓的服务器强校验。

  • 做好客户端反外挂

由于采用P2P通信,有些逻辑难免会放在客户端,这与上述的一些解决方案的做法也是类似的。附上QQ堂对于反外挂处理的一个分享文档

5 小结

综上所述,动作类网游在技术实施层面上,较传统MMORPG主要是在数据同步(多个Peer间、C/S间)上要求更加苛刻,当然,这目前在客户端平台上,也已经有了较为成熟的技术解决方案。但具体到页游平台,虽然从Flash10和Adobe AIR1.5开始,已经支持P2P通信,Adobe也在官方提供相应 的P2P服务,即代号为Cirrus,但目前尚未看到其在商业运营的页游项目里有成熟的应用。因此,在页游平台的P2P应用,还需要更进一步的探索和挖掘。

Social Game与MMORPG在服务器架构上的差异

最近在作公司的一个Social Game的项目服务器架构设计,与之前做过的MMORPG(简称RPG)相比,差别还是较为明显的,现总结一二,以供分享!

(一)协议通信

1)Socail Game为了快速开发,在通信协议的选择上均会选择http作为底层通信协议,这样选择的好处大致有:

1、方便客户端编程:http为一应一答的同步模型;

2、可以选择成熟的开源http服务器,如:apache、nginx;

2)RPG选择的是基于socket的TCP通信,这是由游戏本身的特点所决定的,如:聊天、多人视野、服务器主动通知事件等需求

(二)游戏逻辑服务器的承受能力

1)RPG的游戏逻辑服务器(地图服务器)所能承载的最高在线(PCU)是在3000-5000不等;

2)Social Game由于没有RPG复杂的移动、战斗、视野管理等需求,逻辑服务器承受的在线一般都是比较高的,如:10000-30000不等

(三)游戏逻辑服务器的Cache和回写机制

1)RPG的游戏逻辑服务器一般都需要Cache玩家数据,并且采取定时回写的策略,如根据数据重要程度分别作5min-15min不等的定时回写;

2)Social Game的游戏逻辑服务器一般都无需Cache玩家数据,玩家的每次请求都是即时读即时写(这样会涉及到另外一个问题,即DB读写的性能问题,见下一条);

(四)DB存储模型的选择

1)RPG存储服务器常用的还是MySQL+innodb,中间还由业务自己写一个Cache代理服务器,以Cache热点数据;

2)Social Game则会选用TC、MemCached等所谓Key-Value全内存数据存储,有实力的公司会自己实现一个类似这种机制的存储系统,它可以无源,也可以是有源,并且还可以选择用MySQL作数据落地,毕竟MySQL作为互联网业务DB的成熟解决方案,已毋庸置疑;

(注:我们公司是选择自己开发基于key-value机制的全内存DB,现网测试的数据是平均1KB的数据可以分别达到5w左右的读/写,还是很牛X的了)

(五)交互数据的一致性

1)在SNS Game中,会经常出现同一个玩家在某一个时刻同时被多个好友访问和修改数据的情况,这时就需要保证,每次数据的更新都是正常有序进行的,而不能被写脏数据。一般地,都会使用一个类似全局锁服务的设计来解决这个问题;

2)RPG不会存在这样的问题,类似的需求是:玩家可能会跨地图服务器,即所谓的跳线或跨服,这个问题的通常解决方案是服务器重新作一次下线、重登录的处理,当然,玩家是感觉不到的;

(六)IDC部署

1)RPG一般是分区分服部署;

2)Social Game则是全区全服部署;

呵,先写这些多,后面再慢慢补充,也欢迎同行朋友拍砖!:)