聊聊关于50的IT技术。

mrmengyi

刚看了几篇，关于服务器卡的帖子。
分析的头头是道。还是那句话：然并卵。
所以，技术的问题就丢给游戏商家自己解决吧，玩家只需要提出需要。

先举几个反例：
1、“现在九维的一台物理服务器上通过虚拟机的模式同时运行着几个游戏大区是不争的事实”
评论：网页游戏，应不需要搞虚拟机这么麻烦。正巧我在公司的工作也涉及一些虚拟化的工作。
　　　使用虚拟机，平均会损失 30% 的计算资源。虚拟机的应用主要是在弹性计算资源的调配和系统隔离。
1.1) 弹性计算资源的调配：比如说30人工作，分三班倒。只需要15台的虚拟机资源，超分2倍，可以分配30个虚拟机，大家上班时间不一样，可以轮着使用又不互相干扰。
1.2) 系统隔离：网络服务的应用主要是多个托管商家在一个服务器上，使用虚拟化环境隔离，这样一个厂商的app挂了，不会影响同一个虚拟化环境的其他厂商。
　　　50的系统，用到了集群、负载均衡、多站点、高并发(ngnix)、高速缓存(memcache)等技术。在刚开发的那段时间，尚不流行虚拟机技术。

2、“所以其中一个游戏区因为“小号过多”等原因会争抢同一台物理服务器的性能资源，造成同服务器的其它区出现卡顿甚至崩溃。”
评论：同1.2。如果真的使用了虚拟机，实际上通过监控、隔离，不会因为一个区的崩溃，导致其他区的崩溃。

3、“给每个区增加角色数量上限”评论：实际上是有上限的。我记得有人注册小号遇见这个情况。可能是百万吧，记不清了。
-----------------------------

那么，挂小号影响多少性能？
实际上要看是怎么挂机。挂了哪些。
多挂一个号，会造成多少服务器的开销呢？做权威的应从运维人员这边获取数据，例如每秒请求数量，每秒完成请求数量。
虽然从研发角度并不能准确的评价，不过我可以尝试做一些分析： 一个号占用的资源，大约有：数据库中记录的数据；小号向服务器发出的请求。
1、数据库资源对于游戏，数据库的资源小号基本可以忽略。每个账户的数据有限，所以对数据库的负担增加只是线性。对于检索的时间，是对数级别（查询时间复杂度）。
通俗来说，如果100个号查询需要1毫秒。那么：200个号查询时间是1.15毫秒、300个号查询时间是1.238毫秒、400个号查询时间是1.3毫秒。

2、计算资源（CPU消耗）
CPU的消耗可以分为两部分：http协议处理的消耗和内部计算的消耗。
　　有一些操作，可以合并。例如：卖999个技能书，可以分999次每次卖1本，也可以1次卖出999本。很明显，前者所消耗的CPU资源是后者的999倍。如果大量的操作可以合并，可以减少很多服务器压力。
　　另外，不同的操作，对于CPU的消耗还有不同。例如，卖一本书和打一次怪，对于服务器的压力是不同的。前者只需要简单的计算，把书扣除并增加铜币；后者需要读取双方数据进行对战计算。根据实测数据，三万号只挂日常，不会影响现有服务器的运行。一个小号的日常请求数据为7次以内。21万的http处理，大约单线程120小时以内，对于集群来说是非常轻松的。


------------------------------
有朋友讨论这次问题，提了几个观点，个人比较赞同，这里纯粹转发：
1、不应截断大家获取铜币的方式。
2、老友卷、瑕疵石交易是触发大量建号的原因。
3、减少游戏的不必要功能。最典型的就是加血加蓝的药。在50世界里，这两类药就是两个大大的笑话。
4、允许多物品一次性兑换和买卖。减少服务器开销。
　　BTW： 一次只能换一个，或者买一个，这一定是有多线程并发BUG。例如：一周能换3次的突破进阶石，为嘛一次只能换一个？
　　　　　不要问我为什么知道，用脚趾头都能想得到。



