详解数据库NoSQL的主备份

　　Tarantool DBMS的高性能应该很多人都听说过，包括其丰富的工具套件和某些特定功能。比如，它拥有一个非常强大的on-disk存储引擎Vinyl，并且知道怎样处理JSON文档。然而，大部分文章往往忽略了一个关键点：通常，Tarantool仅仅被视为存储器，而实际上其最大特点是能够在存储器内部写代码，从而高效处理数据。如果你想知道我和igorcoding是怎样在Tarantool内部建立一个系统的，请继续往下看。

　　如果你用过Mail.Ru电子邮件服务，你应该知道它可以从其他账号收集邮件。如果支持OAuth协议，那么在收集其他账号的邮件时，我们就不需要让用户提供第三方服务凭证了，而是用OAuth令牌来代替。此外，Mail.Ru Group有很多项目要求通过第三方服务授权，并且需要用户的OAuth令牌才能处理某些应用。因此，我们决定建立一个存储和更新令牌的服务。

　　我猜大家都知道OAuth令牌是什么样的，闭上眼睛回忆一下，OAuth结构由以下3-4个字段组成：

　　访问令牌（access_token）——允许你执行动作、获取用户数据、下载用户的好友列表等等；

　　更新令牌（refresh_token）——让你重新获取新的access_token，不限次数；

　　过期时间（expires_in）——令牌到期时间戳或任何其他预定义时间，如果你的access_token到期了，你就不能继续访问所需的资源。

　　现在我们看一下服务的简单框架。设想有一些前端可以在我们的服务上写入和读出令牌，还有一个独立的更新器，一旦令牌到期，就可以通过更新器从OAuth服务提供商获取新的访问令牌。

　　如上图所示，数据库的结构也十分简单，由两个数据库节点（主和从）组成，为了说明两个数据库节点分别位于两个数据中心，二者之间由一条垂直的虚线隔开，其中一个数据中心包含主数据库节点及其前端和更新器，另一个数据中心包含从数据库节点及其前端，以及访问主数据库节点的更新器。

　　面临的困难

　　我们面临的主要问题在于令牌的使用期（一个小时）。详细了解这个项目之后，也许有人会问“在一小时内更新1000万条记录，这真的是高负载服务吗？如果我们用一个数除一下，结果大约是3000rps”。然而，如果因为数据库维护或故障，甚至服务器故障（一切皆有可能）导致一部分记录没有得到更新，那事情将会变得比较麻烦。比如，如果我们的服务（主数据库）因为某些原因持续中断15分钟，就会导致25%的服务中断（四分之一的令牌变成无效，不能再继续使用）；如果服务中断30分钟，将会有一半的数据不能得到更新；如果中断1小时，那么所有的令牌都将失效。假设数据库瘫痪一个小时，我们重启系统，然后整个1000万条令牌都需要进行快速更新。这算不算高负载服务呢？

　　一开始一切都还进展地比较顺利，但是两年后，我们进行了逻辑扩展，增加了几个指标，并且开始执行一些辅助逻辑……。总之，Tarantool耗尽了CPU资源。尽管所有资源都是递耗资源，但这样的结果确实让我们大吃一惊。

　　幸运的是，系统管理员帮我们安装了当时库存中内存最大的CPU，解决了我们随后6个月的CPU需求。但这只是权宜之计，我们必须想出一个解决办法。当时，我们学习了一个新版的Tarantool（我们的系统是用Tarantool 1.5写的，这个版本除了在Mail.Ru Group，其他地方基本没用过）。Tarantool 1.6大力提倡主主备份，于是我们想：为什么不在连接主主备份的三个数据中心分别建立一个数据库备份呢？这听起来是个不错的计划。