otter

世界最遥远的距离，是我站在你对面，你却在另一台服务器里。 世界最温暖的举例，是我在internet的另一端，而你挑着一筐刚刨出来的数据来看我。 ——做产品的柏拉图 一个系统装再多数据，不与其他系统交互，那也是孤岛系统，孤独没女朋友。 一个系统若很外向，不断撩拨周围的系统，也乐意被撩拨，成为了众系统中的“交际花”，那么这货甚至就是中台的性质。 而更多的系统是介于上述两种极端之间的。像人一样，自己搞生产，也要参与社交——就是系统之间的数据对接。 对接的本质是为了实现数据信息的传输。 在后端产品的世界里，各子系统之间，或与外部系统之间的对接非常常见。 作为产品经理，不仅要知道数据从哪来，还要理清楚获取数据之后的握手方式、运算逻辑、异常规则、容错机制、数据日志等 等。 本文尝试聊聊如下话题： 数据传输的场景和意义 数据传输的方式 数据传输的处理机制 数据传输的注意事项 说明，因为编辑器的问题 一度缺少图片，若需看原文可以点击这里： ******系统间数据传输，产品经理视角的9千字总结：接口、otter、log4j、SFTP、MQ…… ****** 一、 数据传输的场景和意义 1、数据传输的应用场景 1）前端和后端本身无时不刻的数据互动。 2）公司的各个系统之间的信息共享。 比如，式系统部署之后，就需要各个系统模块之间进行数据的配合，比如订单系统的库存扣减数据要同步给备货系统进行采购。 3

本文是Netty系列笔记第2篇 Netty是网络应用框架，所以从最本质的角度来看，是对网络I/O模型的封装使用。 因此，要深刻理解Netty的高性能，也必须从网络I/O模型说起。 看完本文，可以回答这三个问题： 五种I/O模型是什么？核心区别在哪里？ 同步=阻塞？异步=非阻塞？ Netty的高性能，是采用了哪种I/O模型？ 1.掌握五种I/O模型的关键钥匙 Unix系统下的五种基本I/O模型大家应该都有所耳闻，分为： blocking I/O（同步阻塞IO,BIO） nonblocking I/O(同步非阻塞IO，NIO) I/O multiplexing (I/O多路复用) signal driven I/O（信号驱动I/O） asynchronous I/O（异步I/O，AIO） 每种I/O的特性如何，尤其是同步/非同步、阻塞/非阻塞的区别，其实很多人并不能准确地进行区分。 所以，我们先把最核心的“钥匙”告诉大家，带着这把“钥匙”再来看I/O模型的关键问题，就能手到擒来了。 当一次网络IO发生时，主要涉及到 三个对象 ： 发起此次IO操作的Process或者Application 系统内核kernel。用户进程无法直接操作I/O设备，必须通过系统内核kernel与I/O设备交互。 I/O设备，包括网络、磁盘等。本文主要针对网络。 真正的I/O过程，主要分为 两个阶段 ：

起源 在进行架构转型与分库分表之前，我们一直采用非常典型的单体应用架构：主服务是一个 Java WebApp，使用 Nginx 并选择 Session Sticky 分发策略做负载均衡和会话保持；背后是一个 MySQL 主实例，接了若干 Slave 做读写分离。在整个转型开始之前，我们就知道这会是一块难啃的硬骨头：我们要在全线业务飞速地扩张迭代的同时完成架构转型，因为这是实实在在的”给高速行驶的汽车换轮胎”。 为了最大限度地减少服务拆分与分库分表给业务带来的影响（不影响业务开发也是架构转型的前提），我们采用了一种温和的渐进式拆分方案： 对于每块需要拆分的领域，首先拆分出子服务，并将所有该领域的数据库操作封装为 RPC 接口； 将其它所有服务中对该领域数据表的操作替换为 RPC 调用； 拆分该领域的数据表，使用数据同步保证旧库中的表与新表数据一致； 将该子服务中的数据库操作逐步迁移到新表，分批上线； 全部迁移完成后，切断同步，该服务拆分结束。 这种方案能够做到平滑迁移，但其中却有几个棘手的问题： 旧表新表的数据一致性如何保证？ 如何支持异构迁移？（由于旧表的设计往往非常范式化，因此拆分后的新表会增加很多来自其它表的冗余列） 如何保证数据同步的实时性？（往往会先迁移读操作到新表，这时就要求旧表的写操作必须准实时地同步到新表） 典型的解决方案有两种： 双写(dual write) :

