高可靠高性能廉价MYSQLHA方案在宾果游戏中的应用

yinshi

宾果游戏，要求：游戏中心支持至少20个厅同时接入，每个厅至少50个游戏终端。
使用数据库：MYSQL5.0.42
游戏中心要求：24*7不间断运营，做双机热备。玩家筹码数据不允许中途丢失，对事务完整性要求很高。
买入失败的玩家筹码必须在大厅做退钱处理。
每年产生数据300-400GB
策略：
在开始阶段尽量使用低成本方案占据市场，等待用户认可发现瓶颈后再进一步增加商业方案投入。没有最好的方案，只有合适的方案。
有缺陷的方案有时也有适合的时候。本贴将只做原理解释，细节另外开贴。

yinshi

1.0版本于2009年5月上线。
解决方案概述：
1）使用innodb存储引擎。
2）通过两台HP DL380G5(8块15000rpm)做RAID10保证数据安全性，提供OLTP需要的高性能；(OS:redhat enterprise 5.2)
3）通过Distributed Replicated Block Device实现在Block Device层次的数据镜像。保证磁盘阵列不会存在单点故障。实现存储的热备。
4）通过heatbeat实现HA,并管理Distributed Replicated Block Device。实现开机自动化加载。
在操作系统故障、硬件宕机或生产网络中断的情况下，故障转移速度15s，
heatbeat关闭情况下，故障转移速度4s.
5）通过MON监控mysql进程,故障转移速度2s.
6)通过linux crontab监控mon
7）通过heatbeat管理mysql实例，实现数据库服务的热备。以统一IP ADDRESS对游戏应用提供服务

yinshi

运营实测结果：
数据中心数据库集群工作5个月来很稳定。

yinshi

缺陷：
故障转移时间主要花在heartbeat内部节点之间检测存在性和原主节点释放资源，新主节点加载资源。
主机HA固有缺点几乎不能解决。

yinshi

第一版本缺陷：
故障转移期间，游戏的未提交事务将丢失。游戏程序需要重启。
规避方案：
游戏程序基于JMS框架异步等待故障转移完成，通过异常处理程序捕捉异常重启游戏程序。
效果：游戏中断如能短时间内恢复则从断点继续运行，如时间较长则做废游戏流程处理，向玩家退款。

yinshi

第二版本将借助mysql cluster实现完整功能的不丢失游戏事务，不影响游戏正常查询。事务回滚仅在于程序逻辑。
整个数据库集群对游戏应用透明。游戏应用只需要放心存入数据，不必担心数据丢失或者读写异常。

kider

赞，总结的很好

yinshi

方案适用性：
服务器之间使用直连千兆网线直接相连做心跳并同步数据库数据，并增加直连同轴电缆，防止裂脑。
经测试，每局游戏历时5分钟，大约生成5MB字节数据，合计40MBBIT,速度约为0.13MB BIT/S,远远低于节点间带宽。
潜在风险：
因块镜像（Distributed Replicated Block Device）基于操作系统之上，因此需要监控各节点CPU负载，及时处理负载过高的情况。当负载长期超载时，可能导致块镜像异常。

yinshi

Distributed Replicated Block Device0.7.23版本在重启计算机之后有一个特性，它不会自动实现主备节点重连。为实现自动化维护，使用MON对主节点运行状态进行监控，如果他是孤立状态，就重新连接。Distributed Replicated Block Device更高版本似乎可以自动重连。但是存在另外的问题。

yinshi

性能测试结果：
将70000条菲律宾政府的彩票记录（每条记录是含有25个数字的字符串）拆分为1750000条记录。
使用存储过程实现。
计算过程中通过top度量，mysql 进程cpu占用率60%,时间30分钟。处理完成后cpu占用率降为5%以下。
对存储子系统无影响，在主备节点上验证数据完整性良好。

mysqlkumao

好贴

a_long_river

学习了