云监控背后的技术：Shared-nothing Architecture

什么是 Shared-Nothing(SN)架构？

Shared-nothing 架构本来是一个比较古老的架构模式，最早出现于 1986 年的一篇 database 论文（MichaelStonebraker at the University of California, Berkeley），由于近些年 NoSQL 的大行其道，加上 Google，Amazon 等大厂在 big tabledata storage 领域的不断耕耘，SN 架构又被重新拿来定义超大规模的数据仓库，数据存储架构，并逐渐成为事实上大部分 NoSQL 数据库的架构基础。（例如：Cassandra，DynamoDB，BigTable，HBase 等）

SN 架构简介

如上图就是最简明的 Shared-nothing 图解，左图中，无论从 1,2,3,4 任意的节点访问数据，都能访问到全量的数据；而右图中，1 访问的数据只属于 1，2 访问到的只属于 2。这是因为在 SN 架构中引入了分区（partition）的概念：每一个 node 都应该具备属于自己的分区。

对于左图来说，一个非常大的数据存储集群，当有新数据写入时，必须要有分布式全局锁（distributedlock）来做全局的写控制，这样才能保证在有两个节点同时写入的时候不会出现 racecondition 或者 dead lock。而我们都知道，维护分布式锁的最大问题就是节点数目永远和锁复杂度是成正比的，因此左图中的非 SN 架构在线性扩展上是非常差的，即使扩展成功，每次的写入会给整个系统带来非常大的锁开销。

而 SN 系统在这方面就有先天优势：lockless 的数据 sharding，保证从 1 写入的数据永远只会到达 A，从 2 写入的数据永远只会达到 B 等等，永远不会出现 1 和 2 同时去 A 写的情况出现。这样 SN 架构下的数据库系统，性能是随着集群规模线性增长的，这也是为什么 Cassandra 等 NoSQL 数据库的吞吐量可以无限制增长的主要原因，下面我们来看看在云监控中的应用。

SN 在云监控系统中的应用场景

云监控是一个海量数据+海量并发的低延迟业务系统，每天 20 亿次以上的指标数据写入就已经直接反映了其对数据超高的消费与接纳能力，如果没有 SN 做基础的情况下，扩展起来将会成为灾难。因此，云监控系统中对 SN 的应用与实践反映在方方面面。

a. 基于 SN 的离线降维（聚合）服务 Blueflood

Blueflood 是一款开源的监控指标离线处理系统，云监控用 blueflood 做离线指标的聚合降维计算，在 blueflood 中，所有数据被用 Consistenthash 分成 0-127 个 shards，每个 shard 带有一定数量的指标：

由于 Blueflood 分为聚合集群，写入集群和查询集群，这样 Blueflood 在做聚合运算的时候，我们按照 shard 的数量，均匀分散在聚合节点上，比如有 4 个聚合节点，每个节点带 32 个 shards，如果每个 shard 有 10 个指标，每个 Blueflood 聚合节点就会负责 32 * 10 = 320 个指标的聚合任务。任何一个聚合节点都不会访问别的 shard 里的数据，扩容的时候只要重新将 shards 分配在新的集群上面就可以。

b.基于 SN 的站点监控轮训机制

站点监控是云监控的另一个核心模块，为用户提供网站的可用性，访问时延等指标的监控与告警。核心组件探针也是基于 SN 模型部署，每一个 Probe 节点被平均分配 N 个网站域名，Probe 只会负责相应网站的探测监控，同时加上冗余，最大限度增加整个系统的容量和可用性。

SN 在 Cassandra 上的应用

上一篇我们已经介绍了 Cassandra 的基本概念，以及它近乎变态的线性扩展能力和可靠性，那么是什么维持了它的这些特性呢？ SN 在这里面扮演了很重要的角色：

a. 如何维持高吞吐量和线性扩展能力？

Cassandra 天然的设计就是遵循了 SN 架构：每个节点拿到整个数据集的一部分子集，并且利用 ConsistentHash 将每一个 range 的数据映射到不同的节点上，因此每个节点在理论上只会保存全量数据的一部分。在扩容的时候，由于 consistenthash 算法将新的 range 填入集群，并且会在后台逐渐将以前的 range ring 做 rebalance，这样在新节点加入完成以后，所有的节点又是独立且无干扰的，又符合 SN 架构。

b. SN 下 Cassandra 如何维持一致性以及可靠性？

这个问题是诸多 bigtable 类型 NoSQL 数据库都在努力解决的问题，在上一篇文章中我们介绍了可调的一致性是 Cassandra 的亮点，所以 Cassandra 实际上在 SN 和非 SN 中寻找了一种平衡，在可调一致性的情况下，副本数达到设置的一致性便会返回写成功；而 Cassandra 又允许用户设置副本数，（通常为 3），这就表示，即使一致性级别设置为 All 的情况下，也只是集群中只有三个节点返回写正确就可以表示一次写入正确，这样既保证了数据的可靠性（三副本），又保证了分区容忍度（Networkpartition），以及在前两者保证的情况下的相对 SN 架构符合程度（并非全局的 distributedlock）。

而在其他一致性情况下，比如 LocalOne 的情况下，就是标准的 SN 实现，只要返回一个写成功便会写成功，而对副本的同步会异步在写完成后才进行。总的来说，sharednothing 降低了竞争资源的等待时间，从而提高了性能。反过来，如果一个数据库应用系统要获得良好的可扩展的性能，它从设计和优化上就要考虑 sharednothing 体系结构，Share nothingmeans few contention。

本文转载自 华为云产品与解决方案 公众号。

原文链接：https://mp.weixin.qq.com/s/KmPpxDXngWP--3Xs72BQng