作为在互联网耕耘多年的一线互联网厂商，携程在数据库实例规模和数据规模都是行业标杆，那么在引入分布式数据库时有哪些考量和在业务实践后效果如何？带着这些问题我们专访了数据库总监，携程DBA负责人俞榕刚老师。
携程作为在互联网耕耘多年的一线互联网厂商，本身的业务复杂性、数据量级、数据安全、严格事务 ACID 等对关系型数据库提出了比较高的要求；同时技术团队也持续保持着对关系型数据库产品发展趋势、技术演进的关注和研究热情。
众所周知，关系型数据库从大规模应用以来基本经历了三个阶段：
● 基于小型机、高端存储的单机或者主备模式关系型数据库，典型代表如 Oracle、SQLserver 等，近年来也有基于 PC Server，使用开源数据库内核的解决方案，如 aurora、polar DB 等；● 基于分库分表中间件的分布式模式，通过中间件代理众多底层单机关系型数据库，典型代表如 TDDL、DRDS、TDSQL 等；● 云原生分布式数据库，通过原生分布式，解决多副本一致性，数据分区等复杂的分布式问题的解决方案；如 Google Spanner、TiDB、OceanBase 等。作为二十年来一直在互联网一线发展的企业，在发展早期和众多公司一样，通过使用高端硬件(小型机，共享存储等)搭配 SQL Server 的解决方案，快速支撑了我们的业务发展。但伴随着业务的发展和业务类型的增加，不同业务都对数据库提出了不同的要求，不可避免出现了数据库资源的争抢现象；同时不断沉积的海量数据使得我们的数据库成本越来越高。在国内数字化转型趋势和以上因素的推动下，携程在不同业务上逐步引入了 MySQL 搭配 PC Server 的解决方案，经过多年的努力完成了对 SQL Server 的替换。但是 MySQL 本身也有很多缺点，即需要在内核能力之外寻找方案解决，总结有如下几点：1. MySQL 的 online DDL 带来的稳定性风险2. 基于 binlog 复制的多节点数据一致性问题4. 主备节点切换，机房搬迁等运维操作对业务的影响。对于问题1，业内目前需要依赖外部工具使用复制，重命名等方式去解决，同时带来的延时（对于大表以周为单位），空间膨胀(至少120%变更表存储空间)等问题。对于问题2，业内几乎无解，包括使用 MGR、binlog 复制方式也是经过验证的隐患；所以我们所有的线上数据库节点都是 RAID10 方式使用磁盘。但是无法解决机房级别的数据一致性问题。对于问题3，即使使用分区表也无法解决只能使用单机的计算和存储资源等限制；同时因为分库分表方案众所周知的问题，我们一直没有大范围铺开的分库分表方案。对于问题4，我们开发统一运维平台，在搬迁和切换的过程能够做到各种 check 后，自动放行；但是因为 MySQL 数据复制原生缺陷我们无法真正做到业务无感，而且每次变更也还是会提心吊胆。对于不同业务我们提供了标准的 MySQL 配置，但是不同业务的模式对资源的使用模式都不尽相同，包括但不限于重计算轻存储，重存储轻计算等，造成我们线上资源的使用率整体上偏低，却不能简单提升。综合以上问题，携程一直在跟进技术演进和产品趋势，恰逢国产分布式数据库崛起，OceanBase 惊艳地进入我们团队的视线。在和 OceanBase 技术团队交流和我们使用和测试后，我们认为 OceanBase 有以下优势。● 久经磨练，毕竟一款可以支撑蚂蚁集团的业务体量，经历十余年双十一考验的产品本身就拥有强大的背书；● TPCC 和 TPCH 成绩的惊艳，曾几何时在这些榜单都是耳熟能详的国际产品，但是 OceanBase 的多次测试并取得优异的成绩，更增强了我们的信心；● 经过深思熟虑的产品实现，包括多租户，类 LSM Tree 存储引擎，高效编码和压缩，HATP 能力，真正可用的多机房部署能力和案例；● 成熟的周边配套产品，如统一管控平台，数据迁移平台等；● 强大的技术团队，方案设计能力和高效稳定的服务能力等；以上优势让携程和 OceanBase 开启了合作共赢之路。
通过 OceanBase 的原生分布式能力，比较方便地解决了 MySQL 的隐患并带来了不少额外的好处。在线 DDL 是困扰没有运维过 MySQL 的技术人员的噩梦之一，当年携程 IM 业务群组消息表需要加一个状态字段，从稳定性考虑不得不新建一个表用于扩充这个字段，从而引入了不必要的 join 查询，往事历历在目，却因为 OceanBase 的引入得到改观；因为 OceanBase 的存储引擎使用了类 LSM Tree 设计，表的 scheme 也支持多个版本，所以在 DDL 已经不是问题，秒级即可完成并且不会锁表，可以放心的做此类操作。对于增减索引这类操作，其实也不用担心，简单来说， OceanBase 的存储机制可以理解为一个表在内存中和磁盘中都有一部分，在增减数据的时候，对于内存中的数据是实时生效，这部分的数据量不是很大，可以很快地完成并返回可使用，对于磁盘的部分数据，会有后台任务进行处理，因为大部分的业务是对近实时的数据进行操作，后台任务并不会对业务造成影响。OceanBase 单表数据量可以有多大，其实这个问题还没有准确的答案，因为携程还没有触达这个上限。以携程 IM 业务为例，我们群组消息表保存两个月数据占用存储空间800G 左右，基本触达当前配置下的 MySQL 单表上线；同样的数据迁移到 OceanBase 后数据量在200G 左右。为什么如此神奇，答案就在于 OceanBase 高效的编码和压缩机制，在数据被写入磁盘之前，OceanBase 可以针对数据列使用字典等方式进行编码，编码后每个字段占用的数据量会大大降低，结合不激进的压缩算法就可以取得良好的空间友好性。实际测试下来不同业务的压缩率在1/3到1/10之间；即使 OceanBase 使用三副本也可以保证存储空间不增长，加之携程在 MySQL 上其实也使用一主两备或者 MGR，而且磁盘使用 raid10方式，OceanBase 即使在低压缩比情况下也可以节约近5/6的存储空间。而且因为在内存中保存了编码字段，实际上在业务处理过程中，数据不需要解编码，可以说通过高效的压缩编码，OceanBase 取得了成本与性能的双赢。更进一步，OceanBase 提供了原生的分区表解决方案，可以通过丰富的分区方式对数据进行组织。通过合理的编排数据分区的主分区(写操作一定发生在主分区，读操作可以根据业务进行选择)，还可以更进一步地利用起多个副本所分布在的机器资源提高资源利用率，在不增加资源配置的情况下，极大提高写入性能的同时保证读操作的效率。作为云原生分布式数据库，OceanBase 和大多数产品一样使用多副本解决了数据安全问题，那么这些副本之间的数据一致性怎么保证？这里 MySQL 面临的大难题在 OceanBase 这里却成为了不需要担心的问题。OceanBase 使用优化的 paxos 协议结合物理日志复制强保证多数派的数据一致性，也就是三副本情况下强保证至少两个副本数据一致性，使用 OceanBase 保证了 RPO=0，实际测试下来RTO＜30s，满足携程金融业务的数据一致性的要求。额外的，其实我们比较认同“世界上只有一个多副本一致性协议就是 paxos，其他协议均是变种”的说法。通过我们的技术调研，paxos 比较 raft 等变种协议上来说：● 在故障恢复时选主速度更快，反应到数据库上时，就是节点故障的业务恢复时间更短● paxos 允许日志空洞，这可以让携程更方便的参与到主选举的过程中，更加合理的为业务编码资源的使用使用了 OcenaBase 后其实已经不太关心主备问题，因为 OcenaBase 的 share nothing 的架构，每个副本之间都是对等节点，而且在任何时候 OceanBase 能够保证多数派副本一致性，传统意义上的主备切换其实就是对副本打个标志而已，这就从根本上保证了主备切换变成了一个安全的操作。而且 OceanBase 还可以根据配置顺序自动判断当前系统状态，如果遇到机器宕机等情况，可以自动发现和切换到具备完整数据的其他副本上，保证服务的连续可用。更进一步，OceanBase 在访问层提供 Obproxy 组件自动路由数据库访问，结合我们原本已经具备的 DAL 组件(应用数据源访问控制层)，可以十分方便稳定地提供流量切换能力，真正做到对业务的无打扰或者少打扰。通过以上 OceanBase 原生的能力，携程几乎从根本上解决了 MySQL 的隐患，还获得了额外的收获。因为不同的业务模式对数据库的使用方式不同，业务的高峰也不尽相同；在原有的基于 MySQL 实例的部署模式下，每个业务都需要按照业务要求的高配置去匹配资源，实际运行下来，真正的平均资源利用率都不是很高，但是因为 MySQL 数据复制和切换效率和稳定性限制，无法方便的进行扩缩容，所以没有很好的办法提高资源利用率。携程通过配置一个较大的资源池给到 OceanBase，使用 OceanBase 提供的多租户资源隔离能力，将原来多个业务使用的 MySQL 实例迁移到 OceanBase 的租户中，从而实现一个集群多个数据库实例的混合部署模式。● 通过对租户配置不同的资源隔离，保证每个租户拥有合适的资源配置；● 根据业务高峰的不同时性，使用纵向的租户资源扩缩容方式，实现秒级的数据库实例资源扩缩容，在整体集群资源使用不变的前提下，稳定的实现了多个业务的高峰承载能力。● 如果有个别业务增长速度很快，还可以使用扩展数据库实例使用的资源节点个数方式，快速地进行业务的横向扩容。当然在业务横向扩容时候会发生数据拷贝，OceanBase 还贴心地提供了数据复制对带宽资源使用量的配置参数，保证数据复制或者迁移期间的服务稳定性，经过实测数据复制可以有效使用到服务器带宽80%左右。● 更近一步可以通过增减节点的方式，方便地控制数据库集群整体的资源使用量；扩缩容操作都是在线操作且不要求扩缩容操作一定是对等扩缩容资源，这就保证了携程对资源使用的灵活性。OceanBase 目前提供的 HTAP 能力为携程的业务打开了新的可能性，在同一套数据库集群中，可以一边进行在线业务的 TP 操作，一边提供业务 Ad Hoc 的查询能力，因为 AP 查询就在数据所在的原地，数据都是新鲜的，对业务的服务能力要比经过 ETL 的数据时效性更强，同时因为没有增加数据副本使得存储成本也得到了有效控制，相当于买一送一的大份量满足。在 TP/AP 业务混合使用的场景下，OceanBase 也想在前边提供不同业务的有效资源隔离和限制能力，不会因为 AP 的引入导致与 TP 业务发生资源争抢，终导致业务服务质量受损。
携程的数据库规模整体来说还是比较大的，所以面向规模化运营执行了详细的运维规则、流程，配合开发的一系列平台形成了携程的数据库运维体系。恰巧 OceanBase 从支付宝起家开始，面向规模化运营的设计理念和携程很契合；OceanBase 提供的统一运维监控平台 OCP 可以将多套 OceanBase 集群统一纳管并提供了开发的 API。通过针对开发、测试，生产部署了不同的 OCP 很方便地管理各个环境的 OceanBase 集群，并通过 API 快速便捷地将这些平台和集群纳入到了原有的运维体系中。对于任何一次数据库的迁移我们都需要慎之又慎，必须保证数据的强一致性，因为数据是生命线。引入 OceanBase 也不例外，幸运的是 OceanBase 提供了好用稳定的数据迁移平台 OMS。通过使用 OMS 可以很容易并且是有保证的在数据迁移过程中做到以下能力：1. 全量迁移，可以将 MySQL 中的 scheme，数据前量迁移到 OceanBase 的 MySQL 模式的租户中，并且在迁移完成后会进行全量的数据校验，针对每一条差异都会给出提示和修改 SQL。同时 OMS 迁移过程中会充分发挥 OceanBase 数据写入的并发能力并根据 OceanBase 的内存状态进行自动流控，保证了迁移过程的稳定性。2. 增量迁移，在全量迁移发起前，OMS 就会将 MySQL 的 binlog 拉取到本地，并在全量迁移，全量校验完成后将这些日志进行重放，保证了全量迁移过程中的增量数据不丢失，与此同时还会进行增量数据校验保证增量迁移的数据一致性。3. 反向迁移，在保证增量迁移完成，数据一致的前提下，当业务将读写切换到使用 OceanBase 后，OMS 还可以将 OceanBase 中的增量数据反向迁移到 MySQL 中，保证在数据并行期间的可迁回，不得不说这是一个贴心的设计。4. 数据同步，OMS 提供了将 OceanBase 中的数据同步到 kafka 等消息队列中能力，为后续的大数据分析，机器学习提供数据。更可以作为一种逻辑备份手段提供一定的数据安全性保证。「通过 OceanBase 的使用，携程获得哪些收益？」
通过 OceanBase 的引入和业务实践，解决了长期以来使用 MySQL 困扰携程的 online DDL、数据一致性、大表性能、主备切换等问题。在提供更加稳定、高效的服务能力的同时，降低了数据库系统整体的拥有成本，并且提高了资源利用率。同时 OceanBase 本身是个开放的系统架构，无论是 Observer(数据库内核)，OCP(集群管控平台)，OMS(集群迁移工具) 还是 OB Agent(管理节点)，Obproxy(轻量级数据路由代理) 都提供方便的接口或者标准 SQL 接口，我们可以将 OceanBase 的监控和告警体系接入到我们现有的监控体系中；通过管控使用 API 的方式接入，快速而方便的将 OceanBase 的资源、集群、租户、数据库等多个层级等管控能力介入到当前的管控平台中，使携程可以统一的管理所有的数据库产品，这些开放架构带来的便利性很好的保护了技术投资，也让技术同学以更加熟悉和顺手的方式使用。大家都知道在软件的世界里没有银弹，使用 OceanBase 也不是一蹴而就的，首先需要理解 OceanBase 的设计理念和架构设计，每个功能特性也需要对其优劣势了然于心，才能够大程度的扬长避短，这对技术同学提出更高的要求；同时，OceanBase 还没有做到完全的数据库自治，还需要很大程度的人工参与，主要的集中在表结构数据、索引设计和查询优化上。不过这对技术同学也是好事，在理解数据库技术的基础上还需要分布式系统的知识储备，推动技术同学更加贴近业务，理解业务模式之后才能更好地进行数据库设计和优化。这些都在一定意义上推动了技术同学的知识广度和深度。“Talk is cheap，show me code”，意思是在软件的世界里如果怕手脏，那么可能终究不会得到真正的理解；即使对 OceanBase 的特性和携程自身业务模式都有了很好的掌控，但这些都是先验的经验，如何才能真正的做到完全了然于心，离不开真实的后验结论，毕竟不能使用线上业务直接进行验证，针对于此，携程和 OceanBase 的技术同学共建了以下项目：1. 业务 SQL 重放系统，基于携程业务和数据库的 trace 系统，已将全量的业务 SQL 重放到 OceanBase 进行业务适应性验证；并通过流量复制，扩展重放倍数等手段进行业务压力验证，保证 OceanBase 能够真正满足业务而又不影响业务。2. SQL trace 系统，携程的业务 trace 在 SQL 层的 trace 只有一条 trace 记录，但是数据库的具体执行层面并没有明确的分层 trace，加之 OceanBase 分布式数据库和数据路由的特性，得到完整 SQL trace 找到真正的性能瓶颈并不容易，通过双方共建实现 SQL trace 系统我们可以将每条 SQL 的执行过程可视化，进而找到真正的瓶颈点为后续优化提供数据支撑。3. 统一日志分析系统，对于任何一个分布式系统，日志的统一分析都是需要的，OceanBase 这种分布式数据库的日志分析，对于保证服务稳定性是很重要的，通过识别和串联关键日志信息能够做到及早发现问题和预警，同时通过日志联动分析也能更好地理解分布式系统的运行过程。通过以上的系统共建，携程更加明确 OceanBase 系统对于业务的适用性，也更加清晰的了解分布式系统的运行过程，无论对技术同学的能力增长，还是对业务 SLA 的保证都有明显的帮助。同时也清晰的认知：携程可以在 OceanBase 引入和实践中做的更多，也需要做的更多，在这里还有个 Tips，就是多和 OceanBase 的架构师交流和合作，把他们对于 OceanBase 的理解和长期的实践更清晰的带给携程，一起合作可以少走很多弯路，避免故障。
目前，携程团队已经全员通过 OBCA，正在向全员通过 OBCP 进发，在这个过程里大家对分布式、云原生和数据库的理解能力越来越强；相信通过不断地学习、实践、共创，团队中的 OBCE 也会越来越多。也希望携程和 OceanBase 共建的项目尽快尽稳的在携程落地，更好更快地识别业务适应性和调优能力，可以更加踏实和更有信心地进行业务迁移。同时也希望能够有越来越多的技术人员深入掌握 OceanBase，使 OceanBase 的生态越来越丰富。独行快，众行远。希望能够有越来越多的实际案例分享，在相互借鉴和学习中使用国产云原生数据库并为我们的业务创造更高价值，也让我们拥有更多的能力，具备更高的价值。OceanBase 架构师韩冰 (花名：真难) ：
作为有二十多年技术积淀的头部互联网企业，携程 DBA 团队具备深厚的技术底蕴，对于数据库、分布式系统都有很深刻的造诣；在合作的过程中携程的技术同学很快的掌握了 OceanBase 的使用姿势，结合携程早已构建并持续发展的数据库运维管控体系和平台工具，快速的将 OceanBase 提供的企业级服务能力进行了整合和融合，很快就将 OceanBase 融合到研发、测试和生产各个环境中。
在和携程同学的合作学习中也深入到业务体系内，对业务特点有所掌握，大家一起根据业务特性设计了数据库的适应使用姿势和针对性的设置，为业务的平滑迁移和数据库的效能提升提供了快速支持。在这个过程里深刻的感觉作为原厂的架构师一定要和我们的用户紧密合作和相互学习，只有这样才能各自发挥优势，尽快的掌握业务特性和用户运维体系，同时也能更好的把 OceanBase 的设计理念、功能特性、使用姿势更好的带到合作的环境里，更快、更好、更高效地获得业务价值。
来源 https://mp.weixin.qq.com/s/L7jEe89V07B60C5p0kiBCQ
