安利一波Redis:To游戏后台开发的小伙伴

一、常见的游戏使用数据库方式

1、mysql或mongo等关系数据库落地，redis作为缓存、排行榜、消息队列使用

    好处：

架构比较传统，程序员接受度较高。Mysql等数据库较成熟，组件丰富，数据库运维方便。

缺点：

进程扩容、更新、down机重启需要去冷数据库中重新拉取数据，或者做数据转移，容易产生性能瓶颈。

如果对数据做缓存则会有多份数据同时存在，容易导致数据不一致问题。还有缓存穿透现象。

    特别是全区全服游戏，数据库压力较大。

2、共享内存缓存数据，再加上1中的数据存储方式

    利用共享内存缓存数据，进程更新、重启直接从共享内存中加载数据。

    好处：

    只要不重启丢失，热数据一致存在内存中，带来极致的性能。比较适合腾讯这种大流量厂商。

    缺点：

    数据存储多份、需要自己写扩容逻辑、数据路由也比较麻烦。

3、数据存储完全使用redis

    好处：

    性能高，不需要关心扩缩容，数据路由问题。

合理使用，数据库这方面完全可以抗住大平台导流量的压力。

解放程序员心智，可以花更多精力在玩法、场景等游戏核心体验上。

    缺点：

全内存存储，成本较高。

全redis方案在互联网行业不流行，程序员接受度较低，或者直接没考虑过这种用法。

无法自定义数据结构。

二、Redis能为游戏带来哪些好处

游戏中的玩家数据其读写都是有明显的约束的---玩家ID。Redis这种数据库和游戏可以说是天作之和，非常适合用来存储游戏数据。

1、高性能、高可靠性

   单redis实例每秒可以达到10万+QPS，近似本地内存的性能。

   据了解还没有因为redis本身的bug造成过游戏down机，或者redis自身down机情况。

2、数据结构、接口丰富、不需要提前配置数据结构

   Zlist:排行榜

   Hash:

   Set:

   ...

   除了需要强关系查询的功能，基本都可以找到实现方案。

   最后还有万金油lua，涉及到事务，自定义操作都可以通过lua实现。

3、托管绝大部分数据，取代掉游戏中大部分的状态数据

基于redis的高性能与丰富的数据结构，可以将游戏绝大部分数据放入redis中，进程中只缓存变化特频繁丢失对系统无影响的数据（如对战中的玩家位置，某次战斗中的HP等），系统可以做到随时重启、更新、扩容。方便运维、减少各种原因导致的停机对游戏体验的的影响。

   例子：某休闲游戏的猎魔模式（玩家实时上传自身位置、在特定地点、时间点一起刷怪打怪），相当于一个简单的MMO系统。除了房间里面的战斗数据，都是实时存入redis，进程中不缓存数据，做到了不停机、实时更新系统。扩容、单进程down机对玩家无感知。单台物理机，32个redis实例，最高支持20万玩家同时在线。

三、Redis目前存在的问题

1、扩容困难

   官方集群方案对客户端不透明。

   开源的代理不适合游戏:codis本身性能较低，容易造成单点。Twemproxy除了上面的问题外也不支持在线扩容，没人维护(例如新加入的geo命令就不支持)。

2、落地方式比较粗糙

   Rdb全量落地、利用系统cow特性，fork子进程进行落地。需要两倍的内存容量。

   AOF实时落地

3、数据无法回滚到任意时间点

   Rdb落地间隔较长，aof格式中没有时间戳。回滚只能回滚到大概的时间节点，不能保证强一致性。

4、数据全存内存中

   成本较高，机器有问题则数据丢失，利用rdb与aof加载数据需要时间较长。

5、单线程

   单线程避免了线程切换和竞态产生的消耗。但是对于每个命令的执行时间有要求。如果某个命令执行时间过长会造成其它命令的阻塞。

我们需要的Redis:

四、自动化运维、平滑扩容、高可用

1、自动申请、部署redis系统

2、通过代理实现集群功能、代理和后端的redis都可以平滑扩容

3、代理屏蔽后端redis实例的主从切换

4、日志功能的二次开发，必要的情况下可以回滚到任意时间点

五、全面的监控预警系统

1、zset,list元素个数，热key，大key，慢查询

   有的时候开发会将大量数据存储在一个key中，造成key的数据量太大，容易造成系统阻塞。

   通过监控热key可以找出系统单点瓶颈。比如一个全区排行榜操作太频繁造成系统卡顿。可以实时告警，为开发优化系统提供建议。

   大key和慢查询是各种数据中基本的监控项。

六、冷热自动分离

1、冷数据淘汰出内存，存入硬盘

2、自动备份、扩容

3、方便好用的日志，数据导出等周边工具