张承圆:京东分布式数据库如何应对大型推广活动

本篇文章4860字，读完约12分钟

张承圆:京东分布式数据库如何应对大型推广活动 12月20日至22日，第十一届中国国际数据中心行业年会在北京国家会议中心举行。本次会议由中国信息与通信研究院、云计算发展与政策论坛和数据中心联盟主办。由中国国际数据中心行业年会组委会主办，中国国际数据中心圈主办，得到众多媒体的大力支持。 中国国际数据中心圈12月26日报道，第11届中国国际数据中心行业年会(IDCC2016)于12月20日至22日在北京国家会议中心隆重举行。在中国信息与通信研究院、发展与政策论坛和联盟的指导下，本次会议由中国国际数据中心行业年会组委会主办，中国国际数据中心圈主办，得到了众多媒体的大力支持。

作为中国云计算和数据中心领域最大、最具影响力的标志性事件，IDC中国行业年会已经成功举办了10次。本次会议的规格和规模都是“上一层楼”，吸引了全部现场人员，其影响力涵盖了数据中心、互联网、云计算等所有领域。

会上，JD.com资深建筑师张承圆出席了会议，并在同一天的IDC上市公司大会上发表了题为“JD.com分布式数据库如何应对大促销活动”的主旨演讲。

京东高级建筑师张承圆

以下是这次演讲的文字记录:

张承圆:大家好，今天我想和大家分享京东的分布式数据库是如何响应这次大促销的。我叫张承圆。我是京东的建筑师。我毕业于东北大学，研究方向是分布式数据库。我一直在京东做分布式数据库的相关工作。我是MariaDB原则和实施的小编辑。在JD.com，我负责分布式数据库的架构设计和大规模实现。就我个人而言，我擅长高性能服务器开发和大规模分布式系统架构设计。

我认为对于推广来说，基本系统和业务系统都是一样的，最重要的只是两个步骤，即前期的准备应该是非常充分和完善的，而在推广期间，因为前期的准备非常充分，所以有很多计划，在推广期间只有计划要遵循来处理。也就是说，在正常情况下，所有繁忙的工作都是在大促销开始前完成的，而在大促销开始后，更需要冷静地处理线上的一些情况。

让我们来讨论一下什么是分布式数据库，以及在分布式数据库中需要使用哪些场景。从名称上可以看出，分布式数据库是先分布式的，或者支持SQL，并且存储在多个节点上，以分担原有独立数据库的压力。数据库在计算机领域的发展很早，也是一个相对成熟的分支。70年代，关系理论开始提出背后有许多SQL产品，如我的SQL和SQL SERVER。这些数据库被广泛使用。随着整个互联网的发展和数据量的增加，在许多行业中会出现一些情况。例如，独立数据库可能无法处理业务量，因为当数据量很大时，独立数据库的压力会很大，因此查询会减少。在互联网领域，还有另一个原因。甲骨文和其他互联网公司正在考虑如何省钱。他们将删除这些数据库，并使用免费的MySQL来携带它们。在这样做的时候，他们还需要相应的分布式数据库来解决这些存储问题。

让我们直接来谈谈京东的解决方案。我们有一套专门用于分布式数据库的中间件，在我们身后的存储中会有很多MySQL，因为中间件是金融MySQL，用户在使用它时并不知道。他像MySQL一样使用这个系统。他的SQL写得正常，数据也正常。实现将制定路由规则，我们将把数据放到后面相应的节点上。如果是查询，他的SQL是正常的。我们将解析SQL。如果我们只查询一些记录，我们将把SQL解析成一个执行计划。

JManager管理路由信息。如果每个路由信息单独维护，成本将非常高，因此我们的路由信息是集中管理的，所有路由信息都可以在这里收集。还有JTrasnfer系统。也许我的系统不确定我的数据量。我想在后期把它换成四套或八套。我们将把数据的原始部分迁移到新的集群。这样，整个集群的数据将变得更大，这相当于整个集群的大小。可以支持的数据量，包括支持压力和支持能力，将得到改善。还有JMonitor，因为当一个系统实际在线使用时，除了核心的基本功能满意度和性能满意度之外，监控是非常重要的，尤其是当您支持的系统是一个非常关键的系统时。如果找不到任何异常情况，可能会造成很大的问题。

