C++博客-beautykingdom-随笔分类-misce

有抗癌效果的神奇食物

chatler — Fri, 23 Sep 2011 00:44:00 GMT

from:

http://health.msn.com.cn/healthcare/20110603/05001247621.shtml

http://health.msn.com.cn 2011-06-03 05:00:00 来源: 环球网健康频道

　　保健：七种食物抗癌效果好

　　茄子 “霜打茄子”是好药。越来越多证据表明，茄子具有抗癌功能。曾有试验从茄子中提取的一种无毒物质，用于治疗胃癌、子宫颈癌等收到良效。

　　苦瓜苦瓜是不可多得的抗癌瓜。苦瓜种子中含有一种蛋白酶抑制剂，能抑制肿瘤细胞分泌蛋白酶，从而抑制癌细胞的侵袭和转移。

　　海带海带中药名为“昆布”，可预防乳腺癌和甲状腺肿瘤。海带可杀灭或抑制肠道内能够产生致癌物的细菌，所含的纤维还能促进胆汁酸和胆固醇的排出；海带提取物对各种癌细胞有直接抑制作用。

　　地瓜地瓜是人们逐渐淡忘的抗癌佳品。别名甘薯、红薯、白薯，被认为是祛病延年、减肥保健的绝佳食品。其实地瓜能预防肠癌和乳腺癌的发生。

　　麦麸麦麸是最好的防癌食物纤维，它能预防并治疗结直肠癌、糖尿并高胆固醇血症、高脂血症、便秘、痔疮等。

　　萝卜萝卜是根茎类蔬菜中的“健康保护神”。胡萝卜因含丰富的胡萝卜素，也具有极好的防癌作用。

　　猕猴桃 猕猴桃维生素C含量居水果之冠，是名副其实的“天然维生素C片”，另外还含有丰富的具有保护血管功能的维生素P，其营养价值甚高。

chatler 2011-09-23 08:44 发表评论

收集的一些还不错的网站

chatler — Thu, 07 Oct 2010 05:32:00 GMT

摘要: 阅读全文

chatler 2010-10-07 13:32 发表评论

浅谈游戏服务器---功能模块上来看

chatler — Sun, 31 Jan 2010 04:10:00 GMT

本文小弟浅谈，新手看，老手拍砖，转载请注明出处http://www.cppblog.com/ziyebuboka/

    游戏服务器在网游上的作用不容考虑，游戏能做大到什么程度，还是有很大的依靠的，这篇文章先从功能模块的角度来谈一个完善的游戏服务器需要实现哪。
    一：游戏服务器的作用：连接各个网游客户端，实现各客户端的通信，连接，数据操作
    二：先从大分类上来：游戏服务器按一般架构来说具备1
            1:登陆验证注册和账号有关的所有操作的服务器我们简称他为registerserver
            2：游戏逻辑操作服务器我们简称他为gameserver
            不用细说大家也明白了，说一个玩家登陆进入游戏世界的流程：玩家打开游戏客户端（这之前会有更新操作，不过这只是连接更新服务器的一个文件比对和下载过程，我们不将他列为游戏服务器之内）说到这里朋友会发现游戏登陆上目前有两大类，一类是先选服务器后输入账号一类是先输入账号后选服务器，这里说下区别
先选服务器后输入账号的一般来说都是将registerserver和gameserver配对，就是你先选择服务器，而后你连接上的就是此服务器的registerserver，通过此registerserver来进行账号验证等等。另一类先输入账号的，无非是先制定一个中心registerserver（或者是随机一个，因为register有时候会弄好多个由运维配置来做动态均衡），账号验证成功后再显示服务器列表，然后玩家选择了服务器后，则从指定服registerserver去数据库查询玩家此服的角色列表（当然了，这里如果非有人的服务器是做成查询角色列表就从gameserver走的流程，我也没意见）。返回后，客户端进入角色选择界面，客户端与registerserver断链，玩家选择角色，与gameserver连接，去数据库提取角色，注册进入游戏服游戏世界，反馈角色信息给客户端，客户端进入游戏世界。然后消息发送过来发送过去的开始了。。。。。。
            上面说的是针对一个普通的一对一架构的服务器所有的一个登陆流程，看到这里，朋友们应该对registerserver和gameserver的基本功能有所了解了。一个是登陆验证用（垃圾点的小公司没有注册账号的主页的话也会通过这个在游戏里直接注册账号。。。）到登陆进入游戏世界的过程。
             再稍微高级点的就是加个聊天服务器了，因为聊天这个功能实在是太耗性能了，特别那啥的那公聊，你发个一句，服务器得有多少人就发多少回。。。
