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