走进Hbase-初识分布式

Posted 2021-04-19 百变码神

最前面的话

        Hbase虽然可以单机运行，但更多时候我们需要运行一个分布式的Hbase。倘若这是你第一次踏入分布式计算的精彩世界，你会感到这是一个有趣的年代。分布式计算是很难的，做一个分布式系统需要很多软硬件和网络的技能。你的集群可以会因为各式各样的错误发生故障。比如HBase本身的Bug,错误的配置(包括操作系统)，硬件的故障(网卡和磁盘甚至内存) 。如果你一直在写单机程序的话，你需要重新开始学习。这里就是一个好的起点: 分布式计算的谬论。如果你已经接触到分布式相关编程，并且有一定分布式基础，可以选择忽略这一节，或者选择跟着这个文章重新回味一下分布式各个名词。

谬误

• 该网络是可靠的。

• 延迟为零。

• 带宽是无限的。

• 网络是安全的。

• 拓扑不会改变。

• 有一个管理员。

• 运输成本为零。

• 网络是同质的。

谬误的影响          

• 软件应用程序的编写几乎不会出现网络错误的错误处理。在网络中断期间，这些应用程序可能会停顿或无限等待应答数据包，永久消耗内存或其他资源。当发生故障的网络可用时，这些应用程序也可能无法重试任何停顿的操作或需要（手动）重新启动。

• 对网络延迟以及它可能造成的数据包丢失的忽视，会导致应用程序和传输层开发人员允许无限制的流量，极大地增加丢弃的数据包并浪费带宽。

• 部分通信发送者对带宽限制的忽略可能导致频率复用媒体的瓶颈。

• 有关网络安全的满足感会导致恶意用户和不断适应安全措施的程序不知所措。

• 网络拓扑结构的变化可能会对带宽和延迟问题产生影响，因此也会产生类似的问题。

• 与对手公司的子网一样，多个管理员可能会制定冲突的策略，以使网络流量的发送者必须知道这些策略才能完成其所需的路径。

• 建立和维护网络或子网的“隐藏”成本是不可忽视的，因此必须在预算中注明，以避免巨大的不足。

• 如果一个系统假定一个同质网络，那么它可能导致前三个谬误导致的相同问题。

CAP定理

在理论计算机科学中，计算机科学家Eric Brewer之后命名为布鲁尔定理的CAP定理指出，分布式数据存储不可能同时提供以下三种保证中的两种以上：

• 一致性：每次读取都会收到最近的写入或错误

• 可用性：每个请求都会收到一个（非错误）响应 - 不保证它包含最新的写入

• 分区容错：即使网络在节点之间丢弃（或延迟）任意数量的消息，系统仍会继续运行

特别是，CAP定理意味着在存在网络分区时，必须在一致性和可用性之间进行选择。请注意，CAP定理中定义的一致性与ACID 数据库事务中保证的一致性完全不同。

在网络故障下，没有分布式系统是安全的，因此通常必须容忍网络分区。在存在分区的情况下，剩下一个选项：一致性或可用性。当选择一致性时，如果由于网络分区而无法保证特定信息是最新的，则系统将返回错误或超时。在选择可用性时，系统将始终处理查询并尝试返回最新版本的信息，即使由于网络分区无法保证它是最新版本。

在没有网络故障的情况下 - 即分布式系统正常运行时 - 可以满足可用性和一致性。

CAP经常被误解，就好像人们必须随时选择放弃三项保证中的一项。事实上，只有当网络分区或故障发生时，才会选择一致性和可用性; 在其他任何时候，都不得做出折衷。

考虑到传统ACID保证的数据库系统（如RDBMS）选择可用性的一致性，而围绕BASE理念设计的系统（例如NoSQL机制中常见的）则选择可用性而非一致性。

所述PACELC定理通过阐明，即使在不存在划分的，延迟和一致性之间的另一种折衷发生建立在CAP。

ACID

ACID（Atomicity，Consistency，Isolation，Durability）是一组数据库事务的属性，即使在出现错误，断电等情况下也能保证有效性。在数据库的上下文中，一系列数据库操作满足ACID属性，并且因此可以被视为对数据的单个逻辑操作，被称为事务。例如，将资金从一个银行账户转移到另一个银行账户，即使涉及多个变更，例如借记一个账户和贷记另一个账户，也是一笔交易。

1983年，安德烈亚斯路透社和西奥更难创造的缩写ACID速记为原子性，一致性，隔离性和持久性，建立在先前的工作由吉姆·格雷谁列举的原子性，一致性和耐久性，而且离开了隔离当表征交易概念。这四个属性描述了交易模式的主要保证，它影响了数据库系统开发的许多方面。