打个比方你发一句话 50个字那就是100 一个服有那么个几K人的话，就打比方5K人一句话发送就得是一个全服人口大FOR循环，网络还得消耗掉5000*100字节
所以你看各游戏公聊国聊那啥的都时间限制要不就收费，他扛不住啊。
             所以这个地方就出来个性能优化方案了，加个聊天服务器，也就是玩家在登陆成功与gameserver连接成功的同时要与聊天服务器连接成功，聊天服务器有个全服在线角色表，一个大FOR循环和那啥的5000*100就让他来发吧，至少对gameserver没影响了。
             好了，一个普通服务器的基本介绍就说到这里，读者也应该有个基本了解了，具体架构上的就不细说了，赶明换个帖子发。这里还是接标题从功能上来分析服务器。
            这里就只分析游戏服务器了，registerserver就不考虑了。
            一个游戏服务器他的作用在与，所有的游戏数据操作都将在这里完成，我们将只将客户端作为显示和一个数据的完善缓存。一切的操作都必须在游戏服务器的验证之后才能完成。
           功能模块分类（本人之间，有多余或遗漏的，欢迎补充）：
              1：脚本模块
              2：属性模块
              3：网络模块
              4：数据库模块
              5：日志模块
以上所列的为一个完善的游戏服务器所必须实现的功能下面一一来说
1：脚本模块
      没有脚本模块，脚本策划就得喝西北风，LUA首选很不错。
      具体LUA的学习，推荐LUA程序设计，这玩意不用深究，会即可。
      程序员要写好几个CPP，完成的功能是---》在C++中任意的调用LUA函数（或是执行一个LUA文件），在LUA中任意调用你提供给脚本策划的C++函数接口，如此功能实现后，哈哈，程序员们，你们的工作负担就轻了，很大一部分的逻辑编程将交给策划们去完成了
     举例：程序实现一个接口例如 say(LPCSTR szSay) ，则策划可调用此接口 function mySay() say("欢迎来到游戏世界") end，就可
    可用到的地方：具体物品的使用逻辑，特殊任务的逻辑，活动逻辑，特殊NPC逻辑等等等等，只要你愿意，跑步都可用LUA来
     比如C++里可实现一篮子接口：AddItem 增加个物品 ChangeMap 跳地图甚至是AddLevel等等而由LUA调用此类接口，而后就是C++里做些操作，比如玩家点击物品就是调用相应物品的脚本：例：点击血瓶调用 LUA 的血瓶脚本，执行LUA函数调用AddHp
     脚本模块很重要，可极大的方便工作，还有调试和维护，因为修改脚本，服务器是不用重编译的，则意味着可在调试中随意修改，甚至可在运营过程中随意修改某物品功能某任务某活动。。。，只需C++到LUA，把这个LUA函数RELOAD下即可
     具体的游戏应用脚本的例子大家网上找找吧一坨子开源的。
2：属性模块：呵呵，不知道我取这个名字OK不OK，我也觉得不是很合适，大家又更好的命名没？
     NPC的基本属性配置，物品的基本属性配置，叫属性配置可能更合适点，意思就是你要提供一个模块供策划可填入各个属性配置，甚至是GUI的配置又或者是任务配置。对于这个，我推荐使用EXCEL表格。
    例如：NPC的表格至少包括 NPC名字模型编号   血量    蓝量   移动速度    AI 等等，而后有策划往里面随意填配置这里比如AI就是一个对应的脚本文件
     这个读取表格由程序员实现，功能是要求要自由化，不然的话策划加一条你咋办，不至于从读取开始你的代码都得改吧，肯定能做到直接在NPCPROPERTY结构体里直接加一条和表格新加的对应就OK了。
   如果OK得话，最好再提供个编辑工具给策划，任务的相同模式也可由此来实现：任务描述任务要求对话1 对话2 对话3 奖励1 奖励2 奖励3
   物品：物品名字模型编号职业   等级   攻击脚本
   不然你总不至于傻到认为这些都是写代码里的吧。也可能有人想使用XML 随便了不过我这里不想用XML 为啥 EXCEL清晰啊就一行条目
    这个模块是数值策划任务策划的天下
