2020SACC专场十：分布式存储（下）（PPT下载）

TcaplusDB 是腾讯互娱自研分布式 NoSQL 数据库，立项于2011年，目标是为腾讯游戏提供稳定、可靠的数据存储服务，让游戏研发者能专注于游戏逻辑研发。目前已广泛应用于《荣耀》、《和平精英》、《pubgm》等数百款流行游戏。本次分享将介绍 TcaplusDB 的架构原理，技术实现，游戏场景支持等内容，举例 TcaplusDB 在腾讯游戏业务上落地和使用时遇到的问题，并详细分析针对这些问题 TcaplusDB 团队做的技术优化。
分享提纲及要点：
1. 什么是 TcaplusDB，为什么做 TcaplusDB；
2. TcaplusDB 的架构、原理、场景；
3. 架构、存储模型；
4. 局部索引和全局索引实现；
5. 高可用介绍；
6. 多样化回档机制

10多年分布式数据库和存储系统开发经验，参与建设腾讯自研分布式存储系统 XFS 设计与研发，现负责腾讯自研分布式 NoSQL 数据库 TcaplusDB 的研发和运营，致力于为游戏提供高可用、高性能、低成本的游戏数据存储服务。

EC 编码(纠删码)是一种通用的技术，它在保证数据可靠性的前提下能大幅度的降低磁盘和网络的消耗，Raft 协议也是一种非常常见的一致性协议，它可以极大的降低分布式存储的设计和开发的难度。包括京东云对象存储标准存储在内的很多成熟分布式存储系统都使用了 Raft 作为核心的复制协议。
京东云 EC 存储系统使用 Raft 来做 EC 组内部数据的同步和恢复，由于 EC 的复制和三副本复制的不同，使用 Raft 来做 EC 复制遇到很多挑战。本次分享将会介绍使用支持 EC 的 Raft 遇到的挑战以及在京东云我们是如何使用 Raft 来实现 EC 存储系统，同时也会介绍京东云 EC 存储系统在集群规模，可靠性，小文件支持等方面的一些工作。
分享提纲：
1. 基于 Raft 的三副本系统设计，介绍 Raft 的基本概念，如何正确的使用 Raft，举例说明京东云如何使用 Raft 实现多副本存储系统；
2. 支持 EC 的 Raft 协议，介绍 Raft 协议用在 EC 组复制中的一些问题，以及在京东云中我们是如何来解决这些问题的；
3. 京东云 EC 存储系统实践，介绍京东云 EC 存储系统的一些优化，包括超大规模集群，小文件支持，多AZ EC，限流等方面的工作。
分享要点：
部分先从 Raft 协议开始，介绍基于 Raft 协议的系统正确性的需求，在此基础上介绍我们该如何正确的使用 Raft 协议，终以一个标准的 Raft 系统结束该部分；
第二部分介绍 EC 算法，在京东云 EC 系统设计的过程中，我们发现了 EC 复制组在一些点上打破了 Raft 正确性的需求，终会影响到复制组的正确性，这部分我们会详细介绍这些点以及如何去解决，并且终介绍支持 EC 的 Raft 的正确使用方式。
作为一个存储系统，我们不仅从理论上解决了复制的正确性问题，也做了很多工程化的优化；
第三部分主要介绍真实环境中 EC 存储中面临的一些问题以及我们在京东云的解决方案。

京东智联云云产品研发部架构师，负责了京东智联云下一代存储引擎的设计和研发工作，在加入京东前，先后在知名互联网公司从事存储方面的架构设计工作，主导和参与了对象存储，块存储，KV 存储等多个系统的研发工作。