原子性保证每个事务都被视为一个单元，它可以完全成功或完全失败：如果构成事务的任何语句无法完成，则整个事务将失败并且数据库保持不变。原子系统必须保证每种情况下的原子性，包括电源故障，错误和崩溃。

一致性确保事务只能将数据库从一个有效状态转移到另一个有效状态，从而维护数据库不变量：写入数据库的任何数据必须根据所有已定义的规则（包括约束，级联，触发器及其任意组合）有效。这可以防止非法事务导致数据库损坏，但不保证事务是正确的。

隔离确保了事务的并发执行使数据库处于与按顺序执行事务时所获得的状态相同的状态。隔离是并发控制的主要目标; 取决于所使用的方法，未完成交易的效果可能对其他交易不可见。

耐久性（持久性）保证一旦事务被提交，即使在系统故障（例如，停电或崩溃）的情况下，它也将保持提交。这通常意味着完成的交易（或其影响）被记录在非易失性存储器中。

由于本系列内容为分布式的Hbase，ACID的更多具体细节，不在此赘述。

Base理念（Basically Available, Soft state, Eventual consistency）

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，但请注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子。

• 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。

• 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

在实际工程实践中，最终一致性存在以下五类主要变种。

因果一致性：

        因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。

读己之所写：

        读己之所写是指，进程A更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者而言，其读取到的数据一定不会比自己上次写入的值旧。因此，读己之所写也可以看作是一种特殊的因果一致性。

会话一致性：

        会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读己之所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

单调读一致性：

        单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

单调写一致性：

         单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。

以上就是最终一致性的五类常见的变种，在时间系统实践中，可以将其中的若干个变种互相结合起来，以构建一个具有最终一致性的分布式系统。事实上，可以将其中的若干个变种相互结合起来，以构建一个具有最终一致性特性的分布式系统。事实上，最终一致性并不是只有那些大型分布式系统才设计的特性，许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中，大多都会采用同步和异步方式来实现主备数据复制技术。在同步方式中，数据的复制过程通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往存在延时，这取决于事务日志在主备数据库之间传输的时间长短，如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上，那么很显然，从备库中读取的的数据将是旧的，因此就出现了不一致的情况。当然，无论是采用多次重试还是人为数据订正，关系型数据库还是能够保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性使相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用。

PACELC定理

PACELC定理是CAP定理的扩展。它指出，如果在分布式计算机系统中进行网络分区（P），则必须在可用性（A）和一致性（C）（按照CAP定理）之间进行选择，但是否则（E）即使系统是在没有分区的情况下正常运行，必须在延迟（L）和一致性（C）之间进行选择。

微服务

微服务是一种软件开发技术 - 面向服务的体系结构（SOA）体系结构风格的一种变体，它将应用程序构建为一系列松散耦合的服务。在微服务架构中，服务是细粒度的，协议是轻量级的。将应用程序分解为不同的小型服务的好处是，它可以提高模块化程度，并使应用程序更容易理解，开发，测试，并且更有弹性以抵御架构侵蚀。它还通过使小型自治团队得以发展来平行发展，独立部署和扩展各自的服务。它还允许通过持续重构来实现单个服务的体系结构。基于微服务的体系结构支持持续交付和部署。

目前还没有业界对微服务的属性达成共识，官方定义也不存在。经常被引用的一些定义特征包括：

• 在一个微服务架构（MSA）服务通常过程，超过一个通信网络以满足使用技术无关目标协议（如HTTP）。但是，服务也可能使用其他种类的进程间通信机制，如共享内存。服务也可能在与OSGI捆绑包相同的过程中运行。

• 微服务架构中的服务可独立部署。

• 这些服务很容易更换。

• 服务围绕功能进行组织，例如用户界面前端，推荐，物流，计费等。

• 可以使用不同的编程语言，数据库，硬件和软件环境来实现服务，具体取决于最适合的类型。

• 服务规模小，支持消息传递，受上下文限制，自主开发，可独立部署，分散，构建和发布自动化流程。

基于微服务的体系结构：

• 自然执行模块化结构。

• 适用于持续交付软件开发流程。对应用程序的一小部分进行更改只需要重新构建和重新部署一个或少量的服务。

• 遵循诸如细粒度 接口（可独立部署的服务），业务驱动开发（如域驱动设计），IDEAL 云应用程序体系结构，多语种编程和持久性，轻量级容器部署，分散式持续交付以及具有整体性的DevOps等原则服务监控。

• 提供有利于可扩展性的特性。

其他连载导航