什么是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

创作场景

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