CN111913837A - 大数据环境下实现分布式中间件消息恢复策略管理的系统 - Google Patents
大数据环境下实现分布式中间件消息恢复策略管理的系统 Download PDFInfo
- Publication number
- CN111913837A CN111913837A CN202010825880.1A CN202010825880A CN111913837A CN 111913837 A CN111913837 A CN 111913837A CN 202010825880 A CN202010825880 A CN 202010825880A CN 111913837 A CN111913837 A CN 111913837A
- Authority
- CN
- China
- Prior art keywords
- copy
- policy
- message
- data
- environment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000011084 recovery Methods 0.000 title claims abstract description 57
- 238000013461 design Methods 0.000 claims abstract description 27
- 230000001360 synchronised effect Effects 0.000 claims abstract description 9
- 238000005192 partition Methods 0.000 claims description 72
- 230000007246 mechanism Effects 0.000 claims description 27
- 238000000034 method Methods 0.000 claims description 23
- 230000008569 process Effects 0.000 claims description 12
- 238000009826 distribution Methods 0.000 claims description 10
- 238000004519 manufacturing process Methods 0.000 claims description 9
- 238000012986 modification Methods 0.000 abstract description 4
- 230000004048 modification Effects 0.000 abstract description 4
- 230000008859 change Effects 0.000 abstract description 3
- 238000004891 communication Methods 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 9
- 238000012545 processing Methods 0.000 description 6
- 238000000638 solvent extraction Methods 0.000 description 5
- 238000004422 calculation algorithm Methods 0.000 description 4
- 238000010276 construction Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000010354 integration Effects 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000010076 replication Effects 0.000 description 2
- 241001522296 Erithacus rubecula Species 0.000 description 1
- 241000220324 Pyrus Species 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000004907 flux Effects 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 235000021017 pears Nutrition 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 235000013555 soy sauce Nutrition 0.000 description 1
- 238000003860 storage Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3476—Data logging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/275—Synchronous replication
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Databases & Information Systems (AREA)
- Computing Systems (AREA)
- Data Mining & Analysis (AREA)
- Computer Hardware Design (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明涉及一种大数据环境下实现分布式中间件消息恢复策略管理的系统，包括环境初始化模块，用于满足分布式集群搭建的基本条件；恢复策略设计模块，与所述的环境初始化模块相连接，用于使用副本集合中的ISR设计恢复策略，通过副本恢复数据；分布式集群应用模块，与所述的恢复策略设计模块相连接，用于在宕机的情况下恢复数据。采用了本发明的大数据环境下实现分布式中间件消息恢复策略管理的系统，通过模拟成为主从设备的方式，监听源库的日志来获取数据，获取到执行的每一个增删改的脚本、修改前和修改后的数据来实现数据及时同步变更。
Description
技术领域
本发明涉及大数据分布式领域，尤其涉及分布式中间件领域，具体是指一种大数据环境下实现分布式中间件消息恢复策略管理的系统。
背景技术
随着国内信息化建设的日益深入，越来越多的企业开始进入深度应用的阶段，而中间件也迎来了千树万树梨花开的阶段。消息中间件凭借高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成，通过提供消息传递和消息排队模型，在分布式环境下扩展进程间的通信的模式，在国内许多行业的关键应用中扮演着至关重要的角色，如在政务行业省、市、县多级数据传递交换汇总，金融行业等中多处应用。
消息中间件是指利用高效可靠的消息传输机制进行平台无关的数据交流，并且基于数据通信来进行分布式系统的集成，最突出的特点就是提供数据传输的可靠性和高效性，主要解决分布式的系统数据传输需求。其中，在生产和消费消息的过程中，对于消息的整个生命周期中，存在数据不完整和宕机的风险，影响数据的使用和价值，宕机恢复策略是一种数据恢复方式，可以降低数据丢失的风险，提升数据本应发挥的价值。
目前，在分布式系统中中间件的使用中，当分布式系统的所有Leader、follower节点都能正常运行且消息都正常同步的时候，消息完整且准确，当存在某个节点出现宕机的时候，其余节点正常，消息也可以通过主、从正常恢复，具体的实现步骤如下：
1.初始化环境，配置zookeeper来做master选举一起实现数据的维护；
2.分别配置kafka的到多台机器上，修改配置，同一个集群中的每个机器的id必须唯一；
3.修改zookeeper的连接配置；
4.修改listeners配置。
根据如上步骤在分布式系统中的消息，通过副本机制来实现冗余备份，来解决单点的问题，当其中一个partition不可用的时候，那么这部分消息可以通过其他副本上备份的办法消费，满足常规的消息生产、消费的要求，但是在实际项目使用中，对于所有的Replica不工作的情况副本机制来实现冗余备份的方法就无法解决该问题，就会存在数据不完整的情况，不能满足系统要求，无法保证数据不丢失了。
目前，在分布式系统中中间件的使用中，当分布式系统的所有Leader、follower节点都能正常运行且消息都正常同步的时候，消息完整且准确，当存在某个节点出现宕机的时候，其余节点正常，消息也可以通过主、从的一主多从的集群中正常恢复，但是在实际项目使用中，分布式系统不可能实现完全稳定和高效可靠的消息传输机制进行平台无关的数据交流，当某个分区的所有副本因为某种原因不能正常工作而宕机，对于所有的Replica不工作的情况副本机制来实现冗余备份的方法就无法解决该问题，就会存在数据不完整的情况，不能满足系统要求，无法保证数据不丢失了。
发明内容
本发明的目的是克服了上述现有技术的缺点，提供了一种满足稳定、高效、可靠的大数据环境下实现分布式中间件消息恢复策略管理的系统。
为了实现上述目的，本发明的大数据环境下实现分布式中间件消息恢复策略管理的系统如下：
该大数据环境下实现分布式中间件消息恢复策略管理的系统，其主要特点是，所述的系统包括：
环境初始化模块，用于满足分布式集群搭建的基本条件；
恢复策略设计模块，与所述的环境初始化模块相连接，用于使用副本集合中的ISR设计恢复策略，通过副本恢复数据；
分布式集群应用模块，与所述的恢复策略设计模块相连接，用于在宕机的情况下恢复数据。
较佳地，所述的环境初始化模块的基本条件包含kafka的生产、消费消息的应用场景、架构、分发和消费原理、ISR和硬件要求。
较佳地，所述的消费消息的应用场景为行为跟踪和日志收集。
较佳地，所述的架构包含若干Producer、若干Broker、若干Consumer Group和zookeeper集群，所述的若干Broker相互连接且协同工作，所述的Producer、Broker和Consumer Group通过zookeeper管理协调请求和转发，所述的Producer通过push模式发布消息至broker，所述的Consumer Group通过监听使用pull模式从broker订阅并消费消息。
较佳地，所述的系统中包含topic消息集合，每个topic消息集合包含多个分区，分区策略分别为默认策略、轮询策略和粘性策略。
较佳地，所述的副本的策略包含分区的副本机制策略、副本的leader选举策略、副本协同机制策略和副本数据同步原理策略。
较佳地，所述的分区的副本机制策略中包含主副本和多个从副本，从副本从主副本同步消息日志，所述的主副本和从副本均匀分配到集群中的不同broker上，在主副本的broker出现故障的情况下，重新选举新的主副本继续对外提供服务。
较佳地，所述的副本的leader选举策略在broker失效的情况下，各个broker重新主副本选举得到新的KafkaController。
较佳地，所述的副本协同机制策略为由主副本的节点接收和处理消息的读写操作，从副本进行同步数据，在主副本所在的broker失效的情况下，在从副本中选取新的主副本。
采用了本发明的大数据环境下实现分布式中间件消息恢复策略管理的系统，通过模拟成为主从设备的方式，监听源库的日志来获取数据，获取到执行的每一个增删改的脚本、修改前和修改后的数据来实现数据及时同步变更。
附图说明
图1为本发明的大数据环境下实现分布式中间件消息恢复策略管理的系统的结构图。
图2为本发明的大数据环境下实现分布式中间件消息恢复策略管理的系统的架构图。
图3为本发明的大数据环境下实现分布式中间件消息恢复策略管理的系统的实施例的实施步骤。
具体实施方式
为了能够更清楚地描述本发明的技术内容，下面结合具体实施例来进行进一步的描述。
本发明的该大数据环境下实现分布式中间件消息恢复策略管理的系统，其中包括：
环境初始化模块，用于满足分布式集群搭建的基本条件；
恢复策略设计模块，与所述的环境初始化模块相连接，用于使用副本集合中的ISR设计恢复策略，通过副本恢复数据；
分布式集群应用模块，与所述的恢复策略设计模块相连接，用于在宕机的情况下恢复数据。
作为本发明的优选实施方式，所述的环境初始化模块的基本条件包含kafka的生产、消费消息的应用场景、架构、分发和消费原理、ISR和硬件要求。
作为本发明的优选实施方式，所述的消费消息的应用场景为行为跟踪和日志收集。
作为本发明的优选实施方式，所述的架构包含若干Producer、若干Broker、若干Consumer Group和zookeeper集群，所述的若干Broker相互连接且协同工作，所述的Producer、Broker和Consumer Group通过zookeeper管理协调请求和转发，所述的Producer通过push模式发布消息至broker，所述的Consumer Group通过监听使用pull模式从broker订阅并消费消息。
作为本发明的优选实施方式，所述的系统中包含topic消息集合，每个topic消息集合包含多个分区，分区策略分别为默认策略、轮询策略和粘性策略。
作为本发明的优选实施方式，所述的副本的策略包含分区的副本机制策略、副本的leader选举策略、副本协同机制策略和副本数据同步原理策略。
作为本发明的优选实施方式，所述的分区的副本机制策略中包含主副本和多个从副本，从副本从主副本同步消息日志，所述的主副本和从副本均匀分配到集群中的不同broker上，在主副本的broker出现故障的情况下，重新选举新的主副本继续对外提供服务。
作为本发明的优选实施方式，所述的副本的leader选举策略在broker失效的情况下，各个broker重新主副本选举得到新的KafkaController。
作为本发明的优选实施方式，所述的副本协同机制策略为由主副本的节点接收和处理消息的读写操作，从副本进行同步数据，在主副本所在的broker失效的情况下，在从副本中选取新的主副本。
本发明的具体实施方式中，使用一种等待ISR中的任一个Replica“活”过来，并且选它作为Leader的消息恢复策略的方法来尽可能减少集群宕机的损失，达到分布式系统之间所有的Replica不工作的情况的问题。
本发明分为环境初始化模块、恢复策略设计模块、分布式集群应用模块。
环境初始化模块是分布式集群搭建需满足的基本条件，主要是指kafka的生产、消费消息的应用场景、架构、分发和消费原理、ISR、硬件要求；恢复策略设计模块的设计是指满足初始化模块中的条件下，在分布式集群中出现的某个Partition的所有Replica都宕机了的情况下采取的策略，本方法中使用副本集合中的ISR设计恢复策略，其中ISR表示目前“可用且消息量与leader相差不多的副本集合，这是整个副本集合的一个子集”；分布式集群应用模块是在初始化模块和恢复策略设计模块完成后，某个Partition的所有Replica都宕机了的情况，使用该设计模块实现数据的恢复。
本发明构成如图1所示。
下面将详细描述环境初始化模块、恢复策略设计模块、分布式集群应用模块。
一、环境初始化模块：
环境初始化模块是分布式集群搭建需满足的基本条件，主要是指kafka的生产、消费消息的应用场景、架构、分发和消费原理、ISR、硬件要求。
Kafka应用场景：
由于kafka具有更好的吞吐量、内置分区、冗余及容错性的优点(kafka每秒可以处理几十万消息)，让kafka成为了一个很好的大规模消息处理应用的解决方案。所以在企业级应用长，主要会应用于如下几个方面：
行为跟踪：kafka可以用于跟踪用户浏览页面、搜索及其他行为。通过发布-订阅模式实时记录到对应的topic中，通过后端大数据平台接入处理分析，并做更进一步的实时处理和监控；
日志收集：日志收集方面，有很多比较优秀的产品，比如Apache Flume，很多公司使用kafka代理日志聚合。日志聚合表示从服务器上收集日志文件，然后放到一个集中的平台(文件服务器)进行处理。在实际应用开发中，我们应用程序的log都会输出到本地的磁盘上，排查问题的话通过linux命令来搞定，如果应用程序组成了负载均衡集群，并且集群的机器有几十台以上，那么想通过日志快速定位到问题，就是很麻烦的事情了。所以一般都会做一个日志统一收集平台管理log日志用来快速查询重要应用的问题。所以很多公司的套路都是把应用日志集中到kafka上，然后分别导入到es和hdfs上，用来做实时检索分析和离线统计数据备份等。而另一方面，kafka本身又提供了很好的api来集成日志并且做日志收集。
项目中平台的注册功能来简单分析下，用户注册这一个服务，不单单只是insert一条数据到数据库里面就完事了，还需要发送激活邮件、发送新人红包或者积分、发送营销短信等一系列操作。假如说这里面的每一个操作，都需要消耗1s，那么整个注册过程就需要耗时4s才能响应给用户。分布式消息队列就是一个非常好的解决办法，引入分布式消息队列以后，架构图就变成这样了(下图是异步消息队列的场景)。通过引入分布式队列，就能够大大提升程序的处理效率，并且还解决了各个模块之间的耦合问题。
在分布式系统中，两个服务之间需要通过异步队列的方式来处理任务，引入消息中间件，利用高效可靠的消息传输机制进行平台无关的数据交流，并且基于数据通信来进行分布式系统的集成，把消息处理交给第三方的服务，这个服务能够实现数据的存储以及传输，使得在分布式架构下实现跨进程的远程消息通信。
架构：
一个典型的kafka集群包含若干Producer(可以是应用节点产生的消息，也可以是通过Flume收集日志产生的事件)，若干个Broker(kafka支持水平扩展)、若干个ConsumerGroup，以及一个zookeeper集群。
kafka通过zookeeper管理集群配置及服务协同。
Producer使用push模式将消息发布到broker，consumer通过监听使用pull模式从broker订阅并消费消息。多个broker协同工作，producer和consumer部署在各个业务逻辑中。
三者通过zookeeper管理协调请求和转发。这样就组成了一个高性能的分布式消息发布和订阅系统。和其他mq中间件不同的点，producer发送消息到broker的过程是push，而consumer从broker消费消息的过程是pull，主动去拉数据。而不是broker把数据主动发送给consumer，如图2所示。
分发和消费原理：
在kafka中，topic是一个存储消息的逻辑概念，可以认为是一个消息集合。每条消息发送到kafka集群的消息都有一个类别。
物理上来说，不同的topic的消息是分开存储的，每个topic可以有多个生产者向它发送消息，也可以有多个消费者去消费其中的消息。
每个topic可以划分多个分区(每个Topic至少有一个分区)，同一topic下的不同分区包含的消息是不同的。每个消息在被添加到分区时，都会被分配一个offset(称之为偏移量)，它是消息在此分区中的唯一编号，kafka通过offset保证消息在分区内的顺序，offset的顺序不跨分区，即kafka只保证在同一个分区内的消息是有序的。每一条消息发送到broker时，会根据partition的规则选择存储到哪一个partition。如果partition规则设置合理，那么所有的消息会均匀的分布在不同的partition中，这样就有点类似数据库的分库分表的概念，把数据做了分片处理。消息是kafka中最基本的数据单元，在kafka中，一条消息由key、value两部分构成，在发送一条消息时，我们可以指定这个key，那么producer会根据key和partition机制来判断当前这条消息应该发送并存储到哪个partition中。默认情况下，kafka采用的是hash取模的分区算法。如果Key为null，则会随机分配一个分区。这个随机是在这个参数”metadata.max.age.ms”的时间范围内随机选择一个。对于这个时间段内，如果key为null，则只会发送到唯一的分区。这个值值哦默认情况下是10分钟更新一次。关于Metadata，简单理解就是Topic/Partition和broker的映射关系，每一个topic的每一个partition，需要知道对应的broker列表是什么，leader是谁、follower是谁。这些信息都是存储在Metadata这个类里面。
消息消费原理，在实际生产过程中，每个topic都会有多个partitions，
多个partitions的好处在于，一方面能够对broker上的数据进行分片有效减少了消息的容量从而提升io性能。另外一方面，为了提高消费端的消费能力，一般会通过多个consumer去消费同一个topic，也就是消费端的负载均衡机制，也就是我们接下来要了解的，在多个partition以及多个consumer的情况下，consumer属于一个consumer group，组内的所有消费者协调在一起来消费订阅主题的所有分区。当然每一个分区只能由同一个消费组内的consumer来消费。
在kafka中，存在三种分区分配策略一种是Range(默认)、另一种是RoundRobin(轮询)、StickyAssignor(粘性)。
Range策略是对每个主题而言的，首先对同一个主题里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。
RoundRobinAssignor(轮询分区)轮询分区策略是把所有partition和所有consumer线程都列出来，然后按照hashcode进行排序。最后通过轮询算法分配partition给消费线程。如果所有consumer实例的订阅是相同的，那么partition会均匀分布。
StrickyAssignor分配策略，StrickyAssignor，翻译过来叫粘滞策略，它主要有两个目的：分区的分配尽可能的均匀；分区的分配尽可能和上次分配保持相同。
当两者发生冲突时，第一个目标优先于第二个目标。鉴于这两个目标，StickyAssignor分配策略的具体实现要比RangeAssignor和RoundRobinAssi gn or这两种分配策略要复杂得多。
执行Rebalance以及管理consumer的group：Kafka提供了一个角色：coordinator来执行对于consumer group的管理，Kafka提供了一个角色：coordinator来执行对于consumer group的管理，当consumer group的第一个consumer启动的时候，它会去和kafkaserver确定谁是它们组的coordinator。之后该group内的所有成员都会和该coordinator进行协调通信。
确定coordinator：消费者向kafka集群中的任意一个broker发送一个GroupCoordinatorRequest请求，服务端会返回一个负载最小的broker节点的id，并将该broker设置为coordinator。
JoinGroup的过程：在rebalance之前，需要保证coordinator是已经确定好了的，整个rebalance的过程分为两个步骤，Join和Sync。join:表示加入到consumer group中，在这一步中，所有的成员都会向coordinator发送joinGroup的请求。一旦所有成员都发送了joinGroup请求，那么coordinator会选择一个consumer担任leader角色，并把组成员信息和订阅信息发送消费者leader选举算法比较简单，如果消费组内没有leader，那么第一个加入消费组的消费者就是消费者leader，如果这个时候leader消费者退出了消费组，那么重新选举一个leader，这个选举很随意，类似于随机算法。
Synchronizing Group State阶段：完成分区分配之后，就进入了SynchronizingGroup State阶段，主要逻辑是向GroupCoordinator发送SyncGroupRequest请求，并且处理SyncGroupResponse响应，简单来说，就是leader将消费者对应的partition分配方案同步给consumer group中的所有consumer。每个消费者都会向coordinator发送syncgroup请求，不过只有leader节点会发送分配方案，其他消费者只是打打酱油而已。当leader把方案发给coordinator以后，coordinator会把结果设置到SyncGroupResponse中。这样所有成员都知道自己应该消费哪个分区。consumer group的分区分配方案是在客户端执行的！Kafka将这个权利下放给客户端主要是因为这样做可以有更好的灵活性。
ISR：
ISR表示目前“可用且消息量与leader相差不多的副本集合，这是整个副本集合的一个子集”。对于可用和相差不多这两个词具体来说，ISR集合中的副本必须满足两个条件：
1、副本所在节点必须维持着与zookeeper的连接；
2、副本最后一条消息的offset与leader副本的最后一条消息的offset之间的差值不能超过指定的阈值；(replica.lag.time.max.ms)replica.lag.time.max.ms：如果该follower在此时间间隔内一直没有追上过leader的所有消息，则该follower就会被剔除isr列表；
3、ISR数据保存在Zookeeper的/brokers/topics/<topic>/partitions/<partitionId>/state。
节点中follower副本把leader副本LEO之前的日志全部同步完成时，则认为follower副本已经追赶上了leader副本，这个时候会更新这个副本的lastCaughtUpTimeMs标识，kafk副本管理器会启动一个副本过期检查的定时任务，这个任务会定期检查当前时间与副本的lastCaughtUpTimeMs的差值是否大于参数replica.lag.time.max.ms的值，如果大于，则会把这个副本踢出ISR集合。
硬件要求
本身对硬件没有要求，如果关注性能，就需要考虑几个会影响整体性能的因素：磁盘吞吐量，容量，内存，网络和CPU。确定了性能点，就可以在预算范围内选择最优化的硬件配置。
二、恢复策略设计模块
恢复策略设计模块的设计是指满足初始化模块中的条件下，在分布式集群中出现的某个Partition的所有Replica都宕机了的情况下采取的策略，本方法中使用副本集合中的ISR设计恢复策略，其中ISR表示目前“可用且消息量与leader相差不多的副本集合，这是整个副本集合的一个子集”。
在恢复策略中，主要依靠副本恢复数据，副本中需要使用到分区的副本机制、副本的leader选举、副本协同机制、副本数据同步原理。
分区的副本机制，Kafka的每个topic都可以分为多个Partition，并且多个partition会均匀分布在集群的各个节点下。虽然这种方式能够有效的对数据进行分片，但是对于每个partition来说，都是单点的，当其中一个partition不可用的时候，那么这部分消息就没办法消费。
所以kafka为了提高partition的可靠性而提供了副本的概念(Replica)，通过副本机制来实现冗余备份。每个分区可以有多个副本，并且在副本集合中会存在一个leader的副本，所有的读写请求都是由leader副本来进行处理。剩余的其他副本都做为follower副本，follower副本会从leader副本同步消息日志。
这个有点类似zookeeper中leader和follower的概念，但是具体的时间方式还是有比较大的差异。
所以我们可以认为，副本集会存在一主多从的关系。一般情况下，同一个分区的多个副本会被均匀分配到集群中的不同broker上，当leader副本所在的broker出现故障后，可以重新选举新的leader副本继续对外提供服务。通过这样的副本机制来提高kafka集群的可用性。
副本的leader选举：
1、KafkaController会监听ZooKeeper的/brokers/ids节点路径，一旦发现有broker挂了，执行下面的逻辑。这里暂时先不考虑KafkaController所在broker挂了的情况，KafkaController挂了，各个broker会重新leader选举出新的KafkaController。
2、leader副本在该broker上的分区就要重新进行leader选举，目前的选举策略是：
a)优先从isr列表中选出第一个作为leader副本，这个叫优先副本，理想情况下有限副本就是该分区的leader副本。
b)如果isr列表为空，则查看该topic的unclean.leader.election.enable配置。
unclean.leader.election.enable：为true则代表允许选用非isr列表的副本作为leader，那么此时就意味着数据可能丢失，为false的话，则表示不允许，直接抛出NoReplicaOnlineException异常，造成leader副本选举失败。
c)如果上述配置为true，则从其他副本中选出一个作为leader副本，并且isr列表只包含该leader副本。一旦选举成功，则将选举后的leader和isr和其他副本信息写入到该分区的对应的zk路径上。
副本协同机制：消息的读写操作都只会由leader节点来接收和处理。follower副本只负责同步数据以及当leader副本所在的broker挂了以后，会从follower副本中选取新的leader。
写请求首先由Leader副本处理，之后follower副本会从leader上拉取写入的消息，这个过程会有一定的延迟，导致follower副本中保存的消息略少于leader副本，但是只要没有超出阈值都可以容忍。
但是如果一个follower副本出现异常，比如宕机、网络断开等原因长时间没有同步到消息，那这个时候，leader就会把它踢出去。kafka通过ISR集合来维护一个分区副本信息，一个新leader被选举并被接受客户端的消息成功写入。Kafka确保从同步副本列表中选举一个副本为leader；leader负责维护和跟踪ISR(in-Sync replicas，副本同步队列)中所有follower滞后的状态。当producer发送一条消息到broker后，leader写入消息并复制到所有follower。消息提交之后才被成功复制到所有的同步副本。
副本数据同步原理，它解决了两个问题：
1、怎么传播消息；
2、在向消息发送端返回ack之前需要保证多少个Replica已经接收到这个消息。
Producer在发布消息到某个Partition时，先通过ZooKeeper找到该Partition的Leader get/brokers/topics/<topic>/partitions/2/state，然后无论该Topic的Replication Factor为多少(也即该Partition有多少个Replica)，Producer只将该消息发送到该Partition的Leader。Leader会将该消息写入其本地Log。每个Follower都从Leaderpull数据。这种方式上，Follower存储的数据顺序与Leader保持一致。Follower在收到该消息并写入其Log后，向Leader发送ACK。一旦Leader收到了ISR中的所有Replica的ACK，该消息就被认为已经commit了，Leader将增加HW(HighWatermark)并且向Producer发送ACK。随着follower副本不断和leader副本进行数据同步，follower副本的LEO会主键后移并且追赶到leader副本，这个追赶上的判断标准是当前副本的LEO是否大于或者等于leader副本的HW，这个追赶上也会使得被踢出的follower副本重新加入到ISR集合中。
根据以上的说明，某个Partition的所有Replica都宕机了，选择等待ISR中的任一个Replica“活”过来，并且选它作为Leader的策略。
三、分布式集群应用模块：
分布式集群应用模块是在初始化模块和恢复策略设计模块完成后，某个Partition的所有Replica都宕机了的情况，使用该设计模块实现数据的恢复。
本部分以所在地产行业通过使用数据实时动态更新的方法为具体实施例。
在某地产数据实施案例中，通过业务调研，识别出客户数据信息，部分数据如下表所示：
在得到客户数据表后，根据本发明的方法，主要实施步骤如图3所示。
一、环境初始化模块
环境初始化模块是分布式集群搭建需满足的基本条件，主要是指kafka的生产、消费消息的应用场景、架构、分发和消费原理、ISR、硬件要求。
硬件是：
四台虚拟机，系统是linux，8g,500g
Kafka集群信息：
192.168.0.112；
192.168.0.104；
192.168.0.106；
zk连接信息：
192.168.0.114：2181模式是单机：Mode:standalone
二、恢复策略设计模块
恢复策略设计模块的设计是指满足初始化模块中的条件下，在分布式集群中出现的某个Partition的所有Replica都宕机了的情况下采取的策略，本方法中使用副本集合中的ISR设计恢复策略，其中ISR表示目前“可用且消息量与leader相差不多的副本集合，这是整个副本集合的一个子集”。
三、分布式集群应用模块
分布式集群应用模块是在初始化模块和恢复策略设计模块完成后，某个Partition的所有Replica都宕机了的情况，使用该设计模块实现数据的恢复。
在模块一上的环境，在分布式kafka集群中，当一个Partition的所有Replica都宕机了的情况下采取等待ISR中的任一个Replica“活”过来，并且选它作为Leader的策略，客户数据信息可以恢复。
没有一个中间件能够做到百分之百的完全可靠，可靠性更多的还是基于几个9的衡量指标，比如4个9、5个9.软件系统的可靠性只能够无限去接近100％，但不可能达到100％。在有限的条件下尽可能减少数据的丢失。
采用了本发明的大数据环境下实现分布式中间件消息恢复策略管理的系统，通过模拟成为主从设备的方式，监听源库的日志来获取数据，获取到执行的每一个增删改的脚本、修改前和修改后的数据来实现数据及时同步变更。
在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。
Claims (9)
1.一种大数据环境下实现分布式中间件消息恢复策略管理的系统，其特征在于，所述的系统包括：
环境初始化模块，用于满足分布式集群搭建的基本条件；
恢复策略设计模块，与所述的环境初始化模块相连接，用于使用副本集合中的ISR设计恢复策略，通过副本恢复数据；
分布式集群应用模块，与所述的恢复策略设计模块相连接，用于在宕机的情况下恢复数据。
2.根据权利要求1所述的大数据环境下实现分布式中间件消息恢复策略管理的系统，其特征在于，所述的环境初始化模块的基本条件包含kafka的生产、消费消息的应用场景、架构、分发和消费原理、ISR和硬件要求。
3.根据权利要求2所述的大数据环境下实现分布式中间件消息恢复策略管理的系统，其特征在于，所述的消费消息的应用场景为行为跟踪和日志收集。
4.根据权利要求2所述的大数据环境下实现分布式中间件消息恢复策略管理的系统，其特征在于，所述的架构包含若干Producer、若干Broker、若干Consumer Group和zookeeper集群，所述的若干Broker相互连接且协同工作，所述的Producer、Broker和Consumer Group通过zookeeper管理协调请求和转发，所述的Producer通过push模式发布消息至broker，所述的Consumer Group通过监听使用pull模式从broker订阅并消费消息。
5.根据权利要求2所述的大数据环境下实现分布式中间件消息恢复策略管理的系统，其特征在于，所述的系统中包含topic消息集合，每个topic消息集合包含多个分区，分区策略分别为默认策略、轮询策略和粘性策略。
6.根据权利要求1所述的大数据环境下实现分布式中间件消息恢复策略管理的系统，其特征在于，所述的副本的策略包含分区的副本机制策略、副本的leader选举策略、副本协同机制策略和副本数据同步原理策略。
7.根据权利要求1所述的大数据环境下实现分布式中间件消息恢复策略管理的系统，其特征在于，所述的分区的副本机制策略中包含主副本和多个从副本，从副本从主副本同步消息日志，所述的主副本和从副本均匀分配到集群中的不同broker上，在主副本的broker出现故障的情况下，重新选举新的主副本继续对外提供服务。
8.根据权利要求1所述的大数据环境下实现分布式中间件消息恢复策略管理的系统，其特征在于，所述的副本的leader选举策略在broker失效的情况下，各个broker重新主副本选举得到新的KafkaController。
9.根据权利要求1所述的大数据环境下实现分布式中间件消息恢复策略管理的系统，其特征在于，所述的副本协同机制策略为由主副本的节点接收和处理消息的读写操作，从副本进行同步数据，在主副本所在的broker失效的情况下，在从副本中选取新的主副本。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010825880.1A CN111913837A (zh) | 2020-08-17 | 2020-08-17 | 大数据环境下实现分布式中间件消息恢复策略管理的系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010825880.1A CN111913837A (zh) | 2020-08-17 | 2020-08-17 | 大数据环境下实现分布式中间件消息恢复策略管理的系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111913837A true CN111913837A (zh) | 2020-11-10 |
Family
ID=73279626
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010825880.1A Pending CN111913837A (zh) | 2020-08-17 | 2020-08-17 | 大数据环境下实现分布式中间件消息恢复策略管理的系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111913837A (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112328404A (zh) * | 2020-11-26 | 2021-02-05 | 北京百度网讯科技有限公司 | 负载均衡方法及装置、电子设备、计算机可读介质 |
| CN112559913A (zh) * | 2020-12-11 | 2021-03-26 | 车智互联（北京）科技有限公司 | 一种数据处理方法、装置、计算设备及可读存储介质 |
| CN112822260A (zh) * | 2020-12-31 | 2021-05-18 | 北京天融信网络安全技术有限公司 | 文件传输方法及装置、电子设备、存储介质 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107666516A (zh) * | 2017-09-20 | 2018-02-06 | 重庆邮电大学 | 一种基于消息热度保证kafka集群数据一致性的方法 |
| US20180091586A1 (en) * | 2016-09-26 | 2018-03-29 | Linkedin Corporation | Self-healing a message brokering cluster |
-
2020
- 2020-08-17 CN CN202010825880.1A patent/CN111913837A/zh active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180091586A1 (en) * | 2016-09-26 | 2018-03-29 | Linkedin Corporation | Self-healing a message brokering cluster |
| CN107666516A (zh) * | 2017-09-20 | 2018-02-06 | 重庆邮电大学 | 一种基于消息热度保证kafka集群数据一致性的方法 |
Non-Patent Citations (1)
| Title |
|---|
| 郭宗怀: "Kafka消息系统可靠性研究", 中国优秀硕士学位论文全文数据库信息科技辑, pages 1 - 23 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112328404A (zh) * | 2020-11-26 | 2021-02-05 | 北京百度网讯科技有限公司 | 负载均衡方法及装置、电子设备、计算机可读介质 |
| CN112328404B (zh) * | 2020-11-26 | 2023-08-08 | 北京百度网讯科技有限公司 | 负载均衡方法及装置、电子设备、计算机可读介质 |
| CN112559913A (zh) * | 2020-12-11 | 2021-03-26 | 车智互联（北京）科技有限公司 | 一种数据处理方法、装置、计算设备及可读存储介质 |
| CN112559913B (zh) * | 2020-12-11 | 2023-10-20 | 车智互联（北京）科技有限公司 | 一种数据处理方法、装置、计算设备及可读存储介质 |
| CN112822260A (zh) * | 2020-12-31 | 2021-05-18 | 北京天融信网络安全技术有限公司 | 文件传输方法及装置、电子设备、存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20220239602A1 (en) | Scalable leadership election in a multi-processing computing environment | |
| WO2019154394A1 (zh) | 分布式数据库集群系统、数据同步方法及存储介质 | |
| US9460185B2 (en) | Storage device selection for database partition replicas | |
| CN106953901A (zh) | 一种提高消息传递性能的集群通信系统及其方法 | |
| CN111913837A (zh) | 大数据环境下实现分布式中间件消息恢复策略管理的系统 | |
| US7076553B2 (en) | Method and apparatus for real-time parallel delivery of segments of a large payload file | |
| JP6225262B2 (ja) | 分散データグリッドにおいてデータを同期させるためにパーティションレベルジャーナリングをサポートするためのシステムおよび方法 | |
| US10127077B2 (en) | Event distribution pattern for use with a distributed data grid | |
| CA2596719A1 (en) | Method and apparatus for distributed data management in a switching network | |
| CN113722127A (zh) | 高效轻量易用的分布式网络消息中间件 | |
| CN109639773A (zh) | 一种动态构建的分布式数据集群控制系统及其方法 | |
| WO2017181430A1 (zh) | 分布式系统的数据库复制方法及装置 | |
| CN115292414A (zh) | 一种业务数据同步到数仓的方法 | |
| CN107566341B (zh) | 一种基于联邦分布式文件存储系统的数据持久化存储方法及系统 | |
| CN117056303A (zh) | 适用于军事行动大数据的数据存储方法及装置 | |
| Choudhary et al. | A real-time fault tolerant and scalable recommender system design based on Kafka | |
| US8230444B2 (en) | Global attribute uniqueness (GAU) using an ordered message service (OMS) | |
| Lin et al. | An optimized multi-Paxos protocol with centralized failover mechanism for cloud storage applications | |
| Wang et al. | Naxos: A named data networking consensus protocol | |
| Mat Deris et al. | Managing data using neighbour replication on a triangular-grid structure | |
| US20240223510A1 (en) | Scalable leadership election in a multi-processing computing environment | |
| CN115550458A (zh) | 一种日志处理方法和相关装置 | |
| CN117667447A (zh) | 一种多日志高并发消息队列处理方法及系统 | |
| Wang et al. | School of Computer Science and Engineering, Key Laboratory of Computer Network and Information Integration, Ministry of Education, Southeast University, Nanjing, China ywang_cse@ seu. edu. cn | |
| Gupta et al. | On the fly file dereplication mechanism |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |