shiweizhang 2015-10-27 1.7k浏览
摘要
大数据具备数据量大，数据结构多样，处理分析耗时，可挖掘价值潜力大的特点。除了具备这些特点，大数据时代的游戏数据还具备如下特性：交互性强，社交互动活跃有的还打破了游戏分区隔离；数据更新频率与数据插入读取频率的比例相对大部分非游戏类互联网业务要大得多；记录条数很大但单条记录长度较小；数据按用户分布冷却而不仅仅按时间分布冷却；关于用户行为的数据大量而丰富，可被用于数据分析挖掘进而正面影响用户。
Tcaplus是腾讯互娱研发部为游戏定制的云存储服务，本文介绍Tcaplus应对上述游戏大数据存储访问的相关技术思路。
方便无损的数据扩缩容
不同游戏业务的数据规模增长方向通常是不同的也是很难被提前预测准确的，有的增长迅速需要扩容，有的保持稳定不需要扩缩容，有的走向衰落需要缩容。大数据时代的数据扩缩容是个常态，而且范围和粒度多样灵活，一个执行方便(包括自动化)、无损、快速的扩缩容机制显得很有必要。
Tcaplus的数据扩缩容通过不停服数据搬迁实现。为了做到对业务访问无损的数据搬迁，搬迁采用分hash号段进行。在数据搬迁的过程中，对不处于搬迁hash号段里的数据的业务访问不产生任何影响；对处于搬迁号段里的数据的业务访问通常不产生任何影响但若被访问的记录恰巧还没有被搬迁到目的节点则会增加部分时延，产生部分时延的原因是对于这种极端场景会触发事务首先从源节点搬迁数据到目的节点再从目的节点处理数据访问请求并返回响应，对于这种极端场景虽然产生了部分时延但对业务访问来讲仍然是正常处理返回了响应可以说是无损的。数据搬迁的总体结构如下Figure01所示。
Figure01
从Figure01还可以看出，Tcaplus的数据搬迁支持不同节点配对并行进行，这相对串行搬迁调度可以大大提高数据搬迁的速度。Tcaplus系统做数据搬迁时尽量保留了数据的热点信息，即在源节点为热点的数据被搬迁到目的节点后优先存储在内存中。另外，Tcaplus的扩容缩容支持通过Web Portal调度执行以及查看执行状态，方便了运维人员操作。
为了进一步适应大数据时代游戏数据的多样灵活的变化，Tcaplus在扩容缩容自动化方面未来将做进一步提升：自动发现待扩容对象并且从资源池中找到空闲资源作为扩容目标，自动生成扩容计划，只要运维人员从Web Portal点击确认按钮扩容事务便可自动开始执行；自动发现待缩容对象并自动生成缩容计划，只要运维人员从Web Portal点击确认按钮缩容事务便可自动开始执行。
异构数据兼容与软件兼容
大数据时代的游戏数据格式多样并且处于不断变化之中，Tcaplus全面应对这种场景在不停服的前提下不仅做到业务数据不同格式兼容，也做到内部额外管理数据不同格式兼容，也做到不同模块软件的版本升级兼容，如下Figure02所示。并且，Tcaplus通过Api的自动重连机制实现不停服的tcaproxy软件升级，通过Tcapsvr Master-Slave热备机制实现不停服的tcapsvr软件升级。
Figure02
关于业务数据不同格式版本的兼容，过去Tcaplus Api通过内置Tdr Version库实现字段添加字段有限修改的可兼容性，目前Tcpalus Api还通过内置Tdr TLV库实现字段删除的可兼容性。
Slave支撑实时与延迟数据分析
大数据时代的游戏数据具备巨大的数据挖掘分析价值。
为了性能和成本的考虑，Tcaplus系统在处理数据写请求时不需要等待数据同时落地到2个或以上的节点才返回客户端，数据只要成功落地到tcapsvr master便会向客户端返回数据写成功，后续tcapsvr slave有重试机制保证数据能够通过异步的方式被复制到Slave，根据外网实际统计Slave的数据落后时延通常在百毫秒数量级。Slave上的读写负载轻，为支撑数据挖掘分析提供了便利，比把数据先转换进入关系数据库再做数据分析更高效和节约成本。关于Slave支撑实时与延迟数据分析(离线数据分析属于延迟数据分析)的情况，如下Figure03所示。
Figure03
Tcaplus的实时数据分析(非延迟数据分析)通过在Slave进程部署实时分析服务实现，这些实时分析服务以插件的形式工作于Slave进程的工作线程对业务写入记录做实时的字段解析和统计分析，实时分析服务甚至支持将业务写入记录实时旁路到游戏项目组的统计分析进程。
Tcaplus的延迟数据分析通过如下两种方式实现：一是通过遍历Slave节点上的被Slave进程加载着的数据文件实现数据统计分析，Tcaplus底层数据引擎优先将key集中存储到内存区域并且key中带有记录最近被访问时间戳信息，这为快速遍历数据文件打下了基础；二是通过遍历冷备数据文件(离线数据文件)实现数据统计分析，这对于补充统计分析历史数据具有意义，而且该统计分析不占用Slave进程资源。
全方位负载均衡
自动化的全方位负载均衡对于做好大数据时代的游戏数据存储尤其重要，否则会对资源造成巨大浪费甚至负面影响业务的正常数据访问。如Figure04所示，Tcaplus系统在如下方面全方位做到负载均衡。
(1) Tcaplus Api通过一致性Hash算法选择tcaproxy节点从而实现tcaproxy节点之间的负载均衡。
(2) 不同Tcapsvr节点之间通过缩扩容实现高负载业务(数据表)获得较多存储资源，低负载业务(数据表)获得较少存储资源。
(3) 不管是key还是value，热点数据获得宝贵的内存资源，非热点数据获得相对低廉的硬盘资源。相对value来讲通常key空间较小被访问频率较高，为了减少访问key, value的整体硬盘I/O次数，key往往比value更容易抢占到内存资源。
(4) 不管是key还是value，内存中的数据块大小相对硬盘中的数据块大小要小一些，这样可以提高内存空间的利用率，同时内存数据的多次访问不会有明显的性能上的问题；硬盘中的数据块大小相对内存中的数据块大小要大一些，这样可以减少硬盘I/O的次数，同时可能浪费的硬盘空间相对于内存来讲还算比较成本低廉。
(5) 在同一个tcapsvr存储节点之内不同的数据shards可能因为数据访问负载的不同而获得不同数量的内存资源。这样做的好处是：同一个tcapsvr存贮节点之内不同的数据shards之间调整转移内存资源数量对于tcapsvr, tcapcenter等是透明的，避免了数据搬迁调整这种大动作事件(同时影响系统多个节点的事件)的发生；当数据搬迁调整异常或失灵时tcapsvr节点自身还能应对解决其内不同shards负载不均衡的问题。
Figure04
Tcaplus没有把不同机器节点的内存整合成一个内存海，没有把不同机器节点的硬盘整合成一个硬盘海，但在节点内部在不同shard之间以及在各个shard之内将内存和硬盘的负载均衡做到淋漓尽致，同时辅以不同节点之间的数据搬迁实现节点之间的负载均衡。这样做主要是基于如下考虑：继承Tcaplus支持非服务化定制部署提供功能的历史；节点内部的负载均衡没有网络开销更高效，例如节点内部的内存和硬盘之间数据LRU效率高；节点发生故障时可以靠自己便实现数据restore无需依赖别的多个节点进行复杂的综合计算。
立体的可聚合统计告警
大数据时代的游戏数据存储面临着存储节点数量多，部署变化多，不同游戏发展分化大，时不时发生机器硬件故障或网络故障的现实。如果运维人员盯着每一个节点的每一个指标统计告警将会因为统计值和告警消息太多而疲于应付，真正严重的告警消息也会被不重要的告警消息淹没。
Figure05
如Figure05所示，Tcaplus接入改造后的Tmonitor统计告警系统。Tmonitor系统支持进程指标统计和聚合指标统计。Tmonitor系统支持进程指标告警和聚合指标告警。并且Tmonitor系统支持将告警项(包括进程指标告警项和聚合聚合指标告警项)按业务做聚合，不管业务内部有一个节点还是多个节点发生了故障，只会向运维人员发送一条告警消息，根据这条告警消息运维人员可以看到告警的级别(即对相应那个业务的影响程度，即告警的重要性)，并且还可以根据告警消息里的进程指标告警信息迅速看到定位到导致故障的根源进程列表。一个Tmonitor系统还支持和别的Tmonitor系统相互统计告警，实现Tmonitor系统自身的监控保证。
大数据时代的游戏数据存储管理和挖掘利用是个很大的课题，本文介绍了Tcaplus朝解决这个课题的方向所做的主要尝试和努力。