==================
建议彻底修正并发BUG。按照9wee技术员的尿性，这个问题应该还没彻底解决。现在是能打补丁的就打补丁。反正能糊弄就可以了。
这里，附送一个第5点的解决方案。是某互联网公司（上市公司，算比较大的）技术总监给我们讲课的时候get的方法。“如何解决高并发场景下，同时保证性能和数据一致性”
》》这方法在互联网上都是用烂的，不知道9wee的程序猿们是否知道。

如果两次并发交易，传统的加锁会导致处理队列排队，十分影响效率。而多台服务器并发，有可能导致花1份的钱，买到2份的商品。
众所周知（在程序猿的世界众所周知），数据库的分库分表（横向切割和纵向切割），能保证角色的数据分散在不同的数据库。这样一个角色的频繁请求只会影响同一个服务器，并且可以在该服务器排队。
同时，数据库层面可以通过事务的方式，保证一致性。一个单一的SQL，就是一个事务！


回到问题：如何保持高效和数据一致性？
我们的目标仅仅是高效+数据一致性。那么当并发请求到达时，在计算处理层面，可以使用集群的分布式计算，在不同的服务器上处理。
在SQL之前记录一下当前的账户的余额，例如当前余额100元。然后处理交易数据（可以较长时间）。
然后在最后增加购买数量的时候，SQL里增加一个条件：WHERE '余额'=100
这样，只要余额不匹配就不会交易。而且处理交易的部分可以分布式急死俺，还可以有相对长的时间（10秒级）。不符合条件的情况下不会成交。


最后补充说明：我不是搞互联网的，也不搞大规模集群和高并发处理。只是我觉得这个方式是一种非常廉价和易于理解的方式。
有不正确的欢迎指导，写的不对了也不必嘲笑，大家切磋切磋。

张天师

不明觉厉啊

stoneyu

我代表9wee表示，你被录用了，明天来上班！

一剑浪子

stoneyu 发表于 2016-7-21 10:43
我代表9wee表示，你被录用了，明天来上班！

我表示9维舍不得聘这种

Destiny123

- - 我个人觉得一个数据库的行锁即可解决并发提交问题，针对关键表格关键字段做行锁，然后配合事物。

星月魅影

好深奥~~~！！！
没看懂~~~！！！
不过 看起来 貌似不错的样子 哈~~~！！！

囧 囧

找的技术人员，都是二把刀~~就会复制，拷贝。改几个参数。。每个月拿几万高工资。实际的成效只有250块。。。。我要是他们老板。不天天骂死他们。。。

小老婆那个

这才是九维需要的高科技人才！！！

ssssssssssssssssssss

stoneyu 发表于 2016-7-21 10:43
我代表9wee表示，你被录用了，明天来上班！

这公司也配录用他,这篇的东西**的程序员能了解完处理掉上面的问题以经不错了

破比无悔

屌炸天啊啊啊

mrmengyi

Destiny123 发表于 2016-7-21 10:54
- - 我个人觉得一个数据库的行锁即可解决并发提交问题，针对关键表格关键字段做行锁，然后配合事物。 ...

各种锁都会影响性能。
无锁设计的思想已经出现很久了。有兴趣可以看看。

傷心恶意

回复 mrmengyi 的帖子

我想问问M神 一周是换三 个进阶石么  求bug。

雪心吻蝶

innodb的行锁效率很高的，不会影响，并发BUG问题是出在cache里的热数据无锁
而且游戏应用怎么可能直接读写数据库-。-，直接读写数据库分分钟爆服，必然是有冷热数据分离，内存操作，异步同步内存数据到数据库的
大量小号其实只要不是同时跑副本，对服务器几乎没压力
至于集群……分区分服的游戏怎么可能用到集群来处理……无非就是两台机器一组服，对冷门区直接一组服开多个virtualhost而已
m你想的太多了
一个游戏上线之后的维护必然不是原始开发的那一群人，主力研发早就抽调走去做别的游戏了，维护都是生手上手用的，不断有BUG说明研发测试流程不完善，99%的小型公司都这样，成本是个没法规避的问题。

