公司做网站要注意什么,上海做设计公司网站,专业做生鲜的网站,汽车网址都有哪些原创文章#xff0c;转载请注明出处#xff1a;server非业余研究http://blog.csdn.net/erlib 作者Sunface 为什么我要选择Erlang呢#xff1f; 一、erlang特别适合中小团队创业#xff1a; erlang有异常成熟、经过电信级别大规模验证的OTP应用库#xff0c;仅仅须要非常ea… 原创文章转载请注明出处server非业余研究http://blog.csdn.net/erlib 作者Sunface 为什么我要选择Erlang呢 一、erlang特别适合中小团队创业 erlang有异常成熟、经过电信级别大规模验证的OTP应用库仅仅须要非常easy的代码就能建立起异常稳定、容错性强、扩展性强、高并发的server框架这也是erlang最宝贵的核心价值所在。 二、erlang是天生的并发语言 erlang的并发特性是语言级别的从开发伊始就採用了CSP并发模式, 以进程为单位进程间没有共享内存变量不可变的实现方式保证了无锁的并发模型因此也是异常高效的换句话说你仅仅要像寻常一样写代码就能并发全然不用担心不论什么底层实现你的代码能完美的并行执行在多核server上假设你能写出美丽的并发级别的算法和代码(尽量少的顺序代码)那在32核机器上就能跑出32倍性能 Go 语言的并发模型也是取经于Erlang,可是我觉得Erlang的并发模型更优秀由于进程间全然没有共享内存全然无锁。 三、再介绍下我当初的业务需求 一款多人在线游戏,一个玩家走一步都要把消息广播给同屏的玩家,玩家聊天,战斗更涉及到大量的消息广播;怎样应对?再有一个及其普通却不太easy搞定的的需求:在线玩家列表怎么实现?是啊,你是不是在想用哪种锁合适?提到的两个场景的关键词是:高并发,大量广播;可能你还会想到锁. 我尝试过在.net下使用完毕portTPL库protocol buffer来完毕上面的功能,可是并没有通过測试的检验,測试模型是聊天.在收发消息方面,client和server一对一的收发压力不大,可是一旦开启广播,压力一下就上去了.对象的频繁创建会导致垃圾回收,而垃圾回收会导致CPU和内存都飘忽不定,中间增加对象池会得到一定缓解,可是不能彻底解决这个问题,然后想到的就是人为干预垃圾回收,推断标准是什么呢?那就是用PerformanceCounter吧,结果发现PerformanceCounter一次调用分配的内存相当大!最后一版的结果是:聊天室模型,一人说话广播给全部人,300人在线可以稳定,人数一多就開始不淡定了.这些都是经过量化分析得出的结果,使用的工具是Visual Studio2010中的Performace Profile工具. 须要解决的第二个问题就是并发加锁,最简单的測试模型就是在线玩家列表.这个问题相同困扰了我非常久,尝试各种锁,还是在抛异常,要么就是性能的下降,问题此起彼伏.兴许还要解决TCP通信的数据格式,以及粘包等问题...... 项目时间紧张,存在的风险非常多,要尽快把技术方案确定下来然后去推进别的事情;可是可供选择的方案有C和Erlang.坦白讲我和团队的基础假设使用C方案,一定能搞出来,可是排错和性能优化将是一个巨大的挑战.那么Erlang呢?从开篇引用的那段文字看,好像这就是我须要的,简单了解了一下语法,还是非常惊喜,因为之前对F#有过接触,一下感觉非常亲切.并且我特别关注到: 长处 1.面向并发,有成熟并且久经考验的框架可供使用,网络部分已经经过了良好封装 2.内存缓存解决方式进程字典,前者的读写速度是50NS100Ns级别的 3.对二进制数据解析的语法是直观,简单,强大(游戏中有大量的二进制数据要处理 4.没有共享内存! 没有锁!(我们在代码中没有过显示使用锁) 缺点 1.从一种语言过渡到还有一种语言,会有各种不爽: 2.控制逻辑简单仅仅有if 和 case ,并且有if没有else,没有continue break goto 3.包含kernel库和standlib库在内,非常多函数和变量的命名和传统语言不一样 因此我们就决定了採用erlang来又一次写一套全新的架构事实证明当初的决定是无比正确的一个极少须要重新启动、能热更、稳定的游戏server实在是太重要了并且开发过程和维护是如此的高速和轻松我们的团队一致觉得从来没有想过开发会是这么一件愉快的事情 既然Erlang已经被我“吹”的快飞起来了为什么还要使用Go 鉴于Go语言已经妇孺皆知了我也就不介绍了大概说说我自己的情况我这人没啥其它兴趣爱好业余时间绝大部分都花费在所谓的“程序猿要不停的学习才不会落伍”上因此在11年的时候知道了go断断续续学习了一年后Go1.1版本号出来后发现改进非常大就開始认真研究并常年混迹在google-group及国外大牛的博客世界中自我感觉还能够。当然我绝对不是Go的“朝圣者”,也发现Go确实不是非常完美详细能够參见“为什么我要放弃Go“此文作者的观点我尽管不敢全然苟同可是有些观点还是赞同的比方说非常多Go爱好者是非常护短的假设你敢说什么“坏话”就等着被查水表吧 。 项目nodejspythonc/rubyerlanggolang体系成熟43553开发效率55345性能33554加密公布30435逻辑简单55345易学易用55254跨平台55555从上表中能够看出 erlang和go之间的互补性还是非常好的,Go的体系成熟度确实还有待提高 因为Erlang和Go都是非常棒的语言这里就出现一个问题二选其一还是物尽其用经过深思熟虑后我和团队选择了后者。首先erlang的OTP写server并发框架非常之简单、稳定且高性能erlang的Mnesia数据库也是非常轻量速度非常快分布式简单使用起来也非常原生态(是Erlang标准库支持的全部的这些都能把程序猿从繁琐的工作中解放出来可是erlang也有个挺重要的问题(在不同业务场景中此问题或许非常突出也可能全然无关紧要至少85%的情况下不算一个问题)它是虚拟机语言对于顺序代码的运行速度仅仅有C的七分之中的一个尽管能够利用多核的优势可是在大型mmorpg中消息密集时CPU的瓶颈还是挺明显的会影响玩家顺畅的体验感觉(ARPG)。 因此我就想假设逻辑这部分用Go来写是不是能够非常好的利用这两个语言的长处进行互补心动不如行动由于我们的erlang游戏架构的藕合度还是挺低的因此分离出来地图server用Go又一次实现了下通过socket跟erlang架构部分进行通信发现效果异常之好Go的性能、并发的原生支持再配合上erlang写游戏框架在性能上已经绝不亚于C框架可是后者大家都懂中关村程序猿据说平均寿命50多岁非常大的一部分原因是由于这个。 以后的路怎么走 混合型编程会是以后的主流由于没有哪个语言是完美的包含被众多“朝圣者”所推崇的Go,假设我们能依据自己的业务场景选对合适的语言那不敢说事半功10倍至少事半功倍应该是有的所以不要被主流语言(Java,C)禁锢了我们的世界局限了我们的创新假设能做到轻松愉快的开发那这个世界该多美好
