canal源码分析简介-2

3.0 server模块

server模块的核心接口是CanalServer，其有2个实现类CanalServerWithNetty、CanalServerWithEmbeded。关于CanalServer，官方文档中有有以下描述：

 

 

 

  下图是笔者对官方文档的进一步描述：

 

 

左边的图

表示的是Canal独立部署。不同的应用通过canal client与canal server进行通信，所有的canal client的请求统一由CanalServerWithNetty接受，之后CanalServerWithNetty会将客户端请求派给CanalServerWithEmbeded 进行真正的处理。CannalServerWithEmbeded内部维护了多个canal instance，每个canal instance伪装成不同的mysql实例的slave，而CanalServerWithEmbeded会根据客户端请求携带的destination参数确定要由哪一个canal instance为其提供服务。

右边的图

是直接在应用中嵌入CanalServerWithEmbeded，不需要独立部署canal。很明显，网络通信环节少了，同步binlog信息的效率肯定更高。但是对于使用者的技术要求比较高。在应用中，我们可以通过CanalServerWithEmbeded.instance()方法来获得CanalServerWithEmbeded实例，这一个单例。

整个server模块源码目录结构如下所示：

 

 

其中上面的红色框就是嵌入式实现，而下面的绿色框是基于Netty的实现。

看起来基于netty的实现代码虽然多一点，这其实只是幻觉，CanalServerWithNetty会将所有的请求委派给CanalServerWithEmbedded处理。

而内嵌的方式只有CanalServerWithEmbedded一个类， 是因为CanalServerWithEmbedded又要根据destination选择某个具体的CanalInstance来处理客户端请求，而CanalInstance的实现位于instance模块，我们将在之后分析。因此从canal server的角度来说，CanalServerWithEmbedded才是server模块真正的核心。

        CanalServerWithNetty和CanalServerWithEmbedded都是单例的，提供了一个静态方法instance()获取对应的实例。回顾前一节分析CanalController源码时，在CanalController构造方法中准备CanalServer的相关代码，就是通过这两个静态方法获取对应的实例的。

1.  public CanalController(final Properties properties){
2.         ....
3.      // 准备canal server
4.         ip = getProperty(properties, CanalConstants.CANAL_IP);
5.         port = Integer.valueOf(getProperty(properties, CanalConstants.CANAL_PORT));
6.         embededCanalServer = CanalServerWithEmbedded.instance();
7.         embededCanalServer.setCanalInstanceGenerator(instanceGenerator);// 设置自定义的instanceGenerator
8.         canalServer = CanalServerWithNetty.instance();
9.         canalServer.setIp(ip);
10.         canalServer.setPort(port);
11.        ....   
12. }

CanalServer接口

 CanalServer接口继承了CanalLifeCycle接口，主要是为了重新定义start和stop方法，抛出CanalServerException。

1. public interface CanalServer extends CanalLifeCycle {
2.  
3.     void start() throws CanalServerException;
4.  
5.     void stop() throws CanalServerException;
6. }

CanalServerWithNetty

CanalServerWithNetty主要用于接受客户端的请求，然后将其委派给CanalServerWithEmbeded处理。下面的源码显示了CanalServerWithNetty种定义的字段和构造方法

1. public class CanalServerWithNetty extends AbstractCanalLifeCycle implements CanalServer {
2.     //监听的所有客户端请求都会为派给CanalServerWithEmbedded处理 
3.     private CanalServerWithEmbedded embeddedServer;      // 嵌入式server
4.  
5.     //监听的ip和port，client通过此ip和port与服务端通信
6.     private String                  ip;
7.     private int                     port;
8.  
9.     //netty组件
10.     private Channel                 serverChannel = null;
11.     private ServerBootstrap         bootstrap     = null;
12.     //....单例模式实现
13.     private CanalServerWithNetty(){
14.         //给embeddedServer赋值
15.         this.embeddedServer = CanalServerWithEmbedded.instance();
16.     }
17.     //... start and stop method
18.     //...setters and getters...
19. }

字段说明：

• embeddedServer：因为CanalServerWithNetty需要将请求委派给CanalServerWithEmbeded处理，因此其维护了embeddedServer对象。

• ip、port：这是netty监听的网络ip和端口，client通过这个ip和端口与server通信

• serverChannel、bootstrap：这是netty的API。其中ServerBootstrap用于启动服务端，通过调用其bind方法，返回一个类型为Channel的serverChannel对象，代表服务端通道。关于netty知识不是本教程重点，如果读者不熟悉，可以参考笔者的netty教程。

start方法

start方法中包含了netty启动的核心逻辑，如下所示：

com.alibaba.otter.canal.server.netty.CanalServerWithNetty#start

1. public void start() {
2.         super.start();
3.         //优先启动内嵌的canal server，因为基于netty的实现需要将请求委派给其处理
4.         if (!embeddedServer.isStart()) {
5.             embeddedServer.start();
6.         }
7.         
8.          /* 创建bootstrap实例，参数NioServerSocketChannelFactory也是Netty的API，其接受2个线程池参数
9.          其中第一个线程池是Accept线程池，第二个线程池是woker线程池，
10.          Accept线程池接收到client连接请求后，会将代表client的对象转发给worker线程池处理。
11.          这里属于netty的知识，不熟悉的用户暂时不必深究，简单认为netty使用线程来处理客户端的高并发请求即可。*/
12.         this.bootstrap = new ServerBootstrap(new NioServerSocketChannelFactory(Executors.newCachedThreadPool(),
13.             Executors.newCachedThreadPool()));
14.             
15.         /*pipeline实际上就是netty对客户端请求的处理器链，
16.         可以类比JAVA EE编程中Filter的责任链模式，上一个filter处理完成之后交给下一个filter处理，
17.         只不过在netty中，不再是filter，而是ChannelHandler。*/
18.         bootstrap.setPipelineFactory(new ChannelPipelineFactory() {
19.             public ChannelPipeline getPipeline() throws Exception {
20.                 ChannelPipeline pipelines = Channels.pipeline();
21.                //主要是处理编码、解码。因为网路传输的传入的都是二进制流，FixedHeaderFrameDecoder的作用就是对其进行解析
22.                 pipelines.addLast(FixedHeaderFrameDecoder.class.getName(), new FixedHeaderFrameDecoder());
23.                //处理client与server握手
24.                 pipelines.addLast(HandshakeInitializationHandler.class.getName(), new HandshakeInitializationHandler());
25.                //client身份验证
26.                pipelines.addLast(ClientAuthenticationHandler.class.getName(),
27.                     new ClientAuthenticationHandler(embeddedServer));
28.                 //SessionHandler用于真正的处理客户端请求，是本文分析的重点
29.                SessionHandler sessionHandler = new SessionHandler(embeddedServer);
30.                 pipelines.addLast(SessionHandler.class.getName(), sessionHandler);
31.                 return pipelines;
32.             }
33.         });
34.         
35.         // 启动，当bind方法被调用时，netty开始真正的监控某个端口，此时客户端对这个端口的请求可以被接受到
36.         if (StringUtils.isNotEmpty(ip)) {
37.             this.serverChannel = bootstrap.bind(new InetSocketAddress(this.ip, this.port));
38.         } else {
39.             this.serverChannel = bootstrap.bind(new InetSocketAddress(this.port));
40.         }
41.     }

关于stop方法无非是一些关闭操作，代码很简单，这里不做介绍。

