基于大数据备份迁移速率和性能优化的解决方案.docx

《基于大数据备份迁移速率和性能优化的解决方案.docx》由会员分享，可在线阅读，更多相关《基于大数据备份迁移速率和性能优化的解决方案.docx（6页珍藏版）》请在第一文库网上搜索。

1、基于大数据备份迁移速率和性能优化的解决方案1：针对行业及背景1.1 :行业涉及到数据的诸多行业之中。1.2 ：背景大数据又称巨量资料,指的是所涉及的资料量规模巨大到无法透过目前主流软件工具,在合理时间内达到撷取、管理、处理、并整理成为帮助企业经营决策更积极目的的资讯。从某种程度上说，大数据是数据分析的前沿技术。简言之，从各种各样类型的数据中，快速获得有价值信息的能力，就是大数据技术。大数据区分于传统数据最显著的特征，面向海量的数据，处理数据的效率和捕获速度至关重要。为了满足市场的需求我参与到DataOne数据融合系统的核心研发中。2：所属项目简介2.1 :项目名称DataOne数据融合系统2.

2、2 ：项目描述主要实现数据的迁移。包括数据库到数据库，以及服务器的文件到服务器的迁移，实现数据的备份或者数据库数据迁移到国产化数据库等等。为了能够实现一对多（一个数据源多个目的端）高效快速的完成数据迁移。系统的性能是整个系统的核心问题。3：性能优化方案设计3.1 ：系统整体架构SINKS3.2 ：主流技术框架SpringBootSpringCIoudRedis消息中间件kafkaZk等等3.3 ：设计方案介绍此方案设计采用SPrmgBOOt进行功能开发。系统整体分为数据中台后台两个模块。数据中台：提供用户的操作界面，动态展现数据流转过程，任务的进度，清洗规则以及任务错误队列数据源配置任务创建等

3、信息，不参与数据的抽取和写入。数据后台：提供数据的抓去和目的端的写入工作。因为数据源需要迁移的数据量庞大，用户又要快速的完成数据迁移，以免对生产环境或者后续数据需求造成影响，所以系统的性能设计成为了核心。最终经过研究采用消息对列kafka+线程池的方式实现性能提升。3.3.1 ：设计的方案概述因为数据的海量数据要么表个数居多，要么表中的数据量庞大。如果现在创建一个数据库Orac1e到国产化数据DM的全量数据迁移任务，那么在数据后台就会将源端的数据中的表放入到一个队列中，在数据抓取层开启数据抓取任务的线程并将任务交于线程池进行管理，抓取层的任务开启是从队列中获取源端数据库表信息，读取这张表的数据

4、，分批次的获取并且以表的信息创建Topic并且发送数据到kafka上，同时数据写入层作为消费者动态的监听指定的Topic上是否有发送到的数据并开启写入数据任务及时进行消费，批量的进行数据在目的端的写入工作。这样实现了真正意义上的读写分离，逻辑分离任务分离。3.3.2 ：技术选型的对比一：消息中间件对比要实现读写分离就必须引入消息中间件，市面上的消息中间件居多，分析每个的优劣。MQ的优点1、异步：提升系统的响应速度，吞吐量。2、解耦：服务之间进行解耦，才可以减少服务之间的影响，提高系统整体的稳定性以及可扩展性。另外解耦后可以实现数据分发。生产者发送一个消息后，可以由一个或者多个消费者进行消费，并

5、且消费者的增加或者减少对生产者没有影响O3、削峰：以稳定的系统资源应对突发的流量冲击。MQ的缺点1、系统可用性降低：系统引入的外部依赖增多，系统的稳定性就会变差。一旦MQ宕机，就会对业务产生影响。（需要考虑如何保证MQ的高可用）2、系统的复杂度提高：引入MQ后系统的复杂度会大大提高。以前服务之间可以进行同步的服务调用，引入MQ后，会变成异步调用，数据链路会变得更复杂。并且还会带来一系列的问题。（如何保证消息不会丢失？不会被重复调用？怎么保证消息的顺序性？）3、消息一致性问题：A系统处理完业务，通过MQ发送消息给B、C系统进行后续的业务处理。如果B系统成功，C系统失败，这就需要考虑消息的一致性。

6、Kafka号称大数据的杀手铜，谈到大数据领域内的消息传输，则绕不开Kafka,这款为大数据而生的消息中间件，以其百万级TPS的吞吐量名声大噪，迅速成为大数据领域的宠儿,在数据采集、传输、存储的过程中发挥着举足轻重的作用。ApacheKafka它最初由1inked1n公司基于独特的设计实现为一个分布式的提交日志系统（adistributedcommit1og）,之后成为APaChe项目的部分。目前已经被1inked1n,Uber,Twitter,Netf1ix等大公司所采纳。1优点性能卓越，单机写入TPS约在百万条/秒，最大的优点，就是吞吐量高。时效性：ms级可用性：非常高，kafka是分布式的

7、，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用消费者采用PU11方式获取消息，消息有序，通过控制能够保证所有消息被消费且仅被消费一次；有优秀的第三方KafkaWeb管理界面Kafka-Manager;在日志领域比较成熟，被多家公司和多个开源项目使用；功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用。2.缺点Kafka单机超过64个队列/分区，1oad会发生明显的飙高现象，队列越多，1oad越高，发送消息响应时间变长1. 使用短轮询方式，实时性取决于轮询间隔时间；2. 消费失败不支持重试；3. 支持消息顺序，但是一台代理宕机后，就会产

8、生消息乱序；4. 社区更新较慢；综合MQ和Kafka的优劣点我的迁移系统更注重的就是吞吐量高,与此同时kafka一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用；消费者采用PU11方式获取消息，消息有序，通过控制能够保证所有消息被消费且仅被消费一次。所以系统采用了kafka作为数据的中间件。二：多线程(线程池)设计在java中，如果每个请求到达就创建一个新线程，开销是相当大的。在实际使用中，服务器在创建和销毁线程上花费的时间和消耗的系统资源都相当大,甚至可能要比在处理实际的用户请求的时间和资源要多的多。除了创建和销毁线程的开销之外，活动的线程也需要消耗系统资源。如果在一个jvm里创

9、建太多的线程，可能会使系统由于过度消耗内存或“切换过度”而导致系统资源不足。为了防止资源不足，服务器应用程序需要采取一些办法来限制任何给定时刻处理的请求数目，尽可能减少创建和销毁线程的次数，特别是一些资源耗费比较大的线程的创建和销毁，尽量利用已有对象来进行服务，这就是“池化资源”技术产生的原因。线程池主要用来解决线程生命周期开销问题和资源不足问题。通过对多个任务重或使用线程,线程创建的开销就被分摊到了多个任务上了，而且由于在请求到达时线程己经存在，所以消除了线程创建所带来的延迟。这样，就可以立即为请求服务，使用应用程序响应更快。另外，通过适当的调整线程中的线程数目可以防止出现资源不足的情况。设

10、计中使用线程池的参数设计如下：参数默认值：CorePooISize=IqueueCapacity=Integer.MAX_VA1UEmaxPoo1Size=1nteger.MAX_VA1UEkeepA1iveTime=60sa11owCoreThreadTimeout=fa1serejectedExecutionHand1er=AbortPo1icy()如何来设置需要根据几个值来决定tasks：每秒的任务数，假设为Ioo1000taskcost：每个任务花费时间，假设为0.1Sresponsetime：系统允许容忍的最大响应时间，假设为IS做几个计算CorePooISize=每秒需要多少个线程

11、处理？threadcount=tasks(1taskcost)=tasks*taskcout=(1001000)*0.1=10100个线程。CorePooISize设置应该大于10根据8020原则，如果80%的每秒任务数小于200,那么coreP。ISiZe设置为20即可queueCapacity=(coreSizePoo1taskcost)*responsetime计算可得queuecapacity=20/0.1*1=200意思是队列里的线程可以等待1s,超过了的需要新开线程来执行切记不能设置为Integer.MAX_VA1UE,这样队列会很大，线程数只会保持在CorePo。ISiZe大小，

12、当任务陡增时，不能新开线程来执行，响应时间会随之陡增。maxPoo1Size=(max(tasks)-queueCapacity)(1taskcost)计算可得maxPoo1Size=(1000-200)/10=80(最大任务数队列容量)/每个线程每秒处理能力=最大线程数rejectedExecutionHand1er：根据具体情况来决定，任务不重要可丢弃，任务重要则要利用一些缓冲机制来处理ReepAIiveTime和a11owCoreThreadTimeout采用默认通常能满足以上关于线程数量的计算并没有考虑CPU的情况。若结合CPU的情况，比如，当线程数量达到60时，CPU达到100%,则将maxP。ISiZe设置为80也不合适，此时若系统负载长时间维持在每秒1000个任务，则超出线程池处理能力，应设法降低每个任务的处理时间(taskcost)04：优化方案后性能对比以及客户认可4.1 ：优化后性能提升系统由原来的不适用消息中间件和不适用线程池的架构改变为kafka+线程池的架构之后相比原来速率提升了十几倍之多，每秒可以成功迁移2000条数据左右。4.2 ：优化后客户反馈1：大幅度的性能提升得到了客户的高度认可和赞扬，成功快速帮助用户是现实数据库迁移国产化。2：后续成功拿下上海市委组织部信息中心等诸多政府单位的数据业务项目。