行业： 电子商务

作者：北京市TIDB用户集团领导Meituan高级DBA的萧黄

Transcreator：冉乎昂;编辑：汤姆德湾

这篇文章是基于在TiDB用户组事件由小黄给出的演讲。

梅园在线对离线（O2O）的本地生活服务平台领先的，通过电子商务的服务和产品的综合阵列连接240名多万消费者，五百万人当地商人的世界。为了支持我们的高并发的在线服务，我们需要一个分布式数据库，能够处理大量数据的。

随着越来越多的分布式数据库进入市场，为我们的应用程序选择合适的数据库并不容易。经过深思熟虑的考虑，我们选择了Tidb.，分布式，向外扩展的MySQL数据库的替代。

在这篇文章中，我将分享我们在数据库选择中的考虑因素，并介绍我们如何在Meituan使用TIDB来解决我们的痛点。

选择一个数据库时需考虑什么

我们的业务面临的最大挑战之一是在线服务的极高并发。为了满足这一要求，我们专注于四个主要方面：稳定，绩效，成本和安全性。

稳定

用户可能会接受在线服务略微慢，但它们永远不会容忍频繁停机时间。因此，稳定性是我们的第一优先事项。在这方面，数据库应该：

• 能够支持具有高可用性的多有源体系
• 提供易于使用的监控和预警服务
• 优雅地执行滚动升级与应用没有影响
• 数据迁移和数据验证中有很少的问题
• 有效的弹性缩放

表现

我们希望尽可能地提高用户体验。只要系统稳定，系统越快，用户体验越好。因此，数据库必须高效和支持：

• 低延迟。
• 悲观的交易。如果我们将从MySQL迁移到新数据库，我们希望保留交易使用情况。
• 每秒高疑问（QPS）。如果我们今晚有特殊促销，可以让我们的流量重叠，数据库可以处理这种浪涌吗？数据库是否会失败，它是否完全下降或激活性能保护机制？
• 大规模数据处理。如果数据库不支持此操作，我们必须提前与应用程序团队进行通信以改变系统设计，并计划是否手动拆分数据并确定要创建的碎片数量。

成本

稳定性和性能后，接下来要考虑的是成本。

首先，申请费用。数据库应轻松连接到应用程序，因此我们可以最大限度地减少应用程序团队的负担。理想情况下，这个过程应该很少沟通或培训。

二，CPU，内存和磁盘的成本。我们曾经研究过一个规模的数据库，需要机器拥有384 GB的内存。一种高配置机器，可以指数增加我们的硬件成本。

第三，网络带宽。连接远程数据中心的某些网络根据带宽充电。

安全

为防止数据漏洞和数据丢失，数据库应具有以下三个功能：

• 数据审计。我们想知道谁访问数据的特定部分，以及他们如何在其上运行。
• 数据恢复。无论什么异常情况发生，我们应该能够从备份中恢复数据。
• 数据库权限。数据库权限管理应进行细粒度。例如，DBA或应用程序开发人员不应访问用户ID，电话号码和密码。在这种情况下，我们需要授予表级，甚至是现场级别的权限。

因此，我们希望具有低成本的稳定，高效和安全的数据库。我们也希望它是一个开源数据库，以便在出现问题时可以获得社区支持，并且可能为社区提供贡献。

市场，包括亚马逊极光，扳手，和CockroachDB上比较分布式数据库后，我们选择Tidb.，一个开源的，MySQL的兼容数据库，提供横向扩展和兼容ACID事务。

我们如何在Meituan使用TIDB

目前，Meituan有超过1700 TiDB节点和几百集群。最大的集群有40多个节点，最大的桌子上储存超过1000亿的记录。每天查询数量超过100亿，峰值QP在超过100k的单个集群中。

我们主要使用TIDB，主要是三种场景：水平缩放，财务级数据一致性和数据集线器。

水平缩放

我们选择分布式数据库，因为它们可以向外扩展，并在轻松，无需人工分片。我们的企业经常遇到突然的大起大落。由于流量激增，如果我们不创造更多的碎片，等待时间将上升。当MySQL仍然是我们的主要数据库，数据库管理员必须与应用团队工作手动分片数据库，这是费时和麻烦。之后，流量下降，合并使用数据转换服务（DTS）和验证数据也令人畏惧的任务碎片。

的分片问题的主要原因是计算和存储不分开。为了解决这个问题，我们需要一个分开存储层中的计算层，所以我们可以以不同的量可以根据需要扩展的存储容量和计算资源的数据库。这就是TiDB用武之地。

TIDB具有多层架构。它有三个主要组成部分：Tidb.用于计算，放置司机（PD），用于存储元数据，并提供时间戳，并Tikv.对于分布式存储。在此架构中，存储和计算是分开的，使得每个层可独立地缩放处理波动的业务，而不会影响其他组件。

金融服务

金融服务有不同的，如果不是更严格，数据库系统的要求。在Meituan，数据库必须支持具有较强的一致性交易。

让我们先来看看我们在MySQL中遇到了一个唠叨的问题。MySQL的5.7工具无损半同步复制。在此实现中，MySQL首先将事务写入二进制日志，然后将其发送到副本。副本返回确认（ACK）后，源数据库完成存储引擎（InnoDB）中的事务。换句话说，在应用程序知道完成之前，已将二进制日志发送到副本。如果此时源数据库崩溃，事务在副本中提交，则会发生风险。

此外，无损的半同步复制不会解决数据不一致。即使我们将半同步超时设置为无限值，数据也不会很大一致。例如，如果网络在源数据库和副本之间衰减，则不会副本将能够接收ACK。

