1. 关于DataX
1.1. 前言
为什么写这篇文章，因为初出茅庐的时候，曾经遇到的一个面试官就是DataX的作者之一，而当时我还偏偏因为业务需求做了个数据库的同步工具，我当时不知道他做过这么专业的同步工具，被虐的老惨了，他面试的其中一个问题就是，如果要你去推销一款数据库同步工具，你该怎么推销？
相信没有深入了解过这个领域的可能说不出一两点优势来，而我当时做的工具，也就重在实现功能上了，唯一的优点我觉得就是还算通用，因为也是通过配置json文件设置对应表间的关系来实现不同数据库之间的数据同步
1.2. DataX的优势
所以现在在来谈谈数据同步工具该怎么推销，那不就是把数据同步工具可完善，可扩展的部分尽可能的讲一遍吗
- 首先是工具本身方面，我们需要DataX在传输性能上有保证，它采用的任务架构可以保证在单机多线程上速度随并发线性增长
- 那么如何保证传输过快，导致数据接收方崩掉呢，所以DataX提供了精准的速度控制模式，可以随意调整作业速度，保证达到最高效的同步速度
- 数据同步还需要什么？多了，不同的数据库可能字段类型需要一定转换，根据需要对数据可能需要进行特定的过滤，脱敏，补全操作，最好还可以用户自定义操作，这些DataX也提供了
- 同步的时候我们需要关注什么？对了，最好还有同步的进度，速度，错误情况，传输流量，cpu状况等等的可视化监控
- 对开发者而言，我们需要什么？我们需要的是配置简单，操作容易，依赖少，这也是DataX的特点
- 上述这些都是在正常情况下的操作，我们需要应对异常情况，比如网络波动，甚至宕机，所以我们需要DataX具有健壮的容错机制，对于这个，它提供了丰富的重试策略，和Task级别的重新调度（一个Job任务它会分成多个Task）
- 好了，你们还能想出同步工具需要支持的额外需求吗？
这里给出DataX的官方Github地址，我并没有在推广这个工具哦，如果你们的系统用了大量阿里云提供的服务比如odps，ads，那它倒是天然适配了，用它正合适，不过如果是mysql到mysql的同步就不一定要用这个了，业界流行的似乎是
canal也是阿里的，至于这两个哪个快，我没有测过，感兴趣的可以自行尝试