[八卦杂谈] 聊聊关于50的IT技术。 [复制链接]

mrmengyi

论坛元老

Rank: 8 Rank: 8

贡献: 0
金钱: 2574
性别: 保密
威望: 0
最后登录: 2020-12-25
精华: 0
帖子: 873
积分: 3447
阅读权限: 90
注册时间: 2011-10-13
UID: 119414175

电梯直达

楼主

发表于 2016-7-21 10:39:47 |只看该作者 |正序浏览

本帖最后由 mrmengyi 于 2016-7-21 10:39 编辑

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

先举几个反例：
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秒级）。不符合条件的情况下不会成交。

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