SessionHandler

    很明显的，canal处理client请求的核心逻辑都在SessionHandler这个处理器中。注意其在实例化时，传入了embeddedServer对象，前面我们提过，CanalServerWithNetty要将请求委派给CanalServerWithEmbedded处理，显然SessionHandler也要维护embeddedServer实例。

    这里我们主要分析SessionHandler的 messageReceived方法，这个方法表示接受到了一个客户端请求，我们主要看的是SessionHandler如何对客户端请求进行解析，然后委派给CanalServerWithEmbedded处理的。为了体现其转发请求处理的核心逻辑，以下代码省去了大量源码片段，如下

SessionHandler#messageReceived

1. public class SessionHandler extends SimpleChannelHandler {
2. ....
3. //messageReceived方法表示收到客户端请求
4. public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception {
5.     ....
6.       //根据客户端发送的网路通信包请求类型type，将请求委派embeddedServer处理
7.         switch (packet.getType()) {
8.             case SUBSCRIPTION://订阅请求
9.                 ...
10.                 embeddedServer.subscribe(clientIdentity);
11.                          ...
12.                 break;
13.             case UNSUBSCRIPTION://取消订阅请求
14.                 ...
15.                 embeddedServer.unsubscribe(clientIdentity);
16.                 ...
17.                 break;
18.             case GET://获取binlog请求
19.                 ....
20.                     if (get.getTimeout() == -1) {// 根据客户端是否指定了请求超时时间调用embeddedServer不同方法获取binlog
21.                         message = embeddedServer.getWithoutAck(clientIdentity, get.getFetchSize());
22.                     } else {
23.                         ...
24.                         message = embeddedServer.getWithoutAck(clientIdentity,
25.                             get.getFetchSize(),
26.                             get.getTimeout(),
27.                             unit);
28.                     }
29.                 ...   
30.                 break;
31.             case CLIENTACK://客户端消费成功ack请求
32.                ...
33.                   embeddedServer.ack(clientIdentity, ack.getBatchId());
34.                ...
35.                 break;
36.             case CLIENTROLLBACK://客户端消费失败回滚请求
37.                 ...
38.                     if (rollback.getBatchId() == 0L) {
39.                         embeddedServer.rollback(clientIdentity);// 回滚所有批次
40.                     } else {
41.                         embeddedServer.rollback(clientIdentity, rollback.getBatchId()); // 只回滚单个批次
42.                     }
43.                 ...
44.                 break;
45.             default://无法判断请求类型
46.                 NettyUtils.error(400, MessageFormatter.format("packet type={} is NOT supported!", packet.getType())
47.                     .getMessage(), ctx.getChannel(), null);
48.                 break;
49.         }
50.     ...
51. }
52. ...
53. }

    可以看到，SessionHandler对client请求进行解析后，根据请求类型，委派给CanalServerWithEmbedded的相应方法进行处理。因此核心逻辑都在CanalServerWithEmbedded中。

CannalServerWithEmbeded

CanalServerWithEmbedded实现了CanalServer和CanalServiceCan两个接口。其内部维护了一个Map，key为destination，value为对应的CanalInstance，根据客户端请求携带的destination参数将其转发到对应的CanalInstance上去处理。

1. public class CanalServerWithEmbedded extends AbstractCanalLifeCycle implements CanalServer, CanalService {
2.     ...
3.     //key为destination，value为对应的CanalInstance。
4.     private Map<String, CanalInstance> canalInstances;
5.     ...
6. }

 

对于CanalServer接口中定义的start和stop这两个方法实现比较简单，这里不再赘述。

     在上面的SessionHandler源码分析中，我们已经看到，会根据请求报文的类型，会调用CanalServerWithEmbedded的相应方法，这些方法都定义在CanalService接口中，如下：

1. public interface CanalService {
2.    //订阅
3.     void subscribe(ClientIdentity clientIdentity) throws CanalServerException;
4.    //取消订阅
5.     void unsubscribe(ClientIdentity clientIdentity) throws CanalServerException;
6.    //比例获取数据，并自动自行ack
7.     Message get(ClientIdentity clientIdentity, int batchSize) throws CanalServerException;
8.    //超时时间内批量获取数据，并自动进行ack
9.     Message get(ClientIdentity clientIdentity, int batchSize, Long timeout, TimeUnit unit) throws CanalServerException;
10.     //批量获取数据，不进行ack
11.     Message getWithoutAck(ClientIdentity clientIdentity, int batchSize) throws CanalServerException;
12.    //超时时间内批量获取数据，不进行ack
13.     Message getWithoutAck(ClientIdentity clientIdentity, int batchSize, Long timeout, TimeUnit unit)                                                                                               throws CanalServerException;
14.    //ack某个批次的数据
15.     void ack(ClientIdentity clientIdentity, long batchId) throws CanalServerException;
16.    //回滚所有没有ack的批次的数据
17.     void rollback(ClientIdentity clientIdentity) throws CanalServerException;
18.    //回滚某个批次的数据
19.     void rollback(ClientIdentity clientIdentity, Long batchId) throws CanalServerException;
20. }

 细心地的读者会发现，每个方法中都包含了一个ClientIdentity类型参数，这就是客户端身份的标识。

1. public class ClientIdentity implements Serializable {
2.     private String destination;
3.     private short  clientId;
4.     private String filter;
5.  ...
6. }

CanalServerWithEmbedded就是根据ClientIdentity中的destination参数确定这个请求要交给哪个CanalInstance处理的。

 

下面一次分析每一个方法的作用：

subscribe方法：

subscribe主要用于处理客户端的订阅请求，目前情况下，一个CanalInstance只能由一个客户端订阅，不过可以重复订阅。订阅主要的处理步骤如下：

1、根据客户端要订阅的destination，找到对应的CanalInstance

2、通过这个CanalInstance的CanalMetaManager组件记录下有客户端订阅。

3、获取客户端当前订阅位置(Position)。首先尝试从CanalMetaManager中获取，CanalMetaManager 中记录了某个client当前订阅binlog的位置信息。如果是第一次订阅，肯定无法获取到这个位置，则尝试从CanalEventStore中获取第一个binlog的位置。从CanalEventStore中获取binlog位置信息的逻辑是：CanalInstance一旦启动，就会立刻去拉取binlog，存储到CanalEventStore中，在第一次订阅的情况下，CanalEventStore中的第一条binlog的位置，就是当前客户端当前消费的开始位置。

4、通知CanalInstance订阅关系变化 

1. /**
2.  * 客户端订阅，重复订阅时会更新对应的filter信息
3.  */
4. @Override
5. public void subscribe(ClientIdentity clientIdentity) throws CanalServerException {
6.     checkStart(clientIdentity.getDestination());
7.     //1、根据客户端要订阅的destination，找到对应的CanalInstance 
8.     CanalInstance canalInstance = canalInstances.get(clientIdentity.getDestination());
9.     if (!canalInstance.getMetaManager().isStart()) {
10.         canalInstance.getMetaManager().start();
11.     }
12.   //2、通过CanalInstance的CanalMetaManager组件进行元数据管理，记录一下当前这个CanalInstance有客户端在订阅
13.     canalInstance.getMetaManager().subscribe(clientIdentity); // 执行一下meta订阅
14.   //3、获取客户端当前订阅的binlog位置(Position)，首先尝试从CanalMetaManager中获取
15.     Position position = canalInstance.getMetaManager().getCursor(clientIdentity);
16.     if (position == null) {
17.   //3.1 如果是第一次订阅，尝试从CanalEventStore中获取第一个binlog的位置，作为客户端订阅开始的位置。
18.         position = canalInstance.getEventStore().getFirstPosition();// 获取一下store中的第一条
19.         if (position != null) {
20.             canalInstance.getMetaManager().updateCursor(clientIdentity, position); // 更新一下cursor
21.         }
22.         logger.info("subscribe successfully, {} with first position:{} ", clientIdentity, position);
23.     } else {
24.         logger.info("subscribe successfully, use last cursor position:{} ", clientIdentity, position);
25.     }
26.     //4 通知下订阅关系变化
27.     canalInstance.subscribeChange(clientIdentity);
28. }