安静0906

好腻害的感觉。。。。

小队长

   最最关键的问题是本来卖老友，瑕疵，铜锭（这个其实相当于在卖的）的收入都被卖小号挂的赚去了。官方现在是宁可送你们老友和瑕疵都不想你们去照顾外挂的生意。 只是不能送得太猛，怕引起前面花钱做满老友和6阶的大神的不满。 所以吧，跳的高的玩家只是因为已经投了钱在小号挂上了。 对于一些懒人玩家来说，有点意外之喜的味道，但也要记得相公这样为大家谋福利的人，不能落井下石。
   一个游戏的生存离不了玩家，也离不了玩家的钱，能够这两方面做好平衡，那就是要做到玩家乐意花钱来玩一下这个游戏。 有个帖子说得很直白，让花时间的玩家来做为花钱玩家的道具，如果游戏最后演变成花钱的赶不上花时间的，花时间的赶不上在外挂上花钱的，那这游戏就是彻底的失败了。
   这里大胆设想一下，所有的老友，瑕疵，等一切可交易的装备，都通过公共平台，卖家用礼券，黄金或者铜锭明码标价的交易。 上架后任何玩家都可以抢买，官方照常提成。会不会把花钱花时间的玩家合理的激发起来呢？

一个人的约会

小队长 发表于 2016-7-21 11:43
最最关键的问题是本来卖老友，瑕疵，铜锭（这个其实相当于在卖的）的收入都被卖小号挂的赚去了。官方现 ...

问题来了。。。。游戏需要的是花钱的玩家。。。。。你连买挂的钱都不出的。。。。人你会去充值吗。。。。会去充多少吗。。。。。

Destiny123

雪心吻蝶 发表于 2016-7-21 11:36
innodb的行锁效率很高的，不会影响，并发BUG问题是出在cache里的热数据无锁
而且游戏应 ...

内存里做个字段锁也是一样，反正并发bug的问题就是多线程并且无锁。
要么就把它做成单线程，锁都不需要，要么就做锁。

hotGANDOM

安静0906 发表于 2016-7-21 11:41
好腻害的感觉。。。。

摸到一枚女神大人

安静0906

hotGANDOM 发表于 2016-7-21 11:45
摸到一枚女神大人

小白托你歪楼咯。。。

heypop

我知道你也是做IT的，但是说的都是秀才的话，武林的问题，不简单仅仅是程序员及编程技术上的问题，这还涉及到整个游戏的架构，有没有好的架构师，公司内部的组织和管理、成本核算等等一系列问题。
“50用到了集群、负载均衡、多站点、高并发(ngnix)、高速缓存(memcache)等技术”，你能找出一家现在不用这些技术的网页游戏吗？就像说一个人必须睡觉和吃饭，这都是废话。
“评论：同1.2。如果真的使用了虚拟机，实际上通过监控、隔离，不会因为一个区的崩溃，导致其他区的崩溃。”你的说法在理论上都没有问题，但是实际上并非如此，就像十字路口的交通问题一样，如果大家都切实遵守交通规则，就不会出现那么多交通事故，但是事实呢？武林主要是托管在浙江金华的IDC机房，具体双方的合作方式外人并不清楚，这还包括硬件条件等，从综合运营成本考虑，九维游戏的部署模式也无可厚非，但是绝对不会连监控和隔离都不知道，肯定是受到了某些条件的限制和约束。更何况武林是10年前上线的游戏，没有采用现在流行的比较彻底的云架构。
其它的技术问题，在这里讨论也没啥太大意义，一个公司也罢，一个单位也罢，并不需要人人都懂，只要有一两个高水平的就足矣，玩家只能祈求九维能找到高水平的技术，能稳定的待住，保持一个技术的持续，所有的技术问题就都不是事。