3：网络模快：这个没啥好说的一个基本功能，游戏世界都是在这之上也能成型，做好链接维护，收发消息
4：数据库模块：对数据的保存其实这里我热衷于使用工厂模式，本地调试服务器具体逻辑用本地文档方式，上测试服上外网则用数据库，所以这里叫数据操作模块比较妥当点，就是玩家保存数据，保存帮派啦等等世界信息的具体操作，这个很重要
5：日志模块：我将此日志模块分为两大类，一类是游戏服务器调试维护用日志，一类是游戏运营用日志，可选择使用本地文档或是数据库模式记录
    调试维护日志没啥好说的，运营日志说说，是给客服提供的，谁消费了什么交易流向物品流向等等的记录 GM操作的记录等等比如万一某玩家装备被盗了，则可通过此来证明。

接着一继续，其实写本文从内行技术角度来看，本身就没什么技术含量，但是俗话说的好，隔行隔山，内行看门道，外行那啥什么，反正就是想触碰这玩意，但是又没搞过的人看的。反正都是随便乱写了，爱看的看，准备写个功能模块大概再写个架构得大概，而后就去从网络包开始搞个最简单最轻量的小架构，力图让知道编程是啥的就能在上面搞东西
      还是继续谈功能模块。
      一、还有个 AI模块，这个可不能忘啊
      不过要注意，我这里提到的AI模块和我一里面所提到的几个AI地方说指AI不是一会事情。
      这里的AI模块，哈哈，就是所谓的算法了，算法达人们NB的地方了。
      针对NPC怪物等，比如最基本的寻路算法。
      此模块达到的效果是什么呢，就是：怪物死了又活，怪物看见你知道追你，怪物知道打你都知道寻路躲障碍
      介绍下最基本的A*算法吧什么A B C D E F D的
      怪物要打你得追你，但是他为啥知道跟你走呢，或者说你点击一个地方，为啥就能自动走过去，能自动的绕开障碍呢。这个模块就是实现这些基本的东西。
      2D的一般都是按格子计算，就说2D了，还有用像素玩的，3D玩坐标的，等等其实都是一会事情
      角色身旁一共有8个格子，你点击一个地方，就等于是指明了一个方向，角色就找到正对方向的身旁最近格子，判断此格子是否有阻挡，如果无则走过去，如果有阻挡则搜索身旁另一个格子，然后就是这么一直递归，知道到达终点格子。
     基本的自动寻路算法就是上面这么一段话，当然实际操作中，肯定不会用这么费效率的算法了，这里就是简单介绍下这个活在N-》B之前的N-》A*算法。。NA啊。具体的大家可以去找本人工智能的书看看
     服务器要算一下怪物走哪了就给周围玩家同步下消息，所以服务器需要这玩意，这理由充分吧、、、
     客户端也需要，给玩家或者宠物自动寻路，内挂使用。
    为什么我说这里的AI和我在一里面说的不同呢，是因为这里是实行基本的自动功能，而后你可以在这个模块的基础上发展高级AI智能，结合脚本，表格配置，活用技能。比如一个游戏里按档次有白怪蓝怪  紫怪 BOSS
白怪么就给他这一套最基本的会走路躲障碍会打人就可
蓝怪稍微高级点了，在基本模块上扩展，程序里再实现血少到一定程度会逃跑会喊同伙，

以上两种可根据属性配置表格模块根据怪物类型读取到程序，程序根据类型判断是否激活扩展AI

表格可如下：
NPC名字类型

紫怪再高级点定制AI，可在程序里预先定义一组高级AI，比如预先设想好的十种可能，打个比方，放A技能放B技能自动加血等等，而后也可在表格配置，比如预先表格设定好一种怪物最多可有4个定制AI