从去年到今年，我们的系统已经删除了所有的甲骨文，现在只剩下一些业务。删除Oracle有一些工作需要调整。我们让用户感觉像普通的MySQL，但是它仍然有一些使用规则的限制，或者一些规则，我们需要它的SQL，因为会有很多块被插入，分布式缓存也是如此。您必须确保您的查询尽可能落在单个库中。我们将要求尽可能重写SQL，并将其放在单个库中。

对于订单的标识，该组SQL必须属于某个库，因为它的标识是唯一的。像这样的SQL将尽可能多地重写，以避免跨库事务，这更有趣。如果您跨库，支持基于MySQL的分布式事务会更加困难。如果你感兴趣，你可以搜索我以前做过的分享。当业务方使用它时，他可以让事务中的SQL落在一个数据库上，但是它也有一个有趣的情况。每个SQL落在单个数据库上，但是整个事务是跨节点的，例如，一个事务中有三个SQL，第一个SQL落在单个数据库上，第二个SQL落在单个数据库上，第三个SQL落在单个数据库上，所以整个事务是跨数据库的，但是每个SQL不跨数据库。公司有运单系统，这也是一个非常重要的系统。我们已经在网上运行了两个月，并且非常稳定。我们还没有达到618，因为JD.com 618有一个很大的提升。就在6月份，在升职之前，出现了一个问题。整个系统被卡住了，许多SQL非常慢。我们调查了原因。一项交易涉及三个节点，其中两个不相关。然而，第三个节点与另一个事务冲突，另一个冲突是跨节点的。这将产生连锁反应，并覆盖很大的区域。我们找到了原因，并要求业务方改变这一点。他说我的每一条SQL语句都在一个数据库中。我不确定我的事务如何跨越节点。我们会在这里提供。如果您的SQL跨越数据库，我们必须直接记录它。如果每个SQL都不跨数据库，那么它就落在一个点上。但是，如果整个事务跨越多个节点，我们也会记录它。你可以根据我们的记录改变它，因为整个系统都在那里。您可以直接查看您的系统、您的业务以及现在可以更改的跨数据库事务。

通常情况下，去甲骨文是非常困难的，因为有很多细节，我们的系统在一段时间内通常是双系统的，同时编写甲骨文和MySQL。在这个过程中，我们将记录任何缓慢的SQL。应用程序看到的缓慢的SQL是在这个级别，但是后面的链接非常长。我们将记录慢的SQL并详细记录整个链接，以便清楚地定位问题，如网络问题或数据库问题。当缓慢的SQL出现后，当它们被插入时，其中一些会出现这种情况。它可能不会改变得很好，并且会有大量的慢速SQL。这时，系统开发人员会说，然后你告诉我先更改哪个SQL。大量慢速SQL中的一些是相同的或者可能是相同的类型。我们将对所有的SQL进行分类，告诉你哪个慢SQL出现了多少次，在多长时间内出现了多少次。他会直接选择最高频率来改变，然后慢慢改变。

有定制的路由策略以及JD.com的特色。例如，我们的子检验中心是一个不同数量的国家子检验中心。将比较上海和北京的子检查中心的数量。如果子检验中心被正常拆分，将会出现一种情况，即您可能会与大型子检验中心落在同一个仓库上。在这种情况下，仓库的压力会非常大。我们如何避免这个问题？因为我们都知道哪些分类中心的容量更大或更小，我们将在更好的数据库上建立容量更大的分类中心，并且通常将一些数据分成更小的分类中心。当小型分拣中心的数量增加时，较大的分拣中心会再次移出，这样业务系统就不需要关心这些事情，所有这些都是在分布式数据库级别完成的。