unsubscribe方法：

   unsubscribe方法主要用于取消订阅关系。在下面的代码中，我们可以看到，其实就是找到CanalInstance对应的CanalMetaManager，调用其unsubscribe取消这个订阅记录。需要注意的是，取消订阅并不意味着停止CanalInstance。当某个客户端取消了订阅，还会有新的client来订阅这个CanalInstance，所以不能停。 

1. /**
2.  * 取消订阅
3.  */
4. @Override
5. public void unsubscribe(ClientIdentity clientIdentity) throws CanalServerException {
6.     CanalInstance canalInstance = canalInstances.get(clientIdentity.getDestination());
7.     canalInstance.getMetaManager().unsubscribe(clientIdentity); // 执行一下meta订阅
8.     logger.info("unsubscribe successfully, {}", clientIdentity);
9. }

 

listAllSubscribe方法：

    这一个管理方法，其作用是列出订阅某个destination的所有client。这里返回的是一个List<ClientIdentity>，不过我们已经多次提到，目前一个destination只能由一个client订阅。这里之所以返回一个list，是canal原先计划要支持多个client订阅同一个destination。不过，这个功能一直没有实现。所以List中，实际上只会包含一个ClientIdentity。 

1. /**
2.  * 查询所有的订阅信息
3.  */
4. public List<ClientIdentity> listAllSubscribe(String destination) throws CanalServerException {
5.     CanalInstance canalInstance = canalInstances.get(destination);
6.     return canalInstance.getMetaManager().listAllSubscribeInfo(destination);
7. }

listBatchIds方法:

1. /**
2.  * 查询当前未被ack的batch列表，batchId会按照从小到大进行返回
3.  */
4. public List<Long> listBatchIds(ClientIdentity clientIdentity) throws CanalServerException {
5.     checkStart(clientIdentity.getDestination());
6.     checkSubscribe(clientIdentity);
7.     CanalInstance canalInstance = canalInstances.get(clientIdentity.getDestination());
8.     Map<Long, PositionRange> batchs = canalInstance.getMetaManager().listAllBatchs(clientIdentity);
9.     List<Long> result = new ArrayList<Long>(batchs.keySet());
10.     Collections.sort(result);
11.     return result;
12. }

getWithoutAck方法：

getWithoutAck方法用于客户端获取binlog消息 ，一个获取一批(batch)的binlog，canal会为这批binlog生成一个唯一的batchId。客户端如果消费成功，则调用ack方法对这个批次进行确认。如果失败的话，可以调用rollback方法进行回滚。客户端可以连续多次调用getWithoutAck方法来获取binlog，在ack的时候，需要按照获取到binlog的先后顺序进行ack。如果后面获取的binlog被ack了，那么之前没有ack的binlog消息也会自动被ack。

getWithoutAck方法大致工作步骤如下所示：

1. 根据destination找到要从哪一个CanalInstance中获取binlog消息。

2. 确定从哪一个位置(Position)开始继续消费binlog。通常情况下，这个信息是存储在CanalMetaManager中。特别的，在第一次获取的时候，CanalMetaManager 中还没有存储任何binlog位置信息。此时CanalEventStore中存储的第一条binlog位置，则应该client开始消费的位置。

3. 根据Position从CanalEventStore中获取binlog。为了尽量提高效率，一般一次获取一批binlog，而不是获取一条。这个批次的大小(batchSize)由客户端指定。同时客户端可以指定超时时间，在超时时间内，如果获取到了batchSize的binlog，会立即返回。 如果超时了还没有获取到batchSize指定的binlog个数，也会立即返回。特别的，如果没有设置超时时间，如果没有获取到binlog也立即返回。

4. 在CanalMetaManager中记录这个批次的binlog消息。CanalMetaManager会为获取到的这个批次的binlog生成一个唯一的batchId，batchId是递增的。如果binlog信息为空，则直接把batchId设置为-1。 

1. @Override
2. public Message getWithoutAck(ClientIdentity clientIdentity, int batchSize) throws CanalServerException {
3.     return getWithoutAck(clientIdentity, batchSize, null, null);
4. }
5. /**
6.  * <pre>
7.  * 几种case:
8.  * a. 如果timeout为null，则采用tryGet方式，即时获取
9.  * b. 如果timeout不为null
10.  *    1. timeout为0，则采用get阻塞方式，获取数据，不设置超时，直到有足够的batchSize数据才返回
11.  *    2. timeout不为0，则采用get+timeout方式，获取数据，超时还没有batchSize足够的数据，有多少返回多少
12.  * </pre>
13.  */
14. @Override
15. public Message getWithoutAck(ClientIdentity clientIdentity, int batchSize, Long timeout, TimeUnit unit)
16.                                                                                                        throws CanalServerException {
17.     checkStart(clientIdentity.getDestination());
18.     checkSubscribe(clientIdentity);
19.       // 1、根据destination找到要从哪一个CanalInstance中获取binlog消息
20.     CanalInstance canalInstance = canalInstances.get(clientIdentity.getDestination());
21.     synchronized (canalInstance) {
22.         //2、从CanalMetaManager中获取最后一个没有ack的binlog批次的位置信息。
23.         PositionRange<LogPosition> positionRanges = canalInstance.getMetaManager().getLastestBatch(clientIdentity);
24.    //3 从CanalEventStore中获取binlog
25.         Events<Event> events = null;
26.         if (positionRanges != null) { // 3.1 如果从CanalMetaManager获取到了位置信息，从当前位置继续获取binlog
27.             events = getEvents(canalInstance.getEventStore(), positionRanges.getStart(), batchSize, timeout, unit);
28.         } else { //3.2 如果没有获取到binlog位置信息，从当前store中的第一条开始获取
29.             Position start = canalInstance.getMetaManager().getCursor(clientIdentity);
30.             if (start == null) { // 第一次，还没有过ack记录，则获取当前store中的第一条
31.                 start = canalInstance.getEventStore().getFirstPosition();
32.             }
33.       // 从CanalEventStore中获取binlog消息
34.             events = getEvents(canalInstance.getEventStore(), start, batchSize, timeout, unit);
35.         }
36.         //4 记录批次信息到CanalMetaManager中
37.         if (CollectionUtils.isEmpty(events.getEvents())) {
38.           //4.1 如果获取到的binlog消息为空，构造一个空的Message对象，将batchId设置为-1返回给客户端
39.             logger.debug("getWithoutAck successfully, clientId:{} batchSize:{} but result is null", new Object[] {
40.                     clientIdentity.getClientId(), batchSize });
41.             return new Message(-1, new ArrayList<Entry>()); // 返回空包，避免生成batchId，浪费性能
42.         } else {
43.            //4.2 如果获取到了binlog消息，将这个批次的binlog消息记录到CanalMetaMaager中，并生成一个唯一的batchId
44.             Long batchId = canalInstance.getMetaManager().addBatch(clientIdentity, events.getPositionRange());
45.             //将Events转为Entry
46.             List<Entry> entrys = Lists.transform(events.getEvents(), new Function<Event, Entry>() {
47.                 public Entry apply(Event input) {
48.                     return input.getEntry();
49.                 }
50.             });
51.             logger.info("getWithoutAck successfully, clientId:{} batchSize:{}  real size is {} and result is [batchId:{} , position:{}]",
52.                 clientIdentity.getClientId(),
53.                 batchSize,
54.                 entrys.size(),
55.                 batchId,
56.                 events.getPositionRange());
57.             //构造Message返回
58.             return new Message(batchId, entrys);
59.         }
60.     }
61. }
62. /**
63.  * 根据不同的参数，选择不同的方式获取数据
64.  */
65. private Events<Event> getEvents(CanalEventStore eventStore, Position start, int batchSize, Long timeout,
66.                                 TimeUnit unit) {
67.     if (timeout == null) {
68.         return eventStore.tryGet(start, batchSize);
69.     } else {
70.         try {
71.             if (timeout <= 0) {
72.                 return eventStore.get(start, batchSize);
73.             } else {
74.                 return eventStore.get(start, batchSize, timeout, unit);
75.             }
76.         } catch (Exception e) {
77.             throw new CanalServerException(e);
78.         }
79.     }
80. }