表格可如下：
NPC名字类型定制AI1 定制AI2 定制AI3 定制AI4

程序读取到相应类型而激活相应模块或者此组AI 都用脚本预先写好也不错这样比写死在程序里好

BOSS  那就得完全特殊处理了不是，脚本发挥作用，完全脚本实现程序事先一组接口，比如掉什么装备接口，放技能的接口等等，LUA里面就狂写吧，接口只要完善，写成个WOW里的一样也很OK

表格可如下：
NPC名字类型定制AI1 定制AI2 定制AI3 定制AI4 脚本AI

像2D游戏下FB BOSS不够智能的话玩家就知道卡BOSS 几个玩家把BOSS围一圈，让外面的远程玩家打，格子上玩家又是不可重复的，BOSS就出不去有仇恨系数他又只想杀外面打他的玩家导致就卡那里了，想打的玩家打不到打的到的玩家又不想打。。。。。。。怎么办呢，特殊AI处理，卡BOSS？系统判断BOSS十秒不出手，就放大技能秒杀周围的人。。。。

说到底，AI模块就是最基本算法，程序定制，脚本定制，属性表格配置再加脚本特殊化处理，基本就可达到需求了

二：扩展下前面说的数据库模块和日志模块
        这里大家要注意，在这类数据库和IO操作上尽量使用别的线程来开，不要和主线程搞到一起
按目前流行的架构，一般都是在服务器上多开线程开启网络接口，另外在专门单开代理程序，消息发送到数据代理，让代理来实现数据操作。
       日志模块，本地调试么，就用文档记录，运营日志，单开个代理吧，这个操作挺频繁的，和登录保存角色的代理放一起影响性能而且每什么意思，毕竟这个异步互相是不关联的  稍微提醒下就是你要是做物品流向的时候切记不要所有物品都记啊不然就SB了，这个流向日志要是都记录的话那一天都不知道是多少万条记录了万？十万？百万？
   可以表格配置：
物品名字物品ID 是否记录日志    //后面其他列是其他属性
每次产生物品流向时候比如买一个装备到包里交易一个装备等等
if(pItemProperty->bCanSaveLog)
{
//sendmessagetologdb
}

这样你就记录些珍贵物品就可

按我的分类我一般将代理分为账号代理角色代理游戏代理日志代理运维控制器代理

这里不一个个讲了放到后面说架构的时候再说每个代理需要做的事情
一个宗旨是分的细每一个得压力就小但是要保证不要出现数据互交叉

也见过某些项目是没有具体的数据操作代理的，直接是在服务器里直接操作，我个人认为啊，能新开进程异步的就开，没必要给老板省钱，全部都压一GAME上扛不住啊，而且如果是分布式的话，你肯定得有一个统一的数据出口啊，不然的话。。我没想过会怎样，数据不统一？数据库死锁?

三：运维模块
     运维分开就是运营和维护。。因为他们是走的同一套架构，所以这里就放一起来说
     首先说明他们的产生原因：不可能每一次服务器更新或者再监控服务器维护过程或者是提取某某文件日志都是一个个远程硬件服务器吧那样的话维护者工作效率就太低了
     GM也不可能每一个服务器都登陆进个客户端开着吧。。所以这个模块就产生了，对维护者是要实现他们的远程操作，对GM是要实现他们的线下操作。
    工具功能：可监控开启关闭服务器可主动推送更新文件更新脚本
                       GM可线下操作基本命令，监控聊天，赔偿物品，发送游戏邮件等等。
                       开发者可主动提取调试日志记录
                       算帐的可主动开后台查看运营日志记录计算ARPU值，查看在线记录，等等等等
