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