ack方法：

ack方法时客户端用户确认某个批次的binlog消费成功。进行 batch id 的确认。确认之后，小于等于此 batchId 的 Message 都会被确认。注意：进行反馈时必须按照batchId的顺序进行ack(需有客户端保证)

ack时需要做以下几件事情：

1. 从CanalMetaManager中，移除这个批次的信息。在getWithoutAck方法中，将批次的信息记录到了CanalMetaManager中，ack时移除。

2. 记录已经成功消费到的binlog位置，以便下一次获取的时候可以从这个位置开始，这是通过CanalMetaManager记录的。

3. 从CanalEventStore中，将这个批次的binlog内容移除。因为已经消费成功，继续保存这些已经消费过的binlog没有任何意义，只会白白占用内存。 

1. @Override
2. public void ack(ClientIdentity clientIdentity, long batchId) throws CanalServerException {
3.     checkStart(clientIdentity.getDestination());
4.     checkSubscribe(clientIdentity);
5.     CanalInstance canalInstance = canalInstances.get(clientIdentity.getDestination());
6.     PositionRange<LogPosition> positionRanges = null;
7.    //1 从CanalMetaManager中，移除这个批次的信息
8.     positionRanges = canalInstance.getMetaManager().removeBatch(clientIdentity, batchId); // 更新位置
9.     if (positionRanges == null) { // 说明是重复的ack/rollback
10.         throw new CanalServerException(String.format("ack error , clientId:%s batchId:%d is not exist , please check",
11.             clientIdentity.getClientId(),
12.             batchId));
13.     }
14.     //2、记录已经成功消费到的binlog位置，以便下一次获取的时候可以从这个位置开始，这是通过CanalMetaManager记录的
15.     if (positionRanges.getAck() != null) {
16.         canalInstance.getMetaManager().updateCursor(clientIdentity, positionRanges.getAck());
17.         logger.info("ack successfully, clientId:{} batchId:{} position:{}",
18.             clientIdentity.getClientId(),
19.             batchId,
20.             positionRanges);
21.     }
22.       //3、从CanalEventStore中，将这个批次的binlog内容移除
23.     canalInstance.getEventStore().ack(positionRanges.getEnd());
24. }

rollback方法：

1. /**
2.  * 回滚到未进行 {@link #ack} 的地方，下次fetch的时候，可以从最后一个没有 {@link #ack} 的地方开始拿
3.  */
4. @Override
5. public void rollback(ClientIdentity clientIdentity) throws CanalServerException {
6.     checkStart(clientIdentity.getDestination());
7.     CanalInstance canalInstance = canalInstances.get(clientIdentity.getDestination());
8.     // 因为存在第一次链接时自动rollback的情况，所以需要忽略未订阅
9.     boolean hasSubscribe = canalInstance.getMetaManager().hasSubscribe(clientIdentity);
10.     if (!hasSubscribe) {
11.         return;
12.     }
13.     synchronized (canalInstance) {
14.         // 清除batch信息
15.         canalInstance.getMetaManager().clearAllBatchs(clientIdentity);
16.         // rollback eventStore中的状态信息
17.         canalInstance.getEventStore().rollback();
18.         logger.info("rollback successfully, clientId:{}", new Object[] { clientIdentity.getClientId() });
19.     }
20. }
21. /**
22.  * 回滚到未进行 {@link #ack} 的地方，下次fetch的时候，可以从最后一个没有 {@link #ack} 的地方开始拿
23.  */
24. @Override
25. public void rollback(ClientIdentity clientIdentity, Long batchId) throws CanalServerException {
26.     checkStart(clientIdentity.getDestination());
27.     CanalInstance canalInstance = canalInstances.get(clientIdentity.getDestination());
28.     // 因为存在第一次链接时自动rollback的情况，所以需要忽略未订阅
29.     boolean hasSubscribe = canalInstance.getMetaManager().hasSubscribe(clientIdentity);
30.     if (!hasSubscribe) {
31.         return;
32.     }
33.     synchronized (canalInstance) {
34.         // 清除batch信息
35.         PositionRange<LogPosition> positionRanges = canalInstance.getMetaManager().removeBatch(clientIdentity,
36.             batchId);
37.         if (positionRanges == null) { // 说明是重复的ack/rollback
38.             throw new CanalServerException(String.format("rollback error, clientId:%s batchId:%d is not exist , please check",
39.                 clientIdentity.getClientId(),
40.                 batchId));
41.         }
42.         // lastRollbackPostions.put(clientIdentity,
43.         // positionRanges.getEnd());// 记录一下最后rollback的位置
44.         // TODO 后续rollback到指定的batchId位置
45.         canalInstance.getEventStore().rollback();// rollback
46.                                                  // eventStore中的状态信息
47.         logger.info("rollback successfully, clientId:{} batchId:{} position:{}",
48.             clientIdentity.getClientId(),
49.             batchId,
50.             positionRanges);
51.     }
52. }

get方法：

与getWithoutAck主要流程完全相同，唯一不同的是，在返回数据给用户前，直接进行了ack，而不管客户端消费是否成功。