我现在是不推荐GM做线上操作的呢，就如同之前传奇那样的，都是在聊天框里输入GM命令，我个人认为内部操作还是走后门的好不要和玩家一起从前门走了，注意的是这一块在中心控制器代理这里一定要做好监控，和操作记录，验证，来保证操作的安全性，防止违规操作。力图将工具客户端绑定到某一台机器，比如可在运维登陆工具时候发送账号密码 MACKEY IP 子网掩码   某一个CODE 等等在控制中心验证成功才可登入控制中心，工具客户端才可操作、
     这个模块主要注意的就是安全性，操作的方便，和日志模块结合在一起，日志记录分类挖掘良好

    具体架构的后面再说
    毕竟这个就是浅谈，所以没有什么实际性的代码内容，就是让不了解的朋友能够了解这是怎样的一个架构一个工作流程
    看了留言啊，这博客，不同IP，点了就加一阅读，没意思啊，我不知道到底有没有价值继续啊，

    我是力图用最浅的语言来表现这些玩意是怎么会事情，高深的我也不懂了，扁我吧，。觉得没啥意思的也留个言拍下砖头啊，觉得有意思的留个言让我高兴下，主要是没打草稿直接写的就发了，遗漏不清不楚肯定还是有的 .

本文介绍一下一个应用的游戏服务器的架构和演变
      游戏服务器的作用在于满足在线玩家的需求，实现账号的验证，登陆，玩家在游戏世界的一系列逻辑操作和验证。在此基础上，一个好的架构，可以提升效率，在实现逻辑需求的情况下达到百万级的同时在线数也不是不可能。
      我们先从最搓的最简单的结构看起

      CLIENT ---------- SERVER   ---------   DBSYSTEM

      就是一个很简单的 C/S系统同一个server同时处理登陆注册创建角色和游戏逻辑操作的功能，。在server上直接挂接DB操作。DB可以是一个具体的数据库也可以是一个FILESYSTEM
      这里可以看的出来，过于简单了，将登陆注册创建和具体逻辑这几个毫无关系的东西放置于一起，严重损耗了具体逻辑操作的效率，特别是在新开服阶段，完全会因为登陆验证的操作而导致逻辑爆卡。
      所以这里需要升级，将完全不同类型在玩家一次游戏操作工程中只会在登陆阶段执行一次的操作单独分开，单独进程解决，。故而可成为下面阶段

                 -  LOGINSERVER -
               -                                -
CLIENT -                                   -  DBSYSTEM
               -                               -
                - GAMESERVER -

分为两个服务器，这个我在一文章里的开头就有提到过了。

我们来看下好处进阶，在LOGINSERVER里只执行账号验证查询角色列表创建角色的操作   而后玩家登陆进GAMESERVER 具体逻辑操作在GAMESERVER里完成

玩家的一次登陆操作

                   发送账号                                 验证                               返回角色列表                          创建角色
CLIENT---------------LOGINSERVER -----------DBSYSTEM-----------------------CLIENT ------------------
                                                                                                选择角色与LOGIN断链与GAME连接登陆
LOGINSERVER -------DBSYSTEM ----------CLIENT ------------------------------------------------------GAMESERVER

如此，可有效的提升效率，玩家的验证列表读取创建和GAME就毫无关系了，但是他的缺点任然存在我们再继续看可优化的地方

首先从数据库上来提升效率（先说下，从这里开始就应该是肯定的是用数据库了，而非什么本地FILE了，），将账号库和游戏数据库分开，分离为两个独立的库，
具体理由有两个：
1：从游戏运营上来说你不可能一直是只有一个服吧？分成多个服后人数越来越多，就不能所有服都共用一个数据库了吧？那你这数据库也牛逼了
      所以我们这里这么干，将账号库独立，全游戏共用，这样是方便管理，方便管理账号的全局性的信息经济性的比如点卡什么的，每个服一个游戏数据库，只记录操作你这个服的玩家信息，世界信息。
2：理由类同将服务器拆分为LOGIN和GAME。

现在结构就是这样的

                   - LOGINSERVER-
                 -                               - ACCOUNTDBSYSTEM
CLIENT -                                                             -
                 -                               - GAMEDBSYSTEM
                   - GAMESERVER -

但是到了这里后肯定还是不够的，
我们先说个基本的，在服务器里，你一定要记得，数据库操作，IO操作，文本操作这些一定要单独进程不要和主进程搞一起，你总不希望你做了个什么查询还是什么操作他主线程挂起吧？但是，试想下，如果能单独进程肯定还是单独进程更爽一点吧？你还能在里面做做缓存啥的，还不占服务器的资源
    所以这里还是麻烦的从效率上来说至少后台这块还有很大提升空间。因此，我们加入 DBAGENT模块，单独进程，将数据库操作单独分离，并且可自我添加某些应用的缓存

