# Cassandra 高可用架构设计 ## 简单单体应用架构 最简单的可以保证ACID原则的设计方式是实现一个包含所有功能的单体应用架构。因为被请求的节点中没有协调（coordinate）节点，执行所有系统规则的任务相对都比较简单。提升这种架构的可用性典型的操作就是升级硬件层，例如RAID磁盘矩阵，多网卡接口，热插拔驱动。然而，事实是即使最健壮的数据库服务也会单点故障问题。这就意味着如果服务器宕机，应用马上就变得不可用。这种架构如下图：  一种通用的扩容单体应用架构的方式是把存储层放在一个分片组件（shared component），例如存储区域网络(storage area network SAN)， 或者 NAS(Network Attached Storage:网络附属存储)。这些设备通常非常强大，具有海量磁盘和高速网络接口。 在上图的修改中显示，该图描绘了使用单个NAS的两个数据库服务器。  你将会注意到，这种架构增加了系统整体的请求处理能力，但只是简单的将单点故障从数据库服务层转移到存储层。最终，没有从根本上提升数据库的可用性。 ## 扩容一致性 – 主从架构模型 随着分布式系统变得越来越普遍，对更高容量的分布式数据库的需求也在增长。许多分布式数据库仍然想要保证ACID（或者在某些情况下只保证数据一致性，这点在分布式环境中是最困难的），从而产生了master-salve主从架构. 这种架构下，可能会有许多服务器处理请求，但是为了保证数据的一致性状态，只有一个服务器可以真实的执行写请求。这样避免了在并发写场景下同样的数据被路由到不同的节点进行修改操作。下面的图展示了最基础的情况：  然而，我们还是没有解决可用性的问题，因为数据库主节点(master)的宕机会导致应用的停服。这也就是说主节点不能很好的扩容，因为写请求只路由到一个单机节点上。 ### 使用分片来扩容主节点 有另外一种可以提升主从架构写入吞吐量的技术叫做分片(sharding)，在这种方式下，数据根据keys值不同被划分到不同分组，一个或者多个master可以拥有已知的keys集合。例如，一个用户资料的数据库可以通过姓来分区，A-M属于一个集群，N-Z属于另一个集群。如下：  细心的读者会发现主从架构和分片都在主节点上引入了故障点的问题，事实上，分片技术额外引入了对每个master单点故障的多点故障。此外，含有key的请求信息取决于应用层，并且添加分片需要手动重排数据以适应修改的key范围。 有些系统使用分片管理作为一个在应用层和物理分片之间的抽象层。这样做的好处是应用层不需要知道分区的映射关系。但是，随着集群的增长，还是不能避免需要对数据进行重排。 ### 接管故障的主节点 ---- 提升可用性的一种通用方式是实现主备倒换协议。主备倒换协议有很多种实现，但是一个基本准则是原有主节点宕机时再分配一个新的主节点。并非所有主备倒换算法都相同; 但是，一般情况下主备倒换协议都可以提升主从系统的可用性。 即使是实现了选主协议的主从数据库还是存在许多缺点： ​ 应用必须了解数据库策略 ​ 数据分区规则需提前规划 ​ 主节点很难扩容 ​ 主备倒换增加系统复杂性，尤其对多节点的数据库 ​ 扩容需要重排数据，并有可能导致停机 考虑到我们的目标是一个高度可用的系统，并且假设可扩展性是一个关心的问题，我们还需要考虑其他选择吗？ ## 打破传统 – Cassandra's 选择 实际情况是，并非每个应用程序中的每个事务都需要保证完整的ACID，ACID特性本身可以被视为一个连续统一体，其中给定的事务可能需要不同程度的每个属性。 Cassandra的可用性方法考虑了这一连续性。对比其他的关系型数据库，和同时代的大多数NoSQL相比，其原始架构考虑可用性作为关键的设计目标，旨在实现在服时间100%的难以实现的目标。Cassandra提供了许多旋钮，可以为用户提供高度精细的ACID属性控制，所有这些都有不同的权衡。 ## Cassandra's 对等节点架构 不像单体应用或者主从架构设计，cassandra完全采用对等节点架构。不管数据被写入或者请求到集群的任何一个节点，cassandra集群中所有的节点都可以接受读写请求，内部节点通信采用的是gossip协议，gossip协议可以在不需要主节点的情况下，迅速同步节点之间的元数据信息。 这是一种功能强大的设计，因为它意味着系统本身具有固有的可用性和大规模可扩展性。 请考虑以下图表：  注意同单机和master-slave的结构进行对比，该结构没有特殊节点。事实上，所有的节点本质上一样，因此cassandra没有单点故障，不再不要复杂的sharding或者leader选举。但现在的cassandra如何避免sharding？ ### 一致性哈希 Cassandra使用了一种数据结构可以让任意节点根据指定key轻松定位到数据所在节点，有了这种数据结构，使得Cassandra可以兼顾可用性和可拓展性。这种数据结构就是基于Amazon Dynamo 架构的分布式哈希表(distributed hash table DHT)。 正如我们之前看到的图，Cassandra的拓扑结构是一个哈希环，每个节点负责环上的一部分数据。通过一致性哈希算法将key分配给特定节点，在这期间允许添加或删除节点，而无需基于新范围重新哈希每个key。 拥有给定key的节点由所选分区器（partitioner)确定。Cassandra附带了几个分区器（partitioner）实现，或者开发人员可以通过实现Java接口来定义自己的分区器（partitioner）。 这些话题在下章用大量细节来阐述。 ### 多节点复制 分布式数据库最重要的一个方面是处理集群中数据复制的方式。如果每个分区(partition)仅仅被存储在一个单节点，系统将很有可能会出现单点故障，并且任何一个节点故障都会导致灾难性的数据丢失。因此，这样的系统必须能够跨多个节点复制数据，尽可能的避免数据丢失的情况。 Cassandra拥有先进的副本策略，可提供机架和数据中心感知功能。这意味着它可以配置这样的复制策略，即使发生了如交换机故障，网络分区或数据中心中断等灾难性事件，数据库依然可以对外提供服务。Cassandra同样可以处理在节点故障的情况下，也可以维持原有的副本策略。 多数据中心复制 也许cassandra为实现高可用提供的最独特的特性是多数据中心复制系统。这个系统可以很容易的被配置来通过数据通过物理的或者虚拟的数据中心。这有利于地理位置分散的数据中心放置，而无需复杂的方案来保持数据同步。它还允许您为在线事务和繁重的分析工作负载创建单独的数据中心，同时允许在一个数据中心中写入的数据立即反映在其他数据中心中。 ### 一致性级别 和副本策略紧密关联的是一致性级别，ACID中的C想要保持副本的同步。Cassandra通常被称为最终一致性的系统，这个术语可能会让那些习惯了使用强一致性的关系型数据库的人感到恐慌。然而，正如前面讨论的，一致性应该被认为一个连续统一体，并不是绝对的。 考虑到这一点，Cassandra可以更准确地描述为具有可调整的一致性，其中可以在持久性级别上指定精确的一致性保证程度。这使应用程序架构师能够最终控制调用级别的一致性，可用性和性能之间的权衡，而不是在每个用例上强制实施一刀切的策略。 CAP理论 如果没有考虑CAP理论，任何关于一致性的讨论都是不完整的。CAP首字母缩写是指复制系统中的三个理想属性： ​ Consistency：数据在集群中的所有节点应该相同。 ​ Availability: 系统应该始终可以处理请求。 ​ Partition tolerance(分区容错性): 系统应在部分故障时继续运行. 2000年，加利福尼亚伯克利大学的Eric Brewer计算机教授认为，多副本服务只能选择任何给定操作的三个属性中的两个。 CAP定理被广泛误用，表明整个系统必须只选择两个属性，这导致许多人将数据库定义为AP或CP。 事实上，大多数系统都不适合任何一种类型，而Cassandra也不例外。 Brewer本人在他的2012年文章“十二年后的CAP：规则如何改变”中解决了这种错误的解释： “..所有三个属性都比二进制更连续。 可用性显然是从0到100％连续，但也有很多级别的一致性，甚至分区也有细微差别，包括系统内部是否存在分区存在分歧” 在该文章中，Brewer也指出在ACID范围的一致性定义和CAP的一致性定义不同。在ACID中，一致性是指保证遵循所有数据库规则（唯一约束，外键约束等）。另一方面，如Brewer所说的，CAP的一致性仅指单拷贝一致性，是ACID一致性的严格子集。 在考虑Cassandra一致性级别选项的各种权衡时，重要的是要记住CAP属性存在于连续体而不是二元选择上。 最重要的是，在设计基于Cassandra的系统时，牢记这一连续性非常重要。 有关在各种情况下正确调整Cassandra一致性级别的其他详细信息，请参阅第3章“复制”。 ## 小结 本章节，我们讨论了cassandra的可用性方法，并且为什么做出这个基本设计。这本书的剩余部分基于这个基础来构成。我们将讨论以下主题：如何配置Cassandra以实现高可用性，在Cassandra上设计高可用性应用程序，避免常见的反模式，以及处理各种故障情况。 在本书的最后，您应该牢牢掌握这些概念，并确信您已成功部署了最强大和可扩展的数据库之一。 但是，我们需要一步一步，所以在接下来的几章中，我们将更深入地了解Cassandra如何管理数据。 这个基础对于本书后面讨论的主题是必要的。 我们将在下一章开始讨论Cassandra的数据放置策略。

