Data JellyFish 译文（数据水母）数据调度中心

#现状

1. 对内，微服务环境下，内部系统众多，系统之间的数据流转就是一个绕不开的话题。我有见过：

   1. 有使用http推送的，不管网络死活
   2. 有使用Redis做同步的，承受着本不该她承受的痛
   3. 有使用RabbitMQ等专业做消息中间件的，但是我们用好了吗，发送和消费时的消息确认，幂等性做了吗？重试策略，处理失败是扔回队列还是等会再试，等多久？试几次？。队列中数据不能消费的处理方式？队列满了的处理方式？，队列的持久化策略？。你说你把数据推给我了，可是我又没有收到，那你有证据吗（开始扯皮）trace.log打开了吗？
   4. 有使用定时任务的，定时跑，一直跑，每天零晨就是各种定时任务起来活跃的时候
   5. 我有见过使用datax等重量级产品的，小公司是想玩但受限于成本

2. 对外，互联网时代，只要不是信息孤岛都会和外部打交道的，系统之间打交道，也必然离不开数据的交互。准确性，实时性 是与第三方数据交互的基础。 也体现着两个团队之间的能力，这能力可能不会体现在嗯『数据过来了，没问题，上线』，而是会体现在 『握草 什么垃圾公司，我的数据呢！你说你给我了，你有证据吗，我又没收到！我草又丢数据了？这么垃圾。我之前接收姿势不对，重新给我推一下，什么？找不回来了？垃圾！』（话外音：程序员之间的爱恨情仇）

与三方系统打通的N种进阶方式

https://xie.infoq.cn/article/f813f9373d094965bb32ed2d4

文档地址(安装部署指南)

https://www.yuque.com/alenfive/data-jelly-fish

用途

1. 与第三方的数据同步
2. 内部系统之间的数据同步

特性

1. 数据传输可靠率达99.99999%
2. 实时性高，相比定时任务每5分钟，半天，一天，而言，在秒级实现同步
3. 对接成本低，增量同步时提供一个增量查询接口，全量同步时提供一个全量查询接口
4. 无中心化的分布式任务，实现任务分片能力，多机部署，达到并发处理，实现快速调度的目的
5. 每一条数据都有同步的成功或失败记录，历史可查
6. 自定义重试策略，固定时长，指数级重试
7. 完善的监控信息，有多少同步了，有多少未同步，

原理

以系统A同步数据到系统B为例，A系统提供一个http接口，实现数据增量或全量的抓取，”Data JellyFish 数据高度中心“ 简称 "DJ" DJ 启动生产者任务线 程T1调用A系统的http接口，将数据存储在自己的中间表中，同时，DJ启动消费者任务线程T2调用B系统提供的另一个接受数据的HTTP接口，来完成数据调度

架构图

传统数据同步方案比较

1. RCP, http协议直接访问第三方，内存中重试三次后，消息丢失
2. 定时任务数据同步，延迟高，无分片并发能力
3. MQ,Kafka等，研发对接（保证数据准确传输的）成本高，无流水记录，无法直接回塑
4. 每次数据对接都需要重复开发，不具备可用性

总结

1. 该项目没有技术上的难点
2. 但能解决是中小型团队数据同步的 准确性，实时性，简单性 三方面的痛点

Data Jelly Fish (数据调度中心)

演示地址： http://39.98.181.90:8082/view/admin 用户&密码：admin/admin

样例图

问题反馈

微信号: freedom-Union
邮件交流： kobe96688@126.com
报告issue: https://gitee.com/alenfive/data-jelly-fish/issues