1. @Override
2. public Message get(ClientIdentity clientIdentity, int batchSize) throws CanalServerException {
3.     return get(clientIdentity, batchSize, null, null);
4. }
5.  /*
6.  * 几种case:
7.  * a. 如果timeout为null，则采用tryGet方式，即时获取
8.  * b. 如果timeout不为null
9.  *    1. timeout为0，则采用get阻塞方式，获取数据，不设置超时，直到有足够的batchSize数据才返回
10.  *    2. timeout不为0，则采用get+timeout方式，获取数据，超时还没有batchSize足够的数据，有多少返回多少
11.  */
12. @Override
13. public Message get(ClientIdentity clientIdentity, int batchSize, Long timeout, TimeUnit unit)
14.                                                                                              throws CanalServerException {
15.     checkStart(clientIdentity.getDestination());
16.     checkSubscribe(clientIdentity);
17.     CanalInstance canalInstance = canalInstances.get(clientIdentity.getDestination());
18.     synchronized (canalInstance) {
19.         // 获取到流式数据中的最后一批获取的位置
20.         PositionRange<LogPosition> positionRanges = canalInstance.getMetaManager().getLastestBatch(clientIdentity);
21.         if (positionRanges != null) {
22.             throw new CanalServerException(String.format("clientId:%s has last batch:[%s] isn't ack , maybe loss data",
23.                 clientIdentity.getClientId(),
24.                 positionRanges));
25.         }
26.         Events<Event> events = null;
27.         Position start = canalInstance.getMetaManager().getCursor(clientIdentity);
28.         events = getEvents(canalInstance.getEventStore(), start, batchSize, timeout, unit);
29.         if (CollectionUtils.isEmpty(events.getEvents())) {
30.             logger.debug("get successfully, clientId:{} batchSize:{} but result is null", new Object[] {
31.                     clientIdentity.getClientId(), batchSize });
32.             return new Message(-1, new ArrayList<Entry>()); // 返回空包，避免生成batchId，浪费性能
33.         } else {
34.             // 记录到流式信息
35.             Long batchId = canalInstance.getMetaManager().addBatch(clientIdentity, events.getPositionRange());
36.             List<Entry> entrys = Lists.transform(events.getEvents(), new Function<Event, Entry>() {
37.                 public Entry apply(Event input) {
38.                     return input.getEntry();
39.                 }
40.             });
41.             logger.info("get successfully, clientId:{} batchSize:{} real size is {} and result is [batchId:{} , position:{}]",
42.                 clientIdentity.getClientId(),
43.                 batchSize,
44.                 entrys.size(),
45.                 batchId,
46.                 events.getPositionRange());
47.             // 直接提交ack
48.             ack(clientIdentity, batchId);
49.             return new Message(batchId, entrys);
50.         }
51.     }
52. }

4.0 instance模块

 2018-05-06 23:15:08  10,140  12

    在上一节server模块源码分析中，我们提到CanalServerWithNetty封装了一层网络请求协议，将请求委派给CanalServerWithEmbedded处理。CanalServerWithEmbedded会根据请求携带的destination参数，选择对应的CanalInstance来真正的处理请求。这正是一步一步抽丝剥茧的过程，在本节中，我们将要分析CanalInstance的源码。

1 CanalInstance源码概览

CanalInstance相关代码位于canal源码的instance模块中，这个模块又有三个子模块，如下所示： 

 

 

 

    在core模块中，定义了CanalInstance接口，以及其抽象类子类AbstractCanalInstance。

    在spring模块，提供了基于spring配置方式的CanalInstanceWithSpring实现，即CanalInstance实例的创建，通过spring配置文件来创建。

    在manager模块中，提供了基于manager配置方式的CanalInstanceWithManager实现，即CanalInstance实例根据远程配置中心的内容来创建。

 

CanalInstance类图继承关系如下所示： 

 

 

在本节中，我们主要以spring配置方式为例，对CanalInstance源码进行解析。

2 CanalInstance接口

在Canal官方文档中有一张图描述了CanalInstance的4个主要组件，如下： 

 

 

其中：

event parser：数据源接入，模拟slave协议和master进行交互，协议解析

event sink：parser和store链接器，进行数据过滤，加工，分发的工作

event store：数据存储

meta manager：增量订阅/消费binlog元数据位置存储

 

 在CanalInstance接口中，主要就是定义了获得这几个组成部分的方法： 

1. public interface CanalInstance extends CanalLifeCycle {
2.   //这个instance对应的destination
3.     String getDestination();
4.   //数据源接入，模拟slave协议和master进行交互，协议解析，位于canal.parse模块中
5.     CanalEventParser getEventParser();
6.   //parser和store链接器，进行数据过滤，加工，分发的工作，位于canal.sink模块中
7.     CanalEventSink getEventSink();
8.   //数据存储，位于canal.store模块中
9.     CanalEventStore getEventStore();
10.   //增量订阅&消费元数据管理器，位于canal.meta模块中
11.     CanalMetaManager getMetaManager();
12.   
13.   //告警，位于canal.common块中
14.     CanalAlarmHandler getAlarmHandler();
15.     /**     * 客户端发生订阅/取消订阅行为     */   
16.    boolean subscribeChange(ClientIdentity identity);
17. }

     可以看到，instance模块其实是把这几个模块组装在一起，为客户端的binlog订阅请求提供服务。有些模块都有多种实现，不同组合方式，最终确定了一个CanalInstance的工作逻辑。 

 

CanalEventParser接口实现类：

        MysqlEventParser：伪装成单个mysql实例的slave解析binglog日志

        GroupEventParser：伪装成多个mysql实例的slave解析binglog日志。内部维护了多个CanalEventParser。主要应用场景是分库分表：比如产品数据拆分了4个库，位于不同的mysql实例上。正常情况下，我们需要配置四个CanalInstance。对应的，业务上要消费数据时，需要启动4个客户端，分别链接4个instance实例。为了方便业务使用，此时我们可以让CanalInstance引用一个GroupEventParser，由GroupEventParser内部维护4个MysqlEventParser去4个不同的mysql实例去拉取binlog，最终合并到一起。此时业务只需要启动1个客户端，链接这个CanalInstance即可.

        LocalBinlogEventParser：解析本地的mysql binlog。例如将mysql的binlog文件拷贝到canal的机器上进行解析。

CanalEventSink接口实现类：

        EntryEventSink

        GroupEventSink：基于归并排序的sink处理

CanalEventStore接口实现类：

        目前只有MemoryEventStoreWithBuffer，基于内存buffer构建内存memory store

CanalMetaManager：

        ZooKeeperMetaManager：将元数据存存储到zk中

        MemoryMetaManager：将元数据存储到内存中

        MixedMetaManager：组合memory + zookeeper的使用模式

        PeriodMixedMetaManager：基于定时刷新的策略的mixed实现

        FileMixedMetaManager：先写内存，然后定时刷新数据到File 

 

    关于这些实现的具体细节，我们在相应模块的源码分析时，进行讲解。目前只需要知道，一些组件有多种实现，因此组合工作方式有多种。

3 AbstractCanalInstance源码分析

      AbstractCanalInstance是CanalInstance的抽象子类，定义了相关字段来维护eventParser、eventSink、eventStore、metaManager的引用。 

1. public class AbstractCanalInstance extends AbstractCanalLifeCycle implements CanalInstance {
2.     private static final Logger logger = LoggerFactory.getLogger(AbstractCanalInstance.class);
3.     protected Long canalId;                                     // 和manager交互唯一标示
4.     protected String destination;                               // 队列名字
5.     protected CanalEventStore<Event> eventStore;                // 有序队列
6.     protected CanalEventParser eventParser;                     // 解析对应的数据信息
7.     protected CanalEventSink<List<CanalEntry.Entry>> eventSink; // 链接parse和store的桥接器
8.     protected CanalMetaManager metaManager;                     // 消费信息管理器
9.     protected CanalAlarmHandler alarmHandler;                   // alarm报警机制
10.     //...
11. }

    需要注意的是，在AbstractCanalInstance中，并没有提供方法来初始化这些字段。可以看到，这些字段都是protected的，子类可以直接访问，显然这些字段都是在AbstractCanalInstance的子类中进行赋值的。

    AbstractCanalInstance不关心这些字段的具体实现，只是从接口层面进行调用。对于其子类而言，只需要给相应的字段赋值即可。在稍后我们将要讲解的CanalInstanceWithSpring中，你将会发现其仅仅给eventParser、eventSink、eventStore、metaManager几个字段赋值，其他什么工作都没干。

    因此，对于instance模块而言，其核心工作逻辑都是在AbstractCanalInstance中实现的。