对应ACCOUNTDBSYSTEM 增加 accountagent ，对应 GAMEDBSYSTEM 增加 gameagent

结构如下

                 -LOGINSERVER-
               -                              - accountagent - ACCOUNTDBSYSTEM
CLIENT -
              -                              - gameagent   - GAMEDBSYSTEM
                -GAMESERVER -

LOGINSERVER同时和accountagent和gameagent连接   gameserver也同时和这两个连接   服务器通过agent来对对应的数据库做操作   因为accountdbsystem可能是全服共有的，所以accountagent也可以是全服共有的他连接所有的服务器。loginserver通过accountagent来验证通过gameagent来查询列表创建角色 gameserver通过gameagent来查询完整角色信息登陆进game，并通知accountagent此账号已进入游戏，避免重复登陆。并且定期保存。设置你可以将比如你游戏的排行榜啊，拍卖行啊的信息放置于你自己设计的gameagent的缓存中，而避免重复查询

玩家每一个对数据库的操作 server只需发送消息到agent agent来做具体操作，而后再返回到server 再到client就可。将数据操作完全的异步操作，效率有较大提升。并且安全性上也得到了些许保证。

不是我胡说或者轻视，国内一大半游戏，都用的上面这个结构。。。。。。。。。。。。。。。。。。。。。这个可以算是一个比较完善的产品化架构了。

说到这里，大家有没有发现一个共性。采用这类架构，游戏必然会是先选服务器再验证账号登陆进游戏，这是因为服务端采用的是LOGIN和GAME一对一得处理，也就是你是登陆的什么服务器必然就是从什么服务器的LOGIN进入验证，故而他需要在客户端开启的时候就要知道需要连接的是哪个LOGIN 账号验证成功后再是哪个GAME
其实这里很好处理，就在客户端上做些处理就可以达到先登陆验证在选服务器。所以在配置上 LOGIN不再是一对一（后面会有优化的再说到多个LOGIN），全局也共用一个LOGIN。玩家开启客户端，连接LOGIN。发送账号验证。因为这里已经是把ACCOUNTDBSYSTEM做成全局的了，所以是不用担心他是哪个服的，然后返回成功，玩家客户端显示服务器列表（这个列表还有连接信息配置再客户端就可以了）选择某一个服后，则发送查询某服角色列表的请求到LOGIN，而后再返回再登陆游戏就可。小小调整和改变就可实现先验证后选服务器了。

      所以，到了这步，服务器架构就变成这个样子了

                  -LOGINSERVER-
                -                               - accountagent -ACCOUNTDBSYSTEM
CLIENT -                                 |--------
                -                                |-----------
                 -
                  - GAMESERVER - gameagent     -GAMEDBSYSTEM
                    -                                             |
                   - GAMESERVER -gameagent      -GAMEDBSYSTEM

全局共用一个LOGIN和一个ACCOUNTAGENT还有ACCOUNTDBSYSTEM
每个独立服各自独立的gameagent 和gamesdbystem
但是LOGIN的瓶颈立马出现了，当初是一个服独立一个LOGINSERVER 现在是全服只有一个了，毫无以为，扛不住。

其实上面这个架构的不一定非得存在的，就是随便写写，让大家更清楚一点。

所以LOGINSERVER就得配置多个了。这个地方大家选择吧尽量灵活点，可以全服单位的配置多个也可以每个服对应的配置多个LOGINSERVER。这样在开服时候，这种大面积井喷式的玩家玩家上线，可有效解决负载。具体CLIENT开启后会是和哪个LOGIN连接呢
这里提供两种方式。一个是配置上的一个是程序上的
1：
   程序上的好说，你把所有LOGINSERVER的连接信息都配置到客户端，让客户端开启后随机选择一个去连接。要是你开服后，他所有玩家都随机到一个LOGINSERVER了，那真的算你点背。背到家了
2：配置上：
   通过基于DNS的负载均衡系统，DNS中为一个域名配置多个IP地址。通过负载，让系统来选择是对应到哪个IP

所以就是
                 -LOGINSERVER   -|

                 - LOGINSERVER -|

                 -LOGINSERVER   -|
                -                  -accountagent -ACCOUNTDBSYSTEM
