前几天在B站上面有幸逛到一期关于网站 高并发性 高可用性 伸缩性 的架构方案思路科普视频,收益匪浅。
所以把心得理解记录下来，以备日后使用..
链接为 https://space.bilibili.com/57401628/#/
恰好身边有3台洋垃圾 所以可以使用几台洋垃圾做测试
洋垃圾1:
超微C612服务器 因为使用的是多核心 低频率的ES亮机U 所以计算性能中等,内存最少
洋垃圾2:
Dell PowerEdge R820 计算性能最强 内存数量最大
洋垃圾3
Dell PowerEdge R720XD 使用两颗2680 C1 计算性能介于超微与R820之间, 内存也是比较少
这边使用的是核心数量最多, 频率最低的超微来做网关服务器 因为这台服务器不需要做大量计算,只需要对各个节点的情况进行监控 并且分配新客户和瘫痪节点的客户到最优节点即可
应用性服务器负担了最大量的计算任务 所以这版使用R820 并使用虚拟机来虚拟多台物理机来模拟高可用架构。在其中一台节点服务器(虚拟机)当掉之后, 由客户端在心跳包超时/断线之后重新请求连接 由网关服务器重新分配一台最优节点继续提供服务(这种方案在网页服务比较适用,但是对于多人同屏的游戏来说的话 可能就会存在一些问题 设计思路应该也需要做相应调整)
在多人同屏游戏下 如果遇到一个节点瘫痪的情况,最理想的情况是记录下当前Map的所有对象的状态值 然后整个移植到另外一台节点上面，这样的话 客户端感受的情况可能是“”卡“”了一段时间之后网络又OK了
但是这样的情况下 负担这部分客户的节点在短时间内必然会有一个疯狂的数据库读取操作(如果2秒时间为比较理想的时间的话) 在两秒内 这台客户端就需要在数据库内读取另外一台节点所有玩家的数据/状态 这将必然造成服务器的负载增高,有再次瘫痪的可能. 并且所有玩家必须以集合的方式同步移动到相同的节点， 这也加大了设计上的复杂程度 所以个人觉得并不可取
在这种情况下目前个人想法是制作一个“影”服务器，这是之前研究Raid1磁盘阵列受到的启发。我们这边把每两个节点组成的阵列成为A阵列,而在A阵列下有A1节点和A2节点。
假设A1节点目前是正在运行的游戏节点，所有发往A1节点的数据包同时拷贝给A2节点(或者以其他方法使得两个节点数据同步),这样的话在A1节点瘫痪的时候 A2节点可以立即从影备份节点转化为游戏节点，同时把已经瘫痪的节点服务杀掉 重新启动A1节点作为A2节点的影备份---当然 这也是一个很笨的方法= =....
待编辑
