业务数据迁移上云的一些技术思考

在支持京东集团内部及京东云外部客户的业务迁移到京东公有云及京东私有云、京东政务云的过程中,京东科技-京东云事业群-技术服务组积累了相关业务系统数据迁移的一些管理和技术经验,以案例的形式分享给大家,希望对大家的业务迁移工作有所帮助。 迁移前的准备工作 业务迁移上云涉及到的业务数据种类繁多,主要类型包括: 数据库:关系型数据库 MySQL 、PG、Oracle等 对象存储:标准S3接口对象存储迁移 中间件数据:ES、mongoDB、redis等 文件存储:文档、图片等非结构化数据 大数据:HBASE、HDFS files等 京东云的内外部客户在上云过程中,大部分业务均涉及到以上多种数据类型,基于相关迁移的案例所积累的经验,数据迁移需要在迁移启动前至少做好如下准备工作: 可执行的数据迁移技术方案制定完成,包含明确的迁移操作步骤(迁移前准备工作,迁移操作、迁移后校验工作)、执行人、确认人。 制定迁移应急预案及回切方案,明确责任矩阵,确认异常情况的决策条件及决策人。 确认数据安全等级,确认数据迁移的方案合规安全,通过相关业务安全部门审核。 迁移时长及割接数据同步窗口的评估(以POC验证数据信息为基础制定),确认各个业务及数据迁移可选的第二方案。 确认网络带宽及质量满足迁移需求,网络中断可能造成的影响的评估。 6、需要考虑源端和目标端的资源及服务差别。同样的规格和服务,服务能力和特性可能不一样。 下面是几个案例,涉及到了不同数据迁移的场景。 一、关系型数据库

Read more

Redis 发布订阅

假设我们有这么一个业务场景,在网站下单支付以后,需要通知库存服务进行发货处理。 上面业务实现不难,我们只要让库存服务提供给相关的给口,下单支付之后只要调用库存服务即可。 后面如果又有新的业务,比如说积分服务,他需要获取下单支付的结果,然后增加用户的积分。 这个实现也不难,让积分服务同样提供一个接口,下单支付之后只要调用库存服务即可。 如果就两个业务需要获取下单支付的结果,那也还好,程序改造也快。可是随着业务不断的发展,越来越多的新业务说是要下单支付的结果。 这时我们会发现上面这样的系统架构存在很多问题: 第一,下单支付业务与其他业务重度耦合,每当有个新业务需要支付结果,就需要改动下单支付的业务。 第二,如果调用业务过多,会导致下单支付接口响应时间变长。另外,如果有任一下游接口响应变慢,就会同步导致下单支付接口响应也变长。 第三,如果任一下游接口失败,可能导致数据不一致的情况。比如说下图,先调用 A,成功之后再调用 B,最后再调用 C。 如果在调用 B 接口的发生异常,此时可能就导致下单支付接口返回失败,但是此时 A 接口其实已经调用成功,这就代表它内部已经处理下单支付成功的结果。 这样就会导致 A,B,C 三个下游接口,A

Read more

kafka

https://www.cnblogs.com/qingyunzong/p/9007107.html 1.1 概述 Kafka是最初由Linkedin公司开发,是一个分布式、分区的、多副本的、多订阅者,基于zookeeper协调的分布式日志系统(也可以当做MQ系统),常见可以用于web/nginx日志、访问日志,消息服务等等,Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 主要应用场景是:日志收集系统和消息系统。 Kafka主要设计目标如下: 以时间复杂度为O(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证常数时间的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。 支持Kafka Server间的消息分区,及分布式消费,同时保证每个partition内的消息顺序传输。 同时支持离线数据处理和实时数据处理。 Scale out:支持在线水平扩展 1.2 消息系统介绍 一个消息系统负责将数据从一个应用传递到另外一个应用,应用只需关注于数据,无需关注数据在两个或多个应用间是如何传递的。分布式消息传递基于可靠的消息队列,在客户端应用和消息系统之间异步传递消息。有两种主要的消息传递模式:点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。Kafka就是一种发布-订阅模式。 1.3 点对点消息传递模式 在点对点消息系统中,消息持久化到一个队列中。此时,将有一个或多个消费者消费队列中的数据。但是一条消息只能被消费一次。当一个消费者消费了队列中的某条数据之后,该条数据则从消息队列中删除。该模式即使有多个消费者同时消费数据,也能保证数据处理的顺序。这种架构描述示意图如下: 生产者发送一条消息到queue,只有一个消费者能收到。 1.4 发布-订阅消息传递模式 在发布-订阅消息系统中,消息被持久化到一个topic中。与点对点消息系统不同的是,消费者可以订阅一个或多个topic,消费者可以消费该topic中所有的数据,同一条数据可以被多个消费者消费,数据被消费后不会立马删除。在发布-订阅消息系统中,消息的生产者称为发布者,消费者称为订阅者。该模式的示例图如下: 发布者发送到topic的消息,只有订阅了topic的订阅者才会收到消息。

Read more

kafka跨集群同步 /zk的数据迁移

该方案解决Kafka跨集群同步、创建Kafka集群镜像等相关问题,主要使用Kafka内置的MirrorMaker工具实现。 Kafka镜像即已有Kafka集群的副本。下图展示如何使用MirrorMaker工具创建从源Kafka集群(source cluster)到目标Kafka集群(target cluster)的镜像。该工具通过Kafka consumer从源Kafka集群消费数据,然后通过一个内置的Kafka producer将数据重新推送到目标Kafka集群。 一、如何创建镜像 使用MirrorMaker创建镜像是比较简单的,搭建好目标Kafka集群后,只需要启动mirror-maker程序即可。其中,一个或多个consumer配置文件、一个producer配置文件是必须的,whitelist、blacklist是可选的。在consumer的配置中指定源Kafka集群的Zookeeper,在producer的配置中指定目标集群的Zookeeper(或者broker.list)。 例如,你需要创建S集群的镜像,目标集群T已经搭建好,简单的做法如下: 1. 创建consumer配置文件:sourceClusterConsumer.config 2. 创建producer配置文件:targetClusterProducer.config 3. 创建启动脚本:start.sh 4. 执行脚本 执行start.sh通过日志信息查看运行状况,到目标Kafka集群的log.dir中即可看到同步过来的数据。 二、MirrorMaker的参数说明 执行上面的命令就可以看到各个参数的说明:

Read more