CLIENT -                                  |--------
                -                                 |-----------
                -
                -GAMESERVER -gameagent   -GAMEDBSYSTEM
                -                                             |
                -GAMESERVER - gameagent  -GAMEDBSYSTEM

或者是：



       - LOGINSERVER   -
         - LOGINSERVER   -
         - LOGINSERVER   -
      ..................................上面可以是N个
        -                                -gameagent -GAMEDBSYSTEM
        -GAMESERVER -

Client
       - LOGINSERVER   -
         - LOGINSERVER   -
         - LOGINSERVER   -
      ..................................上面可以是N个
                                         - gameagent-GAMEDBSYSTEM
        - GAMESERVER -

  accountagent    --              --- ACCOUNTDBSYSTEM 是全局的

一个服对应好多个LOGINSERVER

因为LOGINSERVER使用的动态配置，故而可在登陆下线没有多大压力的情况下，关掉几个LOGINSERVER，节省运维资源

不想写了，元旦又混了三天，明天继续吧。明天把前面的再扩展下，再说下分线的和分布的。牛逼的就不说了

chatler 2010-01-31 12:10 发表评论

ASCII码表

chatler — Tue, 22 Dec 2009 12:19:00 GMT

http://www.asciitable.com/

chatler 2009-12-22 20:19 发表评论

字符编码ASCII，Unicode和UTF-8详解

chatler — Sun, 13 Dec 2009 04:50:00 GMT

字符编码是计算机技术的基石，想要熟练使用计算机，就必须懂得一点字符编码的知识。

1. ASCII码

我们知道，在计算机内部，所有的信息最终都表示为一个二进制的字符串。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出 256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从 0000000到11111111。

上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为ASCII码，一直沿用至今。

ASCII码一共规定了128个字符的编码，比如空格“SPACE”是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的1位统一规定为0。

2、非ASCII编码

英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。比如，在法语中，字母上方有注音符号，它就无法用ASCII码表示。于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。比如，法语中的é的编码为130（二进制10000010）。这样一来，这些欧洲国家使用的编码体系，可以表示最多256个符号。

但是，这里又出现了新的问题。不同的国家有不同的字母，因此，哪怕它们都使用256个符号的编码方式，代表的字母却不一样。比如，130在法语编码中代表了é，在希伯来语编码中却代表了字母Gimel (ג)，在俄语编码中又会代表另一个符号。但是不管怎样，所有这些编码方式中，0—127表示的符号是一样的，不一样的只是128—255的这一段。

至于亚洲国家的文字，使用的符号就更多了，汉字就多达10万左右。一个字节只能表示256种符号，肯定是不够的，就必须使用多个字节表达一个符号。比如，简体中文常见的编码方式是GB2312，使用两个字节表示一个汉字，所以理论上最多可以表示256x256=65536个符号。

中文编码的问题需要专文讨论，这篇笔记不涉及。这里只指出，虽然都是用多个字节表示一个符号，但是GB类的汉字编码与后文的Unicode和UTF-8是毫无关系的。

3.Unicode

正如上一节所说，世界上存在着多种编码方式，同一个二进制数字可以被解释成不同的符号。因此，要想打开一个文本文件，就必须知道它的编码方式，否则用错误的编码方式解读，就会出现乱码。为什么电子邮件常常出现乱码？就是因为发信人和收信人使用的编码方式不一样。

可以想象，如果有一种编码，将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码，那么乱码问题就会消失。这就是Unicode，就像它的名字都表示的，这是一种所有符号的编码。

Unicode当然是一个很大的集合，现在的规模可以容纳100多万个符号。每个符号的编码都不一样，比如，U+0639表示阿拉伯字母Ain，U+0041表示英语的大写字母A，U+4E25表示汉字“严”。具体的符号对应表，可以查询unicode.org，或者专门的汉字对应表。

4. Unicode的问题

需要注意的是，Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。

比如，汉字“严”的unicode是十六进制数4E25，转换成二进制数足足有15位（100111000100101），也就是说这个符号的表示至少需要2个字节。表示其他更大的符号，可能需要3个字节或者4个字节，甚至更多。

