共计 7539 个字符，预计需要花费 19 分钟才能阅读完成。
背景：
作为在互联网耕耘多年的一线互联网厂商，携程在数据库实例规模和数据规模都是行业标杆，那么在引入分布式数据库时有哪些考量和在业务实际后成果如何？带着这些问题咱们专访了高级数据库总监，携程 DBA 负责人俞榕刚老师。
携程作为在互联网耕耘多年的一线互联网厂商，自身的业务复杂性、数据量级、数据安全、严格事务 ACID 等对关系型数据库提出了比拟高的要求；同时技术团队也持续保持着对关系型数据库产品发展趋势、技术演进的关注和钻研激情。
为什么关注到 OceanBase？
家喻户晓，关系型数据库从大规模利用以来根本经验了三个阶段：
● 基于小型机、高端存储的单机或者主备模式关系型数据库，典型代表如 Oracle、SQLserver 等，近年来也有基于 PC Server，应用开源数据库内核的解决方案，如 aurora、polar DB 等；
● 基于分库分表中间件的分布式模式，通过中间件代理泛滥底层单机关系型数据库，典型代表如 TDDL、DRDS、TDSQL 等；
● 云原生分布式数据库，通过原生分布式，解决多正本一致性，数据分区等简单的分布式问题的解决方案；如 Google Spanner、TiDB、OceanBase 等。
作为二十年来始终在互联网一线倒退的企业，在倒退晚期和泛滥公司一样，通过应用高端硬件 (小型机，共享存储等) 搭配 SQL Server 的解决方案，疾速撑持了咱们的业务倒退。但随同着业务的倒退和业务类型的减少，不同业务都对数据库提出了不同的要求，不可避免呈现了数据库资源的争抢景象；同时一直沉积的海量数据使得咱们的数据库老本越来越高。
「MySQL 的有余」
在国内数字化转型趋势和以上因素的推动下，携程在不同业务上逐渐引入了 MySQL 搭配 PC Server 的解决方案，通过多年的努力完成了对 SQL Server 的替换。然而 MySQL 自身也有很多毛病，即须要在内核能力之外寻找计划解决，总结有如下几点：
- MySQL 的 online DDL 带来的稳定性危险
- 基于 binlog 复制的多节点数据一致性问题
- 单表数据量承载能力问题
- 主备节点切换，机房搬迁等运维操作对业务的影响。
对于问题 1，业内目前须要依赖内部工具应用复制，重命名等形式去解决，同时带来的延时（对于大表以周为单位），空间收缩 (至多 120% 变更表存储空间) 等问题。
对于问题 2，业内简直无解，包含应用 MGR、binlog 复制形式也是通过验证的隐患；所以咱们所有的线上数据库节点都是 RAID10 形式应用磁盘。然而无奈解决机房级别的数据一致性问题。
对于问题 3，即便应用分区表也无奈解决只能应用单机的计算和存储资源等限度；同时因为分库分表计划家喻户晓的问题，咱们始终没有大范畴铺开的分库分表计划。
对于问题 4，咱们开发对立运维平台，在搬迁和切换的过程可能做到各种 check 后，主动放行；然而因为 MySQL 数据复制原生缺点咱们无奈真正做到业务无感，而且每次变更也还是会胆战心惊。
对于不同业务咱们提供了规范的 MySQL 配置，然而不同业务的模式对资源的应用模式都不尽相同，包含但不限于重计算轻存储，重存储轻计算等，造成咱们线上资源的使用率整体上偏低，却不能简略晋升。
「OceanBase 的劣势」
综合以上问题，携程始终在跟进技术演进和产品趋势，恰逢国产分布式数据库崛起，OceanBase 惊艳地进入咱们团队的眼帘。在和 OceanBase 技术团队交换和咱们应用和测试后，咱们认为 OceanBase 有以下劣势。
● 久经磨难，毕竟一款能够撑持蚂蚁团体的业务体量，经验十余年双十一考验的产品自身就领有弱小的背书；
● TPCC 和 TPCH 问题的惊艳，曾几何时在这些榜单都是耳熟能详的国内产品，然而 OceanBase 的屡次测试并获得优异的问题，更加强了咱们的信念；
● 通过三思而行的产品实现，包含多租户，类 LSM Tree 存储引擎，高效编码和压缩，HATP 能力，真正可用的多机房部署能力和案例；
● 成熟的周边配套产品，如对立管控平台，数据迁徙平台等；
● 弱小的技术团队，方案设计能力和高效稳固的服务能力等；
● 领有相较于同类产品比拟显著的性能劣势。
以上劣势让携程和 OceanBase 开启了单干共赢之路。
携程如何应用 OceanBase 解决问题？
通过 OceanBase 的原生分布式能力，比拟不便地解决了 MySQL 的隐患并带来了不少额定的益处。
「如何解决在线 DDL 问题？」
在线 DDL 是困扰没有运维过 MySQL 的技术人员的噩梦之一，当年携程 IM 业务群组音讯表须要加一个状态字段，从稳定性思考不得不新建一个表用于裁减这个字段，从而引入了不必要的 join 查问，往事历历在目，却因为 OceanBase 的引入失去改观；因为 OceanBase 的存储引擎应用了类 LSM Tree 设计，表的 scheme 也反对多个版本，所以在 DDL 曾经不是问题，秒级即可实现并且不会锁表，能够释怀的做此类操作。
对于增减索引这类操作，其实也不必放心，简略来说，OceanBase 的存储机制能够了解为一个表在内存中和磁盘中都有一部分，在增减数据的时候，对于内存中的数据是实时失效，这部分的数据量不是很大，能够很快地实现并返回可应用，对于磁盘的局部数据，会有后台任务进行解决，因为大部分的业务是对近实时的数据进行操作，后台任务并不会对业务造成影响。
「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 容许日志空洞，这能够让携程更不便的参加到主选举的过程中，更加正当的为业务编码资源的应用
「OceanBase 主备切换怎么做，平安吗？」
应用了 OcenaBase 后其实曾经不太关怀主备问题，因为 OcenaBase 的 share nothing 的架构，每个正本之间都是对等节点，而且在任何时候 OceanBase 可能保障多数派正本一致性，传统意义上的主备切换其实就是对正本打个标记而已，这就从根本上保障了主备切换变成了一个平安的操作。而且 OceanBase 还能够依据配置程序主动判断以后零碎状态，如果遇到机器宕机等状况，能够主动发现和切换到具备残缺数据的其余正本上，保障服务的间断可用。
更进一步，OceanBase 在拜访层提供 Obproxy 组件主动路由数据库拜访，联合咱们本来曾经具备的 DAL 组件(利用数据源访问控制层)，能够非常不便稳固地提供流量切换能力，真正做到对业务的无打搅或者少打搅。
通过以上 OceanBase 原生的能力，携程简直从根本上解决了 MySQL 的隐患，还取得了额定的播种。
「资源池化，数据库实例混部」
因为不同的业务模式对数据库的应用形式不同，业务的顶峰也不尽相同；在原有的基于 MySQL 实例的部署模式下，每个业务都须要依照业务要求的最高配置去匹配资源，理论运行下来，真正的均匀资源利用率都不是很高，然而因为 MySQL 数据复制和切换效率和稳定性限度，无奈不便的进行扩缩容，所以没有很好的方法进步资源利用率。
携程通过配置一个较大的资源池给到 OceanBase，应用 OceanBase 提供的多租户资源隔离能力，将原来多个业务应用的 MySQL 实例迁徙到 OceanBase 的租户中，从而实现一个集群多个数据库实例的混合部署模式。
● 通过对租户配置不同的资源隔离，保障每个租户领有适合的资源配置；
● 依据业务顶峰的不同时性，应用纵向的租户资源扩缩容形式，实现秒级的数据库实例资源扩缩容，在整体集群资源应用不变的前提下，稳固的实现了多个业务的顶峰承载能力。
● 如果有个别业务增长速度很快，还能够应用扩大数据库实例应用的资源节点个数形式，疾速地进行业务的横向扩容。当然在业务横向扩容时候会产生数据拷贝，OceanBase 还贴心地提供了数据复制对带宽资源使用量的配置参数，保证数据复制或者迁徙期间的服务稳定性，通过实测数据复制能够无效应用到服务器带宽 80% 左右。
● 更近一步能够通过增减节点的形式，不便地管制数据库集群整体的资源使用量；扩缩容操作都是在线操作且不要求扩缩容操作肯定是对等扩缩容资源，这就保障了携程对资源应用的灵活性。
「HTAP 能力晋升业务响应速度」
OceanBase 目前提供的 HTAP 能力为携程的业务关上了新的可能性，在同一套数据库集群中，能够一边进行在线业务的 TP 操作，一边提供业务 Ad Hoc 的查问能力，因为 AP 查问就在数据所在的原地，数据都是陈腐的，对业务的服务能力要比通过 ETL 的数据时效性更强，同时因为没有减少数据正本使得存储老本也失去了无效管制，相当于买一送一的大份量满足。
在 TP/AP 业务混合应用的场景下，OceanBase 也想在前边提供不同业务的无效资源隔离和限度能力，不会因为 AP 的引入导致与 TP 业务产生资源争抢，最终导致业务服务质量受损。
怎么安稳地迁徙到 OceanBase？
「对于运维管控」
携程的数据库规模整体来说还是比拟大的，所以面向规模化经营执行了具体的运维规定、流程，配合开发的一系列平台造成了携程的数据库运维体系。凑巧 OceanBase 从支付宝起家开始，面向规模化经营的设计理念和携程很符合；OceanBase 提供的对立运维监控平台 OCP 能够将多套 OceanBase 集群对立纳管并提供了开发的 API。通过针对开发、测试，生产部署了不同的 OCP 很不便地治理各个环境的 OceanBase 集群，并通过 API 疾速便捷地将这些平台和集群纳入到了原有的运维体系中。
「对于数据迁徙」
对于任何一次数据库的迁徙咱们都须要慎之又慎，必须保证数据的强一致性，因为数据是生命线。引入 OceanBase 也不例外，侥幸的是 OceanBase 提供了好用稳固的数据迁徙平台 OMS。
通过应用 OMS 能够很容易并且是有保障的在数据迁徙过程中做到以下能力：
- 全量迁徙，能够将 MySQL 中的 scheme，数据前量迁徙到 OceanBase 的 MySQL 模式的租户中，并且在迁徙实现后会进行全量的数据校验，针对每一条差别都会给出提醒和批改 SQL。同时 OMS 迁徙过程中会充分发挥 OceanBase 数据写入的并发能力并依据 OceanBase 的内存状态进行主动流控，保障了迁徙过程的稳定性。
- 增量迁徙，在全量迁徙发动前，OMS 就会将 MySQL 的 binlog 拉取到本地，并在全量迁徙，全量校验实现后将这些日志进行重放，保障了全量迁徙过程中的增量数据不失落，与此同时还会进行增量数据校验保障增量迁徙的数据一致性。
- 反向迁徙，在保障增量迁徙实现，数据统一的前提下，当业务将读写切换到应用 OceanBase 后，OMS 还能够将 OceanBase 中的增量数据反向迁徙到 MySQL 中，保障在数据并行期间的可迁回，不得不说这是一个贴心的设计。
- 数据同步，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 的技术同学共建了以下我的项目：
- 业务 SQL 重放零碎，基于携程业务和数据库的 trace 零碎，已将全量的业务 SQL 重放到 OceanBase 进行业务适应性验证；并通过流量复制，扩大重放倍数等伎俩进行业务压力验证，保障 OceanBase 可能真正满足业务而又不影响业务。
- SQL trace 零碎，携程的业务 trace 在 SQL 层的 trace 只有一条 trace 记录，然而数据库的具体执行层面并没有明确的分层 trace，加之 OceanBase 分布式数据库和数据路由的个性，失去残缺 SQL trace 找到真正的性能瓶颈并不容易，通过单方共建实现 SQL trace 零碎咱们能够将每条 SQL 的执行过程可视化，进而找到真正的瓶颈点为后续优化提供数据撑持。
- 对立日志剖析零碎，对于任何一个分布式系统，日志的对立剖析都是须要的，OceanBase 这种分布式数据库的日志剖析，对于保障服务稳定性是很重要的，通过辨认和串联要害日志信息可能做到及早发现问题和预警，同时通过日志联动剖析也能更好地了解分布式系统的运行过程。
通过以上的零碎共建，携程更加明确 OceanBase 零碎对于业务的适用性，也更加清晰的理解分布式系统的运行过程，无论对技术同学的能力增长，还是对业务 SLA 的保障都有显著的帮忙。
同时也清晰的认知：携程能够在 OceanBase 引入和实际中做的更多，也须要做的更多，在这里还有个 Tips，就是多和 OceanBase 的架构师交换和单干，把他们对于 OceanBase 的了解和长期的实际更清晰的带给携程，一起单干能够少走很多弯路，防止故障。
对 OceanBase 有哪些期待？
目前，携程团队曾经全员通过 OBCA，正在向全员通过 OBCP 进发，在这个过程里大家对分布式、云原生和数据库的理解能力越来越强；置信通过一直地学习、实际、共创，团队中的 OBCE 也会越来越多。也心愿携程和 OceanBase 共建的我的项目尽快尽稳的在携程落地，更好更快地辨认业务适应性和调优能力，能够更加虚浮和更有信念地进行业务迁徙。同时也心愿可能有越来越多的技术人员深刻把握 OceanBase，使 OceanBase 的生态越来越丰盛。
独行快，众行远。心愿可能有越来越多的理论案例分享，在互相借鉴和学习中应用国产云原生数据库并为咱们的业务发明更高价值，也让咱们领有更多的能力，具备更高的价值。
后记（架构师感悟）
OceanBase 架构师韩冰 (花名：真难)：
作为有二十多年技术积淀的头部互联网企业，携程 DBA 团队具备深厚的技术底蕴，对于数据库、分布式系统都有很粗浅的造诣；在单干的过程中携程的技术同学很快的把握了 OceanBase 的应用姿态，联合携程早已构建并继续倒退的数据库运维管控体系和平台工具，疾速的将 OceanBase 提供的企业级服务能力进行了整合和交融，很快就将 OceanBase 交融到研发、测试和生产各个环境中。
在和携程同学的单干学习中也深刻到业务体系内，对业务特点有所把握，大家一起依据业务个性设计了数据库的适应应用姿态和针对性的设置，为业务的平滑迁徙和数据库的效力晋升提供了疾速反对。在这个过程里粗浅的感觉作为原厂的架构师肯定要和咱们的用户严密单干和互相学习，只有这样能力各自发挥优势，尽快的掌握业务个性和用户运维体系，同时也能更好的把 OceanBase 的设计理念、性能个性、应用姿态更好的带到单干的环境里，更快、更好、更高效地取得业务价值。