3.1 start方法和stop方法：

start方法：

    在AbstractCanalInstance的start方法中，主要就是启动各个模块。启动顺序为：metaManager—>eventStore—>eventSink—>eventParser。

源码如下所示：

com.alibaba.otter.canal.instance.core.AbstractCanalInstance#start 

1. public void start() {
2.         super.start();
3.         if (!metaManager.isStart()) {
4.             metaManager.start();
5.         }
6.         if (!alarmHandler.isStart()) {
7.             alarmHandler.start();
8.         }
9.         if (!eventStore.isStart()) {
10.             eventStore.start();
11.         }
12.         if (!eventSink.isStart()) {
13.             eventSink.start();
14.         }
15.         if (!eventParser.isStart()) {
16.             beforeStartEventParser(eventParser);//启动前执行一些操作
17.             eventParser.start();
18.             afterStartEventParser(eventParser);//启动后执行一些操作
19.         }
20.         logger.info("start successful....");
21.     }

 要理解为什么按照这个顺序启动很简单。官方关于instance模块构成的图中，把metaManager放在最下面，说明其是最基础的部分，因此应该最先启动。

    而eventParser依赖于eventSink，需要把自己解析的binlog交给其加工过滤，而eventSink又要把处理后的数据交给eventStore进行存储。因此依赖关系如下：eventStore—>eventSink—>eventParser ，启动的时候也要按照这个顺序启动。

    

stop方法：

在停止的时候，实际上就是停止内部的各个模块，模块停止的顺序与start方法刚好相反

com.alibaba.otter.canal.instance.core.AbstractCanalInstance#stop 

1. @Override    
2. public void stop() {
3.         super.stop();
4.         logger.info("stop CannalInstance for {}-{} ", new Object[] { canalId, destination });
5.         if (eventParser.isStart()) {
6.             beforeStopEventParser(eventParser);//停止前执行一些操作
7.             eventParser.stop();
8.             afterStopEventParser(eventParser);//停止后执行一些操作
9.         }
10.         if (eventSink.isStart()) {
11.             eventSink.stop();
12.         }
13.         if (eventStore.isStart()) {
14.             eventStore.stop();
15.         }
16.         if (metaManager.isStart()) {
17.             metaManager.stop();
18.         }
19.         if (alarmHandler.isStart()) {
20.             alarmHandler.stop();
21.         }
22.         logger.info("stop successful....");
23.     }

3.2 start和stop方法对eventParser的特殊处理

     在AbstractCanalInstance的start和stop方法，对于eventParser这个组件的启动和停止，都有一些特殊处理，以下是相关代码片段： 

1. --start方法
2. beforeStartEventParser(eventParser);//启动前执行一些操作
3. eventParser.start();
4. afterStartEventParser(eventParser);//启动后执行一些操作
5. --stop方法
6. beforeStopEventParser(eventParser);//停止前执行一些操作
7. eventParser.stop();
8. afterStopEventParser(eventParser);//停止后执行一些操作

    这与eventParser的自身构成有关系。canal官方文档DevGuide中，关于eventParser有以下描述：

 

 

因此，eventParser在启动之前，需要先启动CanalLogPositionManager和CanalHAController。

    关于CanalLogPositionManager，做一点补充说明。

    mysql在主从同步过程中，要求slave自己维护binlog的消费进度信息。canal伪装成slave，因此也要维护这样的信息。

    事实上，如果读者自己搭建过mysql主从复制的话，在slave机器的data目录下，都会有一个master.info文件，这个文件的作用就是存储主库的消费binlog解析进度信息。

beforeStartEventParser方法

   beforeStartEventParser方法的作用是eventParser前做的一些特殊处理。首先会判断eventParser的类型是否是GroupEventParser，在前面我已经介绍过，这是为了处理分库分表的情况。如果是，循环其包含的所有CanalEventParser，依次调用startEventParserInternal方法；否则直接调用com.alibaba.otter.canal.instance.core.AbstractCanalInstance#beforeStartEventParser 

1. protected void beforeStartEventParser(CanalEventParser eventParser) {
2.     //1、判断eventParser的类型是否是GroupEventParser
3.     boolean isGroup = (eventParser instanceof GroupEventParser);
4.     //2、如果是GroupEventParser，则循环启动其内部包含的每一个CanalEventParser，依次调用startEventParserInternal方法
5.     if (isGroup) {
6.         // 处理group的模式
7.         List<CanalEventParser> eventParsers = ((GroupEventParser) eventParser).getEventParsers();
8.         for (CanalEventParser singleEventParser : eventParsers) {// 需要遍历启动
9.             startEventParserInternal(singleEventParser, true);
10.         }
11.     //如果不是，说明是一个普通的CanalEventParser，直接调用startEventParserInternal方法   
12.     } else {
13.         startEventParserInternal(eventParser, false);
14.     }
15. }

    从上面的分析中，可以看出，针对单个CanalEventParser，都是通过调用startEventParserInternal来启动的，其内部会启动CanalLogPositionManager和CanalHAController。

com.alibaba.otter.canal.instance.core.AbstractCanalInstance#startEventParserInternal 

1. /**
2. * 初始化单个eventParser，不需要考虑group
3. */
4. protected void startEventParserInternal(CanalEventParser eventParser, boolean isGroup) {
5.     // 1 、启动CanalLogPositionManager
6.     if (eventParser instanceof AbstractEventParser) {
7.         AbstractEventParser abstractEventParser = (AbstractEventParser) eventParser;
8.         CanalLogPositionManager logPositionManager = abstractEventParser.getLogPositionManager();
9.         if (!logPositionManager.isStart()) {
10.             logPositionManager.start();
11.         }
12.     }
13.     // 2 、启动CanalHAController
14.     if (eventParser instanceof MysqlEventParser) {
15.         MysqlEventParser mysqlEventParser = (MysqlEventParser) eventParser;
16.         CanalHAController haController = mysqlEventParser.getHaController();
17.         if (haController instanceof HeartBeatHAController) {
18.             ((HeartBeatHAController) haController).setCanalHASwitchable(mysqlEventParser);
19.         }
20.         if (!haController.isStart()) {
21.             haController.start();
22.         }
23.     }
24. }

关于CanalLogPositionManager和CanalHAController的详细源码，我们将会在分析parser模块的时候进行介绍

 

afterStartEventParser方法

    在eventParser启动后，会调用afterStartEventParser方法。这个方法内部主要是通过metaManager读取一下历史订阅过这个CanalInstance的客户端信息，然后更新一下filter。

com.alibaba.otter.canal.instance.core.AbstractCanalInstance#afterStartEventParser 

1. protected void afterStartEventParser(CanalEventParser eventParser) {
2.         // 读取一下历史订阅的client信息       
3.         List<ClientIdentity> clientIdentitys = metaManager.listAllSubscribeInfo(destination);
4.         for (ClientIdentity clientIdentity : clientIdentitys) {
5.             //更新filter
6.             subscribeChange(clientIdentity);
7.         }
8.     }

 