这里就有两个严重的问题，第一个问题是，如何才能区别unicode和ascii？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？第二个问题是，我们已经知道，英文字母只用一个字节表示就够了，如果unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。

它们造成的结果是：1）出现了unicode的多种存储方式，也就是说有许多种不同的二进制格式，可以用来表示unicode。2）unicode在很长一段时间内无法推广，直到互联网的出现。

5.UTF-8

互联网的普及，强烈要求出现一种统一的编码方式。UTF-8就是在互联网上使用最广的一种unicode的实现方式。其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用。重复一遍，这里的关系是，UTF-8是Unicode的实现方式之一。

UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。

UTF-8的编码规则很简单，只有二条：

1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。

2）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。

下表总结了编码规则，字母x表示可用编码的位。

下面，还是以汉字“严”为例，演示如何实现UTF-8编码。

已知“严”的unicode是4E25（100111000100101），根据上表，可以发现4E25处在第三行的范围内（0000 0800-0000 FFFF），因此“严”的UTF-8编码需要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，“严”的UTF-8编码是 “11100100 10111000 10100101”，转换成十六进制就是E4B8A5。

6. Unicode与UTF-8之间的转换

通过上一节的例子，可以看到“严”的Unicode码是4E25，UTF-8编码是E4B8A5，两者是不一样的。它们之间的转换可以通过程序实现。

在Windows平台下，有一个最简单的转化方法，就是使用内置的记事本小程序Notepad.exe。打开文件后，点击“文件”菜单中的“另存为”命令，会跳出一个对话框，在最底部有一个“编码”的下拉条。

里面有四个选项：ANSI，Unicode，Unicode big endian 和 UTF-8。

1）ANSI是默认的编码方式。对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对Windows简体中文版，如果是繁体中文版会采用Big5码）。

2）Unicode编码指的是UCS-2编码方式，即直接用两个字节存入字符的Unicode码。这个选项用的little endian格式。

3）Unicode big endian编码与上一个选项相对应。我在下一节会解释little endian和big endian的涵义。

4）UTF-8编码，也就是上一节谈到的编码方法。

选择完”编码方式“后，点击”保存“按钮，文件的编码方式就立刻转换好了。

7. Little endian和Big endian

上一节已经提到，Unicode码可以采用UCS-2格式直接存储。以汉字”严“为例，Unicode码是4E25，需要用两个字节存储，一个字节是4E，另一个字节是25。存储的时候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。

这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中，小人国里爆发了内战，战争起因是人们争论，吃鸡蛋时究竟是从大头(Big- Endian)敲开还是从小头(Little-Endian)敲开。为了这件事情，前后爆发了六次战争，一个皇帝送了命，另一个皇帝丢了王位。

因此，第一个字节在前，就是”大头方式“（Big endian），第二个字节在前就是”小头方式“（Little endian）。

那么很自然的，就会出现一个问题：计算机怎么知道某一个文件到底采用哪一种方式编码？

Unicode规范中定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做”零宽度非换行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。这正好是两个字节，而且FF比FE大1。

如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。

8. 实例

下面，举一个实例。

打开”记事本“程序Notepad.exe，新建一个文本文件，内容就是一个”严“字，依次采用ANSI，Unicode，Unicode big endian 和 UTF-8编码方式保存。

然后，用文本编辑软件UltraEdit中的”十六进制功能“，观察该文件的内部编码方式。

1）ANSI：文件的编码就是两个字节“D1 CF”，这正是“严”的GB2312编码，这也暗示GB2312是采用大头方式存储的。

2）Unicode：编码是四个字节“FF FE 25 4E”，其中“FF FE”表明是小头方式存储，真正的编码是4E25。

3）Unicode big endian：编码是四个字节“FE FF 4E 25”，其中“FE FF”表明是大头方式存储。

4）UTF-8：编码是六个字节“EF BB BF E4 B8 A5”，前三个字节“EF BB BF”表示这是UTF-8编码，后三个“E4B8A5”就是“严”的具体编码，它的存储顺序与编码顺序是一致的。

from：
http://blog.chinaunix.net/u2/76292/showart_1272892.html

chatler 2009-12-13 12:50 发表评论