要解决此问题，但后来介绍了MySQLMySQL组复制（MGR），但其可扩展性很差。一个团体可以拥有大多数九个成员。此外，MGR对网络抖动敏感。几秒钟的网络抖动可能导致群集更改主要。此外，MGR多原色模式有很多错误，MySQL社区主要使用单程模式以避免交易冲突。

MySQL的半同步不能解决一致性问题，但TiDB的Multi-筏协议一样。在存储层中，数据被划分成区域（数据的96 MB范围），每一个具有多个副本，以弥补一RAFT基团。每个筏组都有一个领导者的过程读取和写入请求。当一个领导者崩溃，该组中的其他副本选出一个新的领导人。即使一个节点崩溃，筏集团不会丢失任何数据。

接下来，我将介绍我们如何在Meituan在不同的金融方案中使用分布式事务。

跨数据库事务

当我们执行跨数据库的数据更新，我们需要跨数据库事务，以保证数据的一致性。就拿我们送外卖为了服务为例。因为客户数据和餐厅数据存储在不同的数据库，当客户下订单，我们需要更新这两个数据库。TiDB的跨数据库事务是在这种情况下有帮助。

跨碎片交易

在货币转移服务中，发件人和接收方的数据可能位于不同的碎片上。当发件人将100美元转移到接收器时，如果交易成功为一个碎片但是另一个碎片但另一件碎片失败，则从一个帐户中扣除金钱，但不会归功于另一个帐户。因此，我们需要原子交易来保证数据一致性。

SOA.

另一个使用方案是面向服务的架构（SOA）。在微服务体系结构中，我们需要分布式事务来保持跨不同服务的数据一致。

如果我们没有分布式事务，则保持跨不同服务的数据保持复杂。如果没有分布式事务，则可能需要将单个操作写入不同的模块，从而产生多个写入。在食品交付中，当客户端集群下降但餐厅侧集群存活时，验证服务检测到餐馆数据库中只存在于客户数据库中的订单。接下来，可以将订单数据添加到客户数据库中。但是这样的验证和添加逻辑为应用程序增加了复杂性。

此外，对于帐户服务，分布式事务是必不可少的，因为：

• 账户余额不能为负数。
• 在电源或网络中断的情况下，难以维持数据一致性。
• 数据损坏可能是灾难性的。当多个群集损坏时，恢复数据很难。

值得庆幸的是，TIDB解决了这些困难与其分布式交易模型。

解决方法：渗滤器中的分布式事务模型

过滤器是由谷歌专为增量处理大型数据集的系统。通过渗滤器的启发，TIDB交易模式是一个优化的两阶段提交协议，它支持悲观交易。利用TIDB的分布式交易模型，我们的研发工程师释放了分布和验证的复杂逻辑，并可以关注自己的发展。

如果您计划使用TIDB的交易模型，我们有两个普通提示：

• 整合小交易。分布式事务需要大量的网络通信，以及许多小的交易可能导致高网络延迟，从而影响性能。
• 分开大交易。大型交易通常需要很长时间并更新多个密钥。因为其他读取请求需要等待大型事务来提交，所以读取延迟可能会上升。

数据中心

我们还将TIDB用于数据集线器。对于大规模数据，数据使用逐渐变为多样化。现在需要通过OLAP数据库或数据仓库处理的一些数据，现在需要存储在TIDB中，并且实时获取结果。

在酒店预订应用程序中，我们需要获取大量数据来计算，如果酒店房间定价具有竞争力。结果必须实时给出，但计算不能影响在线服务。但是，如果数据存储在一个数据库中，则分析引擎连续从数据库中读取大量数据，这可能导致OLTP事务缓慢响应。

要解决这个问题，我们使用tidb binlog.将数据复制到另一个TIDB集群。由于TIDB的底部存储引擎RockSDB，使用日志结构的合并树（LSM-树）结构高效的写入操作，我们可以将数据快速同步到TIDB副本。在此副本中，我们可以执行大量计算和频繁查询，生成报告，甚至构建搜索引擎。

我们有许多遍布不同系统的相关数据。如果我们将这些数据提取并将它们汇集在一起​​中，我们可以将其应用于不同的服务，例如操作报告和数据订阅。

其他方案

我们也可以考虑TiDB以下情况：

• 单独的热和冷数据。随着公司的增长，累积的在线历史数据可以倾倒到TIDB集群中以降低成本。
• 存储日志和监控数据。正如TIDB的存储层使用LSM树数据结构，它为写入操作有效，它可以无限地缩放以保持用于分析目的的所有数据。
• 在线数据定义语言（DDL）模式更改。MySQL对更改表格架构有许多限制。我们曾经使用像Pt-OSC或GH-OST这样的工具来执行模式更改，但更改可能会降低在线性能或花费太长。TIDB可以在几秒钟内执行在线DDL操作，这为我们解决了痛苦。
• 从HBase / Elasticsearch（ES）迁移。我们的一些服务使用HBase或ES，但这些数据库令人沮丧，因此我们将服务迁移到TIDB。
• HTAP是不断增长的需求。随着5G和物联网的崛起，数据量呈指数增长。我们的快节奏业务可能拥有OLTP和OLAP要求，这使得HTAP数据库的需要。通过HTAP，我们可以快速生成大数据分析，降低运营和营销成本。

概括

在Meituan，TIDB帮助我们构建了更好的应用程序并节省成本。到目前为止，我们只集成了TIDB只是我们系统的一小部分，但我们期待着探索更多的场景，以利用其全部潜力。