因为我刚刚看到整个链接非常长，并且与前端服务相关。在整个推广之前，整个链接是高度可用的。如果高可用性不能保证这一点，那将非常麻烦。让我们先来谈谈高可用性。高可用性意味着当您的系统停机时会发生什么？业务的应用程序实例将部署在多个副本中，在一个步骤中部署数百或数百个实例。一个系统中有两个jproxies，最多需要三个。通过域名连接，代理背后的变化对业务没有影响。例如，MySQL主机和从机连接在普通系统之间，后面有一个开关。如果您的应用程序非常重要，您将希望快速使链接有效，并连接到新的主服务器，因此业务将重新启动，这里不需要。JProxy将部署两个，每个计算机房将部署两个，并且将有跨境灾难准备，因为一些计算机房由于某些原因会有问题。当部署在同一计算机房时，应考虑不要部署在同一机架上。仍有一个机架挂起的可能性。此外，MySQL被部署在不同的机房，同一间机房将有一个副本。在这种情况下，因为MySQL经常会有主从切换，如硬件问题、网络电缆问题等，需要进行切换，所以同一机房会有一个副本，另一个副本用于另一个机房。

除了高可用性之外，还有许多其他东西。例如，我们通常在大规模推广前进行全环节压力测量。这样，我们就会发现哪一个环节最薄弱，需要扩展相应的资源。

还有一个非常完美的监控和报警，这一点非常重要，因为当你的系统，尤其是你的核心功能不稳定时，如果没有完美的报警，那就是完全失明的状态，如果有问题，我不知道是什么，而且我不能调试在线系统，所以我必须有一个非常完美的监控和报警系统，比如最基本的生存监控。例如，数据需要由慢速SQL监控，因为慢速SQL可能会有问题。在一些系统中，我们经常使用慢速SQL，然后我们会立即进行调查。事实上，一些非常简单的事情是不容易避免的，并且发生的概率相对较高。例如，它的网络数据包被重传，或者丢失。可能是网线松了，或者网卡有问题。像这样的硬件是一种标志。您不能等到它完全挂起后再进行处理。因此，除了生存监测，更详细的监测应该在此之前完成。还有连接号码监控报警。每次你慢慢查询，就会变成大量的连接。还有一种情况是，企业被错误地联系在一起。在这种情况下，连接数将非常高。我们将控制这方面的权威。还有基本的系统监控，如中央处理器/内存/网卡/磁盘/网络质量。例如，这个MySQL集合有大量的数据，进行大量的查询，然后解包大量的包，CPU会激增很多。内存，如果你有一个查询，MySQL那里有大量的数据。同时，SQL连接到中间件服务提供商。中间件有1000多个子数据库，每个都非常大。让它的数据发送到中间件将会导致非常大的问题。数据量非常大。只有一个环节在它面前消失，它的记忆就会爆发。我们会有记忆保护。在一定程度上，其余的将被压入TCP，从而保证整个内存。事实上，网络质量非常关键，问题可以及时处理。数据的分布，我的数据是否均匀，某个分区中是否有大量的数据。

如何处理在线异常？我的感觉是，足够的计划和训练。你能想到的例外肯定会发生。在分布式系统中，节点越多，出错的可能性就越大。任何节点都有可能挂起。即使您没有挂断任何节点，网络也可能会有问题。如果网络没有问题，它也会有问题。整个分布式系统意味着，如果任何节点出现问题，它需要确保系统在可控范围内。如果不能保证，你的系统在线运行时会非常糟糕。这可能不是100%的意外，但它基本上会遇到你能想到的任何异常。我们将为所有可能的异常情况制定相应的计划。在大规模推广之前会有很多计划演练，比如某个节点应该做什么，比如拔掉网线会有什么影响，以及我可以多快处理这些事情。为了实现大的提升，很少有新的问题需要暂时解决。这样，问题就经常出现。在大多数情况下，所有的异常都准备好了。如果在大促销期间出现问题，我们只能按计划运作。我们可以尽量避免思考。我们不是说不去想，而是说在大促销之前，所有的准备工作都应该准备好。大促销是机械化的反应。

然而，实际情况可能并不完美。有一些情况需要考虑。计划可能没有完全覆盖，但覆盖率仍然很高。

我想表达一下基本系统团队在大促销中的地位。我只想坐在那里，看着大促销真正发生时的监控和警报。我只想按照计划处理这些问题。基本上是这样的，只要整个团队相对成熟，整个公司的支持系统非常成熟。对于一些发展中的团队来说，他可能不会如此无忧无虑，因为有些事情很难做好充分准备。然而，这些年来，JD.com在系统、处理计划和团队方面变得更加成熟。