集群实现细节（3）-DB集群

集群实现细节（3）-DB集群

 

一、纯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