标签：hash 集群 分布式系统 一致性 设计 运用 数据 节点
分布式系统设计与运用实践
计算机科学与技术学院
计算机科学与技术专业二班 20191687310088 郭超
摘 要：分布式系统的出现是为了解决单机架构下服务器的服务压力，尤其是在当下互联网大数据时代，每天所产生的数据是过去的十年的数据。那么对于这么多的数据，我们现阶段计算机硬件的所能够处理的数据吞吐量是远远无法满足的，所以需要将单体计算机优化到多体计算机集群的形式来进行数据的存储，即由众多分散部署的计算机通过网络连接形成的集群进而形成的分布式计算机系统，系统的处理和控制各个功能均由系统的每一条主机负责，系统中的各个主机相互独立也相互依赖。除此之外，分布式系统的引入还增强了整个数据的可靠性和安全性，在分布式系统中的主机可能会出现某台主机宕机的情况，这时就可以依赖系统中的其他主机进行服务，大大提高了容灾性，这在单机模型下是无法实现的。
关键词：分布式、大数据、算法设计
分布式系统并不是简单的进行多计算机之间的数据备份，还要考虑非常多的问题，比如集群中每个节点的数据一致性，因为分布式系统中的每一台主机都能满足服务的要求。由此，本文从分布式系统的特点、理论基础、一致性算法这三个主要方面进行论述介绍，最后引入一个实际应用，来深一步的探索分布式的设计和实际应用场景。
1、分布式系统的基本概念
分布式系统直观来讲多个网络计算机之间相互支持合作，这些网络计算机如果不进行集群间的通信，就是一种单体结构，但是如果要与集群中的其他计算机进行通信和服务交流，那就必须配置进行通信的软硬件，比如下载一个zookeeper或者是其他通信软件，这些软件都是通过网络通信和交流进而形成具备协调能力的一个多机系统。简单来说，就是集群中的每个计算机共同对外界的请求进行服务，我们使用用户发出请求的时候，不考虑该将请求发往那一台计算机，就像是一台计算机在提供服务一样，例如我们直接输入百度的首页地址，这个URL请求会进行负载均衡发送到合适的计算机，而不需要我们客户考虑。甚至可以理解为，将单体计算机结构的所有资源全部分散到一个个小型计算机。而且这些小型计算机的在空间上几乎没有任何限制，所以每一台计算机的物理资源肯定也是不一样的，对于经常被访问的机器，我们可以适当提高物理资源的投入，比如利用Redis作为缓存服务器，对于热点机器，我们可以适当加大内存的设置，或者是CPU的提升。利用网络通信，可以将这些计算机放到不同的机房中，不同的城市中，对于大型的网站甚至可能分布在不同的国家和地区。
图1.1：分布式JavaWeb服务器与用户的交互
1.1分布式系统的主要特征
分布式系统主要有以下四个特征，一：分布性，即在分布式系统中的计算机集群在空间位置上是随意分布的，比如可以将多台计算机同时放置一个地区或者是多个地区，由于网络通信，并不造成任何服务困扰，而且每一台机器在本地区的分布也不是固定的。二：平等性：在分布式系统中的各个计算机每个计算机节点都是平等的，每一台计算机都可以进行集群的整体把握控制，也可以不参与集群控制，只进行基本操作即可。三：独立性，分布式系统中的各个节点都配置了进行服务的硬件和软件，这些软件和硬件可以相同也可以不相同，例如，全部配置JDK，但是，每一台机器的JDK可能是不一样的，有的是linux版本，有的是windows版本的，但是尽管如此，他们依旧能够独立处理发往本机的请求，具备独立处理数据的能力，但这不代表集群中的节点互不通信，他们是可以通过网络通信进行数据交互，协调任务处理。四：并发性，在一个计算机网络中，可能有多个请求要操作同一个数据，然而这些数据不是存储在一台计算机上的，比如淘宝的库存秒杀，在短时间内有众多请求要将库存减一，这时，就必须控制发来的并发请求进行合理的顺序操作，否则就会发生超买的现象。解决并发问题可以有效地提高集群的工作能力，其中一个解决方法就是引入分布式锁。
1.2分布式系统运行的性能指标
性能代表的是系统的吞吐能力，指系统在有限时间处理的数据总量，例如10钟的时间处理了100000条更新数据库的操作，通常可以用单位时间处理的数据量（每秒钟）来衡量。这也就是我们所说的QPS（每一秒服务的查询请求），用来衡量系统的并发能力；我们知道，对于请求的响应是有时延的，指的是客户端发来一条请求到获得响应的时间长，很显然，系统的处理时延越短，用户的体验就越号。系统平均响应时间较长时，也很难提高QPS。可扩展性：上文我们讲到了，分布式系统的分布式特性，即主机的动态设置和动态变化，设想一下，如果系统中大量添加或者是删除了一些主机，系统的扩展性如果不强的话，那么这将会造成大量的人工和财力成本，系统的性能是否也会收到影响，系统对于数据的处理能力是否增强或者下降，计算能力是否也会被抑制，这些也是需要考虑的地方。我们日常写代码的时候，追求的是高内聚和低耦合，那么对于集群的设置和部署，我们也应该考虑系统的可扩展性，最好的状况就是“线性扩展”，即系统的性能等指标可以随着集群中机器数量的增加而增加。一致性：一致性问题的出现非常重要，他和并发性问题是离不开的，一般设计并发性的问题都离不开对于共享数据的处理，不过这里的一致性强调的是集群中每一条机器数据是否统一的问题，我们可以让每一台机器每时每刻都数据一致，也可以考虑短时间的数据不一致而最终达到一致。
2、分布式系统理论概念
2.1 CAP理论
CAP理论是分布式系统、特别是分布式存储领域中被讨论的最多的理论。其中C代表一致性 (Consistency)，A代表实时可用性 (Availability)，P代表分区可用性 (Partition tolerance)。CAP理论告诉我们C、A、P三者不能同时满足，最多只能满足其中两个。
一致性：对于集群中的节点，如果这个节点是一个存储数据的节点，我们要考虑它与所有存储数据的节点的数据版本一定要一致，否则这个数据节点存储的可能是一个错误的数据或者是过期的数据
实时可用性：对于集群中网络不连通的情况下，有的节点可能会宕机或者不可用，实时可用要求在这些主机不可用的情况下仍然能够对外提供正常的服务，不超时不失败。
分区可用性：我们知道分布式的主机大概率可能都是跨地区的，那么就一定会出现网络中断所造成的集群通信阻断的问题，被分隔的节点（注：是一部分节点，不是所有被分隔的节点）仍能正常对外提供服务就是分区可用性。
图2.1：CAP理论
下面我们从三个角度来解释为什么同时满足CAP特性：
1、满足CA特性，不满足P特性：满足数据一致性，那么集群中没有被分隔的节点是网路互通的并且可以正常服务。P特性要求必须是分区网络不互通。
2、满足PA特性，不满足C特性：当集群中网络断开不能通信，意味着各个机器节点之间是无法交流的，所以无法达到数据交换并进行统一，即不满足C特性，但是只要自己不宕机则满足PA属性。
3、满足PC特性，不满足A特性：在网格分区断网的情况下，为了保持数据一致性，某些分区的节点主机从服务集群中舍弃，即设置为失效的。那么就保证了有用的节点数据都是一致，这也显然表明了，无法服务的主句是失效的，所以当请求来到这些节点的时候就会出现访问超时或者是请求失败。
2.2 BASE理论
BASE理论并不是一个全新的理论，它其实是CAP理论的改进补充版本，也满足CAP的特性，只不过BASE理论在数据的一致性上做了新的改进说明，不再追求实时的集群数据统一。
下面来详细说明一下BASE的含义：
1、BS指的是Basically Available （基本可用）：我们知道，分布式系统中的各个主机并不是每时每刻都正常运行的，一旦发生故障，这个系统要允许在这些故障的前提下，继续提供服务。
2、S指的是Soft state （软状态）：系统中的数据并不是一旦被存储就是最终被正确使用的数据，有些数据可能是中间状态，但是这些中间状态数据并不会影响整个系统的对外服务，比如我们下单购物车，但是还没有付款，数据库中是会执行减一操作的，但是我们一旦超时未支付，它还是会执行加一操作，在此期间，其他用户看到的还是减一的数据，但不影响整体的系统服务。
3、E指的是Eventually consistent（最终一致性）：正如上面所说的，数据是可能存在中间状态的，最终一致性要求系统中规定的数据在规定的时间过后进行数据同步，然后将数据统一成一个最终版本，与强一致性所要求的实时的数据一致是不相同的。
BASE理论其实就是对于CAP理论中的一致性和可用性做出的一种取舍，是从CAP定理一步一步演化而来的，经过了实际中国公司的实践，他的核心思想就是通过业务代码的实现，比如通过添加消息中间件kafka、RabbitMQ等来减弱强一致性进而增强可用性，数据因为有了缓存的概念，就不满足强一致性，但是经过一段时间最终还是会达到一致性状态，也可以理解为是CAP理论的补充方案。
ACID是传统关系型数据库的设计理念，经常地被使用，它追求强一致性模型，而BASE理论支持的是大型分布式系统，追求通过牺牲强一致性进而获得高可用。
3、分布式一致性算法
3.1 一致性Hash算法
在请求到来，需要获得主机位置新的的时候，经常被采用的其实就是通过hash算法来下标寻址，然而，我们都知道，hash算法存在hash冲突，更存在rehash操作，这些操作都是非常消耗时间和性能的，对于集群来说也是一样的。试想一下，当集群中添加或者删除了一个主机，所要做的rehash操作该会多么的大，所以，在普通hash算法的基础上出现了一致性hash算法，概括来说就是将被hash的对象抽象为一组数据或者是一段数据，当轻微的数据改变的时候，并不会造成大量的rehash操作。
一致性hash算法是常规hash算法的改进版，下面介绍一下他的具体流程：
1、使用常见的hash算法将一个key值hash到一个桶空间中，并且形成一个环形空间。
2、将一定数量的key值通过一定的hash算法将其对应到上面的环形hash空间中去。
3、同样的，将服务器也通过hash算法加入到上述的环中。
数据存储到服务器过程：
通过key值hash之后在环上可按照顺序找到离自己最近的机器节点，最终就可以把数据存储到上面去。
3.2 Raft算法
Raft算法的提出和zookeeper的状态选举很像，同样考虑的各个主机之间通过主从节点的思想，进行数据日志的相互同步，进而达到集群中的数据一致。
Raft将系统中的角色分为领导者、跟从者和候选人：
他们各自的作用：
Leader：顾名思义，leader就是领导者，进行集群中数据的同步和分发，主要去接收其他非leader节点的数据同步日志。
Follow：leader中的数据一般都是最新的实时的，当自己的数据与leader不同时，他就会将leader发来的数据同步请求日志执行，最终会提交日志。
Candidate：候选人角色，他的状态是随时可以改变的，可以成为follow也可以成为leader。
图3.2 Raft角色
4、分布式系统实践场景
基于ELK、Zookeeper、filebeat、kafka是一种企业级的分布式应用架构，Zookeeper是一种分布式协调工具，专门用来管理分布式系统中的机器，首先，Zookeeper满足CP特性，即对于数据的最终一致性确定，他的不可用体现在leader的选举过程中。除了Zookeeper，满足AP特性的还有 Eureka。
基于本人实际的搭建过程，总结出以下使用情景：首先，对于分布式系统的引入，我们不需要任何系统都引入分布式系统架构，当整个系统中出现了架构分部特别广的情况下，我们可以考虑引入分布式；又或者说，当整个系统设计高并发、高需求的情况下，也可以引入分布式架构。针对ELK这个架构，之所以引入Zookeeper，是因为引入了kafka，kafka解决了logstash处理能力低下的缺点，为此引入了filebeat，但是filebeat在网络传输过程中可能操作数据的丢失，为此将搜集的数据线存放在kafka这个消息队列中，logstash根据自己的处理能力实现异步处理的能力，同时配置kafka集群，增大了容错能力和单个主机的压力，通过Zookeeper进而实现了集群的管理。
由此可见，在引入分布式架构的时候，我们要考虑的方面很多，但单机模式已经可以满足业务的需求的时候，我们没必要大费周章进行分布式系统的架构和部署。
参考文献
[1]胡琪,王晓懿,贺国平.基于Raft协议的两节点主备系统调度算法[J].软件导刊,2022,21(04):109-115.
[2]丁凡.分布式系统的故障管理与应用动态重构[J].信息技术与信息化,2022,(03):77-80.
[3]珠海华润银行日志管理与分析平台课题组,杨京健.基于ELK的日志管理与分析平台实践[J].金融科技时代,2022,30(01):59-62.
[4]任安,冯佳,朱玉立.基于Zookeeper服务的数据库同步研究与实现[J].信息系统工程,2020,(07):116-117.
[5]李书达,刘遵仁,朱琦.基于ELK的运维辅助系统的设计与实现[J].青岛大学学报(工程技术版),2022,37(01):18-23.
标签：hash,集群,分布式系统,一致性,设计,运用,数据,节点 来源： https://www.cnblogs.com/HNUGC/p/16387888.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。