起源 在进行架构转型与分库分表之前，我们一直采用非常典型的单体应用架构：主服务是一个 Java WebApp，使用 Nginx 并选择 Session Sticky 分发策略做负载均衡和会话保持；背后是一个 MySQL 主实例，接了若干 Slave 做读写分离。在整个转型开始之前，我们就知道这会是一块难啃的硬骨头：我们要在全线业务飞速地扩张迭代的同时完成架构转型，因为这是实实在在的”给高速行驶的汽车换轮胎”。 为了最大限度地减少服务拆分与分库分表给业务带来的影响（不影响业务开发也是架构转型的前提），我们采用了一种温和的渐进式拆分方案： 对于每块需要拆分的领域，首先拆分出子服务，并将所有该领域的数据库操作封装为 RPC 接口； 将其它所有服务中对该领域数据表的操作替换为 RPC 调用； 拆分该领域的数据表，使用数据同步保证旧库中的表与新表数据一致； 将该子服务中的数据库操作逐步迁移到新表，分批上线； 全部迁移完成后，切断同步，该服务拆分结束。 这种方案能够做到平滑迁移，但其中却有几个棘手的问题： 旧表新表的数据一致性如何保证？ 如何支持异构迁移？（由于旧表的设计往往非常范式化，因此拆分后的新表会增加很多来自其它表的冗余列） 如何保证数据同步的实时性？（往往会先迁移读操作到新表，这时就要求旧表的写操作必须准实时地同步到新表） 典型的解决方案有两种： 双写(dual write) :

Mysql跨机房同步方案 原 尚浩宇 发布于 2016/05/19 17:01 字数 424 阅读 3298 收藏 20 点赞 2 评论 0 撸了今年阿里、网易和美团的面试，我有一个重要发现.......>>> 假设现有两个机房，需要做到数据同步。 以下是架构图（实际架构图根据现有机房架构和实际会比下图复杂，但整体思路不变）： Mycat、Canal、Otter是关键的三项技术： Mycat：数据库分库分表中间件，可以管理一个mysql集群，屏蔽了mysql集群，对外伪装成mysql server，用户无感知mysql集群。 Canal：阿里巴巴开源产品，可以读取mysql二进制日志文件，并解析成想要的数据。 Otter：阿里巴巴开源产品，配合Canal可以做到读取二进制文件，解析出增量数据sql，然后执行sql到指定连接。 流程： 1、用户插入一条数据到mycat 2、mycat解析sql，分配sql到指定mysql数据库 3、mysql（假设M1接收到数据）数据库接收数据，根据主从配置，写出二进制日志。 4、mysql（M2）读取二进制日志同步数据，mysql（S）读取二进制日志同步数据，并写出二进制日志 5、Canal读取二进制日志，解析成sql 6、Otter接到sql，获取连接，在机房B的mycat上执行sql 7、Otter收到sql执行回执，执行完毕。 注：