Bigo 的业务是服务全球的，大多数业务系统都有跨 Region、跨 Zone 多 IDC 部署的需求。这给存储系统带来了非常严苛的挑战，存储系统不仅要支持常态的跨 Region 部署能力，而且在整个 Region 不可用或跨 Region 网络质量严重影响到业务服务质量时，存储系统还需要具备自感知、自决策的自愈能力。存储系统存储状态，其强状态的属性给系统的容错、扩展能力方面带来了很大的挑战。设计一个全球部署的分布式存储系统，设计取舍上很容易想到的是CAP Theorem，CAP理论是分布式系统中的经典论述。但我们觉得CAP是面对失败场景的取舍，不应该作为架构设计层面的取舍，不同企业、不同场景和部署模型，出现失败的几率各不相同...
提纲：
1. Spider的研发背景
1.1 业务诉求维度
1.2 数据特性维度
2. Spider的设计思考
2.1 设计理念
2.2 工程设计
2.3 特性设计
- 多一致性级别
- 多模态
- 高可用
- 易用性
3. Spider的设计剖析
3.1 物理架构
3.2 逻辑架构
3.3 Data engine
3.4 Log engine
4. 收获与感受
4.1 健壮性保障
4.2 CRDT & MRDT
4.3 GC流程

BIGO 存储中间件团队负责人，数据库及分布式系统技术专家。拥有超过15年后端技术、数据库内核、分布式系统架构设计和研发经验。先后于腾讯、唯品会、YY等大型互联网公司担任技术研发和管理工作，在大型分布式系统的设计研发和工程化实践方面有丰富经验。

随着当今存储系统越来越多，Change Data Capture（实时数据同步）正变得越来越重要，在尤其对于的关系型数据库来说，中间涉及到 DDL 的处理，源端和终端异构等等问题，而且随着如今分布式数据库的普及，CDC 不再是简单的 Binlog 订阅，如何支持海量数据的实时变化订阅成为一个新的课题，在当下，一个现代的 CDC 系统需要考虑哪些问题，有哪些难点，同时未来的方向又是如何？在这个talk中，会针对 tidb 在 cdc 方面的实践给出我们的见解。

基础软件工程师，架构师。擅长分布式系统以及数据库开发，在分布式存储领域有丰富的经验和独到的见解。狂热的开源爱好者以及开源软件作者，代表作品分布式 Redis 缓存方案 Codis，以及分布式关系型数据库 TiDB。2015 年创业，成立 PingCAP，在 PingCAP 的主要工作是从零开始设计并研发开源 NewSQL 数据库 TiDB, 目前 GitHub 上该项目累积 star 数超过 20000+，成为本领域全球的开源项目。

软件定义存储已经成为存储市场主流，从边缘业务渗透到核心业务系统，不断加快替代传统集中式存储。企业核心业务上云，AI、5G、边缘计算、物联网等新兴技术兴起，对存储基础实施性能不断提出新的需求，容量型SDS已经无法满足诸如此类应用场景的发展，尤其是带宽之外的低延迟和高IOPS的性能需求。高性能硬件的快速发展，诸如多核CPU、高带网络、高性能SSD以及各种智能芯片，为新一代性能型全闪SDS提供了发展机遇，裸金属云存储应运而生。全闪SDS基于全用户态设计（kernel bypass）、polling模型、专核调度策略、端到端NVMf协议，发挥裸金属物理性能，实现百微秒级低延迟下的千万级IOPS超高性能。新一代性能型全闪SDS，为核心业务系统中SDS替换传统存储提供了极好的驱动力，为新兴应用提供了的存储基础设施。
分享要点：
1） 当前SDS采用内核态和用户态综合方式，以及传统的iSCSI协议，无法释放SSD的高性能。从NVMe SSD驱动到RDMA通信，再到全新的NVMf存储协议，实现端到端的全用户态低延迟I/O访问；
2） 上一代SDS中的元数据管理和硬盘管理对SSD并不友好，损耗了SSD的原生性能。全闪SDS基于裸盘管理和轻量级无状态元数据模型，从物理层到逻辑层，彻底释放90%以上的NVMe SSD原生性能；
3） 当前主流SDS是面向HDD设计，操作系统调度策略和编程模型限制了SSD效率。Polling轮循模型、专用CPU核心、无锁队列、基于hugepage虚拟内存管理、协程编程模型，全闪SDS面向SSD设计，打破限制实现新一代高性能SDS；
4） NVMe SSD和SATA SSD两种全闪环境性能对比测试，用实际数据验证全闪SSD架构设计实现的低延迟和高性能存储系统。

中科院博士，TaoCloud创始人兼首席科学家，CCF存储专委会委员。分布式存储理论研究与实践者，长期从事存储领域研发工作，GlusterFS技术专家，业内知名存储专家。目前专注软件定义存储，分布式全闪存储和智能存储系统。