subscribeChange 方法

     subscribeChange方法，主要是更新一下eventParser中的filter。 

1. @Override    
2. public boolean subscribeChange(ClientIdentity identity) {
3.         if (StringUtils.isNotEmpty(identity.getFilter())) {//如果设置了filter
4.             logger.info("subscribe filter change to " + identity.getFilter());
5.             AviaterRegexFilter aviaterFilter = new AviaterRegexFilter(identity.getFilter());
6.             boolean isGroup = (eventParser instanceof GroupEventParser);
7.             if (isGroup) {
8.                 // 处理group的模式               
9.                List<CanalEventParser> eventParsers = ((GroupEventParser) eventParser).getEventParsers();
10.                 for (CanalEventParser singleEventParser : eventParsers) {// 需要遍历启动                   
11.                          ((AbstractEventParser) singleEventParser).setEventFilter(aviaterFilter);
12.                 }
13.             } else {
14.                 ((AbstractEventParser) eventParser).setEventFilter(aviaterFilter);
15.             }
16.         }
17.         // filter的处理规则       
18.        // a. parser处理数据过滤处理       
19.        // b. sink处理数据的路由&分发,一份parse数据经过sink后可以分发为多份，每份的数据可以根据自己的过滤规则不同而有不同的数据      
20.        // 后续内存版的一对多分发，可以考虑      
21.      return true;
22.     }

    关于filter，进行一下补充说明，filter规定了需要订阅哪些库，哪些表。在服务端和客户端都可以设置，客户端的配置会覆盖服务端的配置。

服务端配置：主要是配置instance.properties中的canal.instance.filter.regex配置项，官网文档关于这个配置项有以下介绍 

 

 

客户端配置

客户端在订阅时，调用CanalConnector接口中定义的带有filter参数的subscribe方法重载形式

1. /**
2. * 客户端订阅，重复订阅时会更新对应的filter信息
3. *
4. * <pre>
5. * 说明：
6. * a. 如果本次订阅中filter信息为空，则直接使用canal server服务端配置的filter信息
7. * b. 如果本次订阅中filter信息不为空，目前会直接替换canal server服务端配置的filter信息，以本次提交的为准
8. * </pre>
9. */
10. void subscribe(String filter) throws CanalClientException;

    至此，针对start eventParser前后的特殊处理步骤的两个方法：beforeStartEventParser和afterStartEventParser我们已经分析完成。

    对于stop eventParser前后做的特殊处理涉及的beforeStopEventParser和afterStopEventParser方法，这里不再赘述。

3.3 AbstractCanalInstance总结

    AbstractCanalInstance源码到目前我们已经分析完成，无非就是在start和stop时，按照一定的顺序启动或停止event store、event sink、event parser、meta manager这几个组件，期间对于event parser的启动和停止做了特殊处理，并没有提供订阅binlog的相关方法。那么如何来订阅binglog数据呢？答案是直接操作器内部组件。

    AbstractCanalInstance通过相关get方法直接返回了其内部的组件： 

1. @Override
2. public CanalEventParser getEventParser() {return eventParser;}
3. @Override
4. public CanalEventSink getEventSink() {return eventSink;}
5. @Override
6. public CanalEventStore getEventStore() {return eventStore;}
7. @Override
8. public CanalMetaManager getMetaManager() {return metaManager;}

    在上一节server模块源码分析中，CanalServerWithEmbedded就是直接通过CanalInstance的内部组件，进行操作的。我们再次回顾一下getWithoutAck方法，进行验证：

 com.alibaba.otter.canal.server.embedded.CanalServerWithEmbedded#getWithoutAck 

1. public Message getWithoutAck(ClientIdentity clientIdentity, int batchSize, Long timeout, TimeUnit unit)
2. throws CanalServerException 
3. {
4.     checkStart(clientIdentity.getDestination());
5.     checkSubscribe(clientIdentity);
6.     CanalInstance canalInstance = canalInstances.get(clientIdentity.getDestination());
7.     synchronized (canalInstance) {
8.         //通过canalInstance.getMetaManager() 获取到流式数据中的最后一批获取的位置
9.         PositionRange<LogPosition> positionRanges = canalInstance.getMetaManager().getLastestBatch(clientIdentity);
10.         Events<Event> events = null;
11.         if (positionRanges != null) {
12.             //通过canalInstance.getEventStore()获得binlog事件
13.             events = getEvents(canalInstance.getEventStore(), positionRanges.getStart(), batchSize, timeout, unit);
14.         } else {// ack后第一次获取，通过canalInstance.getMetaManager()获得开始位置
15.             Position start = canalInstance.getMetaManager().getCursor(clientIdentity);
16.             if (start == null) { // 第一次，还没有过ack记录，通过canalInstance.getEventStore()当前store中的第一条
17.                 start = canalInstance.getEventStore().getFirstPosition();
18.             }
19.             //通过canalInstance.getEventStore()获得binlog事件
20.             events = getEvents(canalInstance.getEventStore(), start, batchSize, timeout, unit);
21.         }
22.         if (CollectionUtils.isEmpty(events.getEvents())) {
23.             logger.debug("getWithoutAck successfully, clientId:{} batchSize:{} but result is null", new Object[] {
24.                     clientIdentity.getClientId(), batchSize });
25.             return new Message(-1, new ArrayList<Entry>()); // 返回空包，避免生成batchId，浪费性能
26.         } else {
27.             // 通过canalInstance.getMetaManager()记录流式信息
28.             Long batchId = canalInstance.getMetaManager().addBatch(clientIdentity, events.getPositionRange());
29.             List<Entry> entrys = Lists.transform(events.getEvents(), new Function<Event, Entry>() {
30.                 public Entry apply(Event input) {
31.                     return input.getEntry();
32.                 }
33.             });
34.            ...
35.             return new Message(batchId, entrys);
36.         }
37.     }
38. }

    可以看到AbstractCanalInstance除了负责启动和停止其内部组件，就没有其他工作了。真正获取binlog信息，以及相关元数据维护的逻辑，都是在CanalServerWithEmbedded中完成的。

    事实上，从设计的角度来说，笔者认为既然这些模块是CanalInstance的内部组件，那么相关操作也应该封装在CanalInstance的实现类中，对外部屏蔽，不应该把这些逻辑放到CanalServerWithEmbedded中实现。

    最后，AbstractCanalInstance中并没有metaManager、eventSink、eventPaser，eventStore这几个组件。这几个组件的实例化是在AbstractCanalInstance的子类中实现的。AbstractCanalInstance有2个子类：CanalInstanceWithSpring和CanalInstanceWithManager。我们将以CanalInstanceWithSpring为例进行说明如何给这几个组件赋值。

4 CanalInstanceWithSpring    

    CanalInstanceWithSpring是AbstractCanalInstance的子类，提供了一些set方法为instance的组成模块赋值，如下所示： 