序 本文主要研究一下OtterController OtterController otter/node/etl/src/main/java/com/alibaba/otter/node/etl/OtterController.java public class OtterController implements NodeTaskListener, OtterControllerMBean { private static final Logger logger = LoggerFactory.getLogger(OtterController.class); // 第一层为pipelineId，第二层为S.E.T.L模块 private Map<Long, Map<StageType, GlobalTask>> controllers = OtterMigrateMap.makeComputingMap(new Function<Long, Map<StageType, GlobalTask>>() { public Map<StageType, GlobalTask> apply(Long pipelineId) { return new MapMaker().makeMap(); } }); private ConfigClientService

序 本文主要研究一下OtterLauncher OtterLauncher otter/node/deployer/src/main/java/com/alibaba/otter/node/deployer/OtterLauncher.java public class OtterLauncher { private static final Logger logger = LoggerFactory.getLogger(OtterLauncher.class); public static void main(String[] args) throws Throwable { // 启动dragoon client // startDragoon(); // logger.info("INFO ## the dragoon is start now ......"); final OtterController controller = OtterContextLocator.getOtterController(); controller.start(); try { logger.info("INFO ## the otter server is running now ......"); Runtime.getRuntime().addShutdownHook(new

基于1.1.5-alpha版本，具体源码笔记可以参考我的github：https://github.com/saigu/JavaKnowledgeGraph/tree/master/code_reading/canal 本文将对canal的启动模块deployer进行分析。 Deployer模块(绿色部分)在整个系统中的角色如下图所示，用来启动canal-server. 模块内的类如下： 为了能带着目的看源码，以几个问题开头，带着问题来一起探索deployer模块的源码。 CanalServer启动过程中配置如何加载？ CanalServer启动过程中涉及哪些组件？ 集群模式的canalServer，是如何实现instance的HA呢？ 每个canalServer又是怎么获取admin上的配置变更呢？ 1.入口类CanalLauncher 这个类是整个canal-server的入口类。负责配置加载和启动canal-server。 主流程如下： 加载canal.properties的配置内容 根据canal.admin.manager是否为空判断是否是admin控制,如果不是admin控制，就直接根据canal.properties的配置来了 如果是admin控制，使用PlainCanalConfigClient获取远程配置

AVIRIS 是指 机载可见光近红外成像光谱（Airborne Visible InfraRed Imaging Spectrometer）。是由美国NASA下属的喷气动力实验室（JPL）开发和维护的光谱成像设备。现有两代产品： AVIRIS-Classic 和 AVIRIS-NG （AVIRIS Next Generation），其中AVIRIS-Classict从1986年开始服役，目前网站上提供从1992年开始至2020年采集高光谱图像数据，主要为地面辐亮度图像，少部分图像提供反射率图像。AVIRIS-NG则提供从2012年至2020年的高光谱图像数据。所有的图像均进行了几何矫正，具有真实的地理坐标信息。目前AVIRIS-Classic提供的数据主要位于美国本土，还有少量太平洋中海岛、以及加拿大和欧洲地区的数据。AVIRIS-NG则目前主要提供欧洲和印度区域数据。 1. AVIRIS-Classic AVIRIS是地球遥感领域的先进设备。其具备一个独特的光学传感器，能够采集波长在400~2500nm范围内的上行的光谱辐亮度信息，并进行辐亮度矫正，最终生成具有224个连续光谱通道（波段）的高光谱图像。AVIRIS曾经搭载在4种不同的飞行平台上， 分别为：NASA 的ER-2 喷气式飞机，Twin Otter International 的涡轮螺旋桨飞机，Scaled

基于1.1.5-alpha版本，具体源码笔记可以参考我的github： https://github.com/saigu/JavaKnowledgeGraph/tree/master/code_reading/canal 本文将对canal的启动模块deployer进行分析。 Deployer模块(绿色部分)在整个系统中的角色如下图所示，用来启动canal-server. 模块内的类如下： 为了能带着目的看源码，以几个问题开头，带着问题来一起探索deployer模块的源码。 CanalServer启动过程中配置如何加载？ CanalServer启动过程中涉及哪些组件？ 集群模式的canalServer，是如何实现instance的HA呢？ 每个canalServer又是怎么获取admin上的配置变更呢？ 1.入口类CanalLauncher 这个类是整个canal-server的入口类。负责配置加载和启动canal-server。 主流程如下： 加载canal.properties的配置内容 根据canal.admin.manager是否为空判断是否是admin控制,如果不是admin控制，就直接根据canal.properties的配置来了 如果是admin控制，使用PlainCanalConfigClient获取远程配置