《王者荣耀》是由腾讯游戏天美工作室开发的MOBA手游大作。作为全球用户数最多的手游，无论玩家什么时候上线、玩多久，王者荣耀总是如丝般顺滑。其实，每一次响起那句经典冲锋号"稳住，我们能赢"的时候，对网络环境、手机性能、服务器端的能力（尤其是数据库的能力）的考验就开始了。
峡谷的战场，就是数据的战场，每一次团战都是在海量的数据中增删改查。接下来，就为大家解密在这款现象级手游背后的腾讯云自研游戏数据库TcaplusDB数据库技术。
面临的问题
对于王者荣耀而言，数据库是灵魂，承载着所有系统的信息落地。任何一款游戏的成功都不是偶然的，王者荣耀在保证游戏的挑战性、趣味性和多样性上做了很多功夫，仅系统就有几十个，包括战斗系统、玩家系统、铭文、商城、角色、物品等，目前后台数据量已高达数百TB，1个区有100多个表且还在不断呈几何级增加，这对数据库性能要求非常高。每一次王者峡谷爆发的大小战役中数据读写甚至每一次请求都不能超过10毫秒，稍有延迟，就会影响数以亿计玩家的游戏体验。
如果说要实现PB级数据的秒级延迟，难度相当于能在1分钟内完成给高速行驶的汽车换轮胎，那么实现PB级数据的微秒级延迟，技术难度不亚于要求在一秒内把换好轮胎的汽车开到月球。
另外，对于底层架构来说，相比较于其他类型业务，游戏业务除去常规的业务高峰时间预估之外，很难做到业务爆发的时间准确判断，作为国民手游的王者荣耀也存在因各类突发事件和特殊时期带来的巨大流量，这对底层数据库自动扩缩容能力提出了巨大挑战。
解决之道
PB级数据微秒级延迟
传统关系型数据库显然完全无法达到这样业务要求，因为在游戏业务中要求实时返回，在涉及逻辑时需要避免关系型查询，一旦逻辑复杂，就会导致性能低下。所以通常情况下，如果使用主流开源数据库MySQL等，在业务的开发设计中无法享受到作为关系数据库的完备功能，却背负了由此带来的性能包袱。如果加入纯内存数据库作缓存，又会因为cache+存储这种形式带来极高的架构成本，不仅需要考虑不同数据库的开发逻辑也要考虑不常使用的数据落盘问题。
腾讯自研数据库TcaplusDB，专为游戏而生。作为NoSQL数据库产品，TcaplusDB具备高性能/低成本、高可用性、无损伸缩能力，提供表的抽象描述，同时使用ProtoBuf作为表描述语言。但其核心存储本质上是一个具备持久化能力的内存key value系统，在内存中进行KV式数据存储，通过内存池共享、冷热数据分离等技术保证海量数据的微秒级返回。
要实现数据的微秒级读写，关键在于扁平式的访问模式与内存池共享技术。这要求数据库架构要足够简单，王者荣耀通过TcaplusDB提供的异步读写接口直接连接TcaplusDB 接入层，接入层直接提供路由信息连接至数据库操作数据库数据，完全不用关心数据分片和主从逻辑的细节，大大避免了业务的复杂开发逻辑。在这种访问模式下，游戏服务器操作平均响应时延小于4ms，存储层读写时延为微秒级。
TcaplusDB架构图
内存池共享逻辑则也很简单，同其他内存数据一样，将数据缓存于内存当中，用户访问数据直接从内存中读取，无需经过磁盘，这极大提升了读写效率。而一般场景下表的大小往往会直接影响查询效率，面对海量数据，通常解决办法是分库分表。在游戏业务中，需要在设计阶段就要适当的进行分表，拿角色表举例，角色的各种数据放在一张表对于逻辑开发是最简单的，但出于表大小的限制，需要把具有增长潜力的数据字段放在新的数据表里，这就意味着角色的内存对象数据要根据各个表的数据合并而成。而TcaplusDB面对超大单表的场景下，通过分表因子将大表平均打散存放至不同的集群分片当中，访问指定数据无需完全加载全表，仅仅加载数据所在分片即可，极大提升了查询性能。
王者荣耀的PB级数据中，40%为不常调用的冷数据，比如历史开局信息等，为提高业务响应效率，一个行之有效的办法是降低冷数据的读写次数。TcaplusDB采用内存 + SSD盘存储的方式，单个引擎文件前1GB映射在内存，冷数据放在磁盘，并采用LRU算法进行冷热数据交换，游戏服务器的get操作触发LRU换入操作，数据库LRU线程负责LRU换出，保证热数据存储在内存里，从而实现cache命中率高、单次读写延时低。
3小时扩容400万PCU，用户无感知
春节期间，TcaplusDB陆续对各个大区7个表进行了15次扩容，扩容集群服务只增加了20组（原330组）,最后一次扩容是在26日，时间紧任务重，TcaplusDB在1小时内完成了突增100万-200万 PCU的扩容，且在扩容过程中玩家无感知。
这是个几乎不可能完成的任务，但是TcaplusDB交上了满分答卷，它是怎么做到的？
面对随时会出现的业务高峰和低谷，人力运维存在明显弊端，这就对系统的智能化能力提出了高要求，而高频的业务忽高忽低，导致伸和缩同时出现，会使得数据库无法处理请求，严重的还会导致数据库宕机，所以要实现系统智能根据业务情况进行自动扩缩容是非常困难的。
这个问题在TcaplusDB面前迎刃而解。TcaplusDB云上管控系统为每一个用户设定了自动扩展能力。TcaplusDB会根据数据表的使用量情况来计算出扩容窗口时长，当扩容窗口内无法支撑业务增长的读写能力时，系统会自动发起扩容，扩容的量级由用户单位增长速度的等级、所处实例规格以及数据库处理能力来决定。系统将自动对接入层与存储层进行横向扩容，拉起各个地域中空闲的服务器，根据自动扩容逻辑进行一致性hash数据迁移，平均每秒数据传输速度在300M以上，从发起扩容到完成扩容，业务侧毫无感知。
TcaplusDB采用了分布式架构，整体分为接入层、存储层、管理层。数据存放于存储层中，数据路由信息存放于管理层中，用户连接通过接入层对数据库进行访问，每一层均可实现自由的快速伸缩容。当业务请求突增，在服务能力无法支撑前进行告警，并自动进行横向扩容。当业务请求降低后，还可根据当前使用情况进行自动缩容，以降低成本。自动快速伸缩的能力足以应对业务突增峰值的痛点。
存储层扩容采用无损搬迁方式进行的
业务完全无感知
无损搬迁时，首先从数据搬迁源端的tcapsvr slave全量扫描数据文件，现场计算hash值，将需要搬迁的数据打包发送到目的端tcapsvr master；当全量的数据扫描完成后，将从全量数据搬迁开始时的增量数据也搬迁到目的端tcapsvr master，在最后切换路由前，接入层会缓存短暂的读写请求，保证完全无损。
接入层扩缩容是无损的
业务无感知
TcaplusDB自研了SDK，SDK内维护了接入层一致性hash环，天然支持增加或者减少接入层节点。
接入层扩容时，新的接入层节点启动后，再由管控节点通知SDK更新本地路由hash环，则请求可能从新的接入层节点发送和接收。
接入层缩容时，接入层需要进行安全退出，先告诉SDK不再朝自己发送新的请求，再朝与自己相连的存储层节点发送染色包，确定所有的请求的响应都成功返回后，再等待1秒钟后退出，确保SDK不会出现超时丢包现象。
结语
综上所述，TcaplusDB是一款腾讯自研的高性能内存式分布式数据库系统，具有无损扩缩容、高可用、易用性等特性，针对游戏业务的开发、运营需求，支持全区全服、分区分服的业务模式，提供不停服扩缩容、自动合服等功能。同时，TcaplusDB 提供完善的高可用、容灾、备份、回档功能以实现7*24小时五个9的可靠数据存储服务。
历经腾讯内部8年的游戏经验积累，广泛应用于王者荣耀、刺激战场、穿越火线、火影忍者等数百款流行游戏的TcaplusDB，现已通过腾讯云向全球游戏业务提供服务。