1. public class CanalInstanceWithSpring extends AbstractCanalInstance {
2.     private static final Logger logger = LoggerFactory.getLogger(CanalInstanceWithSpring.class);
3.     public void start() {
4.         logger.info("start CannalInstance for {}-{} ", new Object[] { 1, destination });
5.         super.start();
6.     }
7.     // ======== setter ========
8.     public void setDestination(String destination) {
9.         this.destination = destination;
10.     }
11.     public void setEventParser(CanalEventParser eventParser) {
12.         this.eventParser = eventParser;
13.     }
14.     public void setEventSink(CanalEventSink<List<CanalEntry.Entry>> eventSink) {
15.         this.eventSink = eventSink;
16.     }
17.     public void setEventStore(CanalEventStore<Event> eventStore) {
18.         this.eventStore = eventStore;
19.     }
20.     public void setMetaManager(CanalMetaManager metaManager) {
21.         this.metaManager = metaManager;
22.     }
23.     public void setAlarmHandler(CanalAlarmHandler alarmHandler) {
24.         this.alarmHandler = alarmHandler;
25.     }
26. }

    当我们配置加载方式为spring时，创建的CanalInstance实例类型都是CanalInstanceWithSpring。canal将会寻找本地的spring配置文件来创建instance实例。canal默认提供了一下几种spring配置文件：

• spring/memory-instance.xml

• spring/file-instance.xml

• spring/default-instance.xml

• spring/group-instance.xml

 

 在这4个配置文件中，我们无一例外的都可以看到以下bean配置： 

1. <!--注意class属性都是CanalInstanceWithSpring-->
2. <bean id="instance" class="com.alibaba.otter.canal.instance.spring.CanalInstanceWithSpring">
3.    <property name="destination" value="${canal.instance.destination}" />
4.    <property name="eventParser">
5.       <ref local="eventParser" />
6.    </property>
7.    <property name="eventSink">
8.       <ref local="eventSink" />
9.    </property>
10.    <property name="eventStore">
11.       <ref local="eventStore" />
12.    </property>
13.    <property name="metaManager">
14.       <ref local="metaManager" />
15.    </property>
16.    <property name="alarmHandler">
17.       <ref local="alarmHandler" />
18.    </property>
19. </bean>

    这四个配置文件创建的bean实例都是CanalInstanceWithSpring，但是工作方式却是不同的，因为在不同的配置文件中，eventParser、eventSink、eventStore、metaManager这几个属性引用的具体实现不同。

 

memory-instance.xml

所有的组件(parser , sink , store)都选择了内存版模式，记录位点的都选择了memory模式，重启后又会回到初始位点进行解析

特点：速度最快，依赖最少(不需要zookeeper)

场景：一般应用在quickstart，或者是出现问题后，进行数据分析的场景，不应该将其应用于生产环境 

1. <bean id="metaManager" class="com.alibaba.otter.canal.meta.MemoryMetaManager" />
2. <bean id="eventStore" class="com.alibaba.otter.canal.store.memory.MemoryEventStoreWithBuffer">
3.    ...
4. </bean>
5. <bean id="eventSink" class="com.alibaba.otter.canal.sink.entry.EntryEventSink">
6.    <property name="eventStore" ref="eventStore" />
7. </bean>
8.  
9. <bean id="eventParser" class="com.alibaba.otter.canal.parse.inbound.mysql.MysqlEventParser”>
10. ...
11. </bean>

 

file-instance.xml

所有的组件(parser , sink , store)都选择了基于file持久化模式，注意，不支持HA机制.

特点：支持单机持久化

场景：生产环境，无HA需求，简单可用. 

1. <bean id="metaManager" class="com.alibaba.otter.canal.meta.FileMixedMetaManager">
2.    <property name="dataDir" value="${canal.file.data.dir:../conf}" />
3.    <property name="period" value="${canal.file.flush.period:1000}" />
4. </bean>
5. <bean id="eventStore" class="com.alibaba.otter.canal.store.memory.MemoryEventStoreWithBuffer">
6.    ...
7. </bean>
8. <bean id="eventSink" class="com.alibaba.otter.canal.sink.entry.EntryEventSink">
9.    <property name="eventStore" ref="eventStore" />
10. </bean>
11.  
12. <bean id="eventParser" class="com.alibaba.otter.canal.parse.inbound.mysql.MysqlEventParser”>
13. ...
14. </bean>

    在这里，有一点需要注意，目前开源版本的eventStore只有基于内存模式的实现，因此官方文档上说store也是基于file持久化的描述是错误的。

 

default-instance.xml：

所有的组件(parser , sink , store)都选择了持久化模式，目前持久化的方式主要是写入zookeeper，保证数据集群共享.

特点：支持HA

场景：生产环境，集群化部署. 

1. <!--注意，由于default-instance.xml支持同ZK来进行HA保障，所以多了此项配置-->
2. <bean id="zkClientx" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean" >
3.    <property name="targetClass" value="com.alibaba.otter.canal.common.zookeeper.ZkClientx" />
4.    <property name="targetMethod" value="getZkClient" />
5.    <property name="arguments">
6.       <list>
7.          <value>${canal.zkServers:127.0.0.1:2181}</value>
8.       </list>
9.    </property>
10. </bean>
11.  
12. <bean id="metaManager" class="com.alibaba.otter.canal.meta.PeriodMixedMetaManager">
13.    <property name="zooKeeperMetaManager">
14.       <bean class="com.alibaba.otter.canal.meta.ZooKeeperMetaManager">
15.          <property name="zkClientx" ref="zkClientx" />
16.       </bean>
17.    </property>
18.    <property name="period" value="${canal.zookeeper.flush.period:1000}" />
19. </bean>
20. <bean id="eventStore" class="com.alibaba.otter.canal.store.memory.MemoryEventStoreWithBuffer">
21.    ...
22. </bean>
23. <bean id="eventSink" class="com.alibaba.otter.canal.sink.entry.EntryEventSink">
24.    <property name="eventStore" ref="eventStore" />
25. </bean>
26. <bean id="eventParser" class="com.alibaba.otter.canal.parse.inbound.mysql.MysqlEventParser”>
27. ...
28. </bean>

 

group-instance.xml：

主要针对需要进行多库合并时，可以将多个物理instance合并为一个逻辑instance，提供客户端访问。

场景：分库业务。 比如产品数据拆分了4个库，每个库会有一个instance，如果不用group，业务上要消费数据时，需要启动4个客户端，分别链接4个instance实例。使用group后，可以在canal server上合并为一个逻辑instance，只需要启动1个客户端，链接这个逻辑instance即可. 

1. <bean id="metaManager" class="com.alibaba.otter.canal.meta.MemoryMetaManager" />
2. <bean id="eventStore" class="com.alibaba.otter.canal.store.memory.MemoryEventStoreWithBuffer">
3.    ...
4. </bean>
5. <bean id="eventSink" class="com.alibaba.otter.canal.sink.entry.EntryEventSink">
6.    <property name="eventStore" ref="eventStore" />
7. </bean>
8. <bean id="eventParser" class="com.alibaba.otter.canal.parse.inbound.group.GroupEventParser">
9.    <property name="eventParsers">
10.       <list>
11.          <ref bean="eventParser1" />
12.          <ref bean="eventParser2" />
13.       </list>
14.    </property>
15. </bean>

    细心的读者会发现，这几个不同的spring配置文件中，最主要的就是metaManager 和eventParser 这两个配置有所不同，eventStore 、和eventSink 定义都是相同的。这是因为：

eventStore：目前的开源版本中eventStore只有一种基于内存的实现，所以配置都相同

eventSink：其作用是eventParser和eventStore的链接器，进行数据过滤，加工，分发的工作。不涉及存储，也就没有必要针对内存、file、或者zk进行区分。

 

    最后，上面只是列出了这几个模块spring配置文件不同定义，特别的针对metaManager和eventParser具体属性配置都没有介绍，我们将会在相应模块的源码分析中进行讲解。