往期回顾+材料下载：https://bbs.huaweicloud.com/forum/thread-13022-1-1.htmlCloud Native LIves 直播 【Istio服务网格系列】第6课《Istio Mixer架构设计与应用》01月10日 晚 20：00-21:00 直播可选择以下观看方式：1、在线直播及回放地址：http://zhibo.huaweicloud.com/watch/26968162、手机扫码收看：（直播及回放观看二维码）（欢迎回帖提问，会邀请讲师回复问题，也可以现场向讲师发问！参与直播互动还有惊喜哦！）本期课程介绍：【Cloud Native Lives 】直播系列 于每周四晚20：00-21：00 举行直播，每期给您丰富的知识体验！每期直播预告+材料下载，请点击收藏本帖：https://bbs.huaweicloud.com/forum/thread-13022-1-1.html演讲材料下载：【Cloud Native Lives】 第6课：Mixer 功能架构与实践.pdf( 预览 )【品牌课程介绍】Cloud Native：云原生是云计算必然的发展方向。自从Cloud2.0时代来临，许多公司都希望完成传统应用到云端的迁移，但是这个过程中会遇到一些技术难题。云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生的出现，可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。Cloud Native Lives ：系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。讲师团队：主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。

点击下载ppt完整版【热门活动】寻找超级算法大师-挑战最优算法，赢取荣耀8X！跳转链接：https://bbs.huaweicloud.com/forum/thread-13282-1-1.html