Sheppard Y

keep thinking keep coding.

集群实现细节(3)-DB集群

2016-07-11 日更新 
此篇博客已经迁移到新博客,并做行文检查和优化排版:
http://blog.clawz.me/2013/12/06/13-game-cluster-design-detail-3/

 

 

一、纯redis集群

    如果redis不止做cache,也做持久化,那就得好好算算我们的业务规模需要多少台机器来支撑。1000w注册玩家,每台机器16G内存(为了保证效率取3/4为可用,即12G)。

    如果每个玩家1M数据,总约9765G,不算热备,需要814台机器。每台机器存储1.2w人。

    如果每个玩家16k数据,总约153G,不算热备,需要13台机器。每台机器存储77w人。

    如果每个玩家1k数据总约9.5G,不算热备,需要1台机器。每台机器存储1000w人。

    注册玩家会越来越多的……

 

二、mysql做持久化,redis做cache

    只说存储,一个mysql支持几T数据没什么问题。例如上边1000w注册玩家,每个玩家1M数据,总数据近9.5T,存一个mysql足够。但是如果高峰在线玩家并发到100w,需要将大部分操作规划到redis这个cache上。否则mysql仍然因磁盘IO太多吃不消。

 

(一)与纯redis集群相比的劣势

(1)好友需要看离线玩家的信息,而离线玩家在mysql里,如果频繁?

    把离线玩家可能被别人查看的信息不存mysql了,改用redis做持久化。

(2)GM工具改玩家消息,需要改mysql和redis的cache里。会不会容易出问题?

 

(二)优势

(1)redis只做cache集群了,用twemproxy管理就行了。如果redis做持久化,还是需要自己来分片,且早期就要规划好。

(2)单个玩家的数据涨到1M的时候,总用户涨到2000w~3000w,再加两个mysql。

 

三、redis做cache+热数据持久化,mysql做冷数据持久化

    这里其实就是将二里边的每个玩家的部分很热的数据从mysql移到redis里做持久化。但是玩家在线时,他的数据基本都算是热的。所以这个方案不是很好设计。

 

 

最后、参考

1. redis官方关于分片的文章:http://redis.io/topics/partitioning

2. twemproxy文章:http://antirez.com/news/44

 

 

posted on 2013-12-06 16:53 Sheppard Y 阅读(844) 评论(0)  编辑 收藏 引用 所属分类: 设计架构


只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


<2013年6月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

导航

统计

留言簿(1)

随笔分类(77)

随笔档案(58)

me

基友

同行

业界前辈

最新随笔

搜索

积分与排名

最新评论

阅读排行榜