canal是一个订阅消费模式的服务，于是其消费位点的控制就非常重要，在正常情况或者重启canal之后都要保证不重复消费同一个位点，也不能漏掉某一个位点。本文我们来看看canal是如何控制消费位点的。

经过前文canal——代码初读的分析，我们对canal的工作流程有了初步的了解。本文，我们来分析canal的monitor机制。

canal是阿里巴巴开发的，用于解析数据库日志的工具，提供增量数据订阅和消费。目前主要支持mysql。

canal的原理并不复杂：模拟mysql slave协议，将自己伪装为slave，收到log之后进行解析然后发送给应用程序。参考：canal产品介绍

canal在我们公司的主要用途是同步mysql数据到ElasticSearch。目前需要基于canal做二次开发，因此需要熟悉canal的源码。本文是对canal源码的初读。

在前面的文章中，我们分别分析了Netty的启动过程以及NioEventLoop的工作流程。本文我们来分析Netty怎样处理新连接的接入。

基于ElasticSearch的搜索功能开发过程中，数据的实时同步是一个非常关键的步骤。

从代码的解耦角度来考虑，业务代码不会直接往ES写数据，而仅仅是查询ES。业务代码将数据更新到Mysql，然后由单独的同步程序同步到ES。我们采用的方式如下：

1. 使用阿里开源的canal监听mysql的binlog
2. 将binlog解析过的数据发送到Kafka
3. 同步程序从Kafka中读数据
4. 构造数据插入到ES中

在我们后端开发中，经常使用redis作为缓存。常见的redis使用场景一般是这样的：使用sorted set存储有序列表，key存储的是数据的id，score作为列表的排序依据；使用字符串存储详细数据的json，key存储的是数据的id。这样我们就可以通过redis获得列表数据的id值，然后使用id去redis中获取数据的详细值。

在这样的使用方式下，每一次的接口请求都需要几十次的redis请求。因为redis占用了连接池资源并且存在固定的网络传输消耗，在读多写少的场景下，大量的redis请求造成的性能损失还是相当可观的。

为了减少的redis访问次数，提升效率，我们需要借助redis的pipeline功能。

Spring的事件通知机制是一项很有用的功能，使用事件机制我们可以将相互耦合的代码解耦，从而方便功能的修改与添加。本文我来学习并分析一下Spring中事件的原理。

火焰图是程序性能分析的一款工具，借助火焰图我们可以比较直观地分析出CPU耗时，了解瓶颈在哪里。

在我们后端开发的过程中，对于数据的存储和处理一般采用这样的一个套路：首先有一个Bean和数据库中的数据相对应，另外有多个对应的DTO和前端数据进行通信。这样可以保证数据库的字段保持稳定，和前端的数据通信格式可以灵活改变。

这几天在开发一个内部SDK的过程中遇到一个问题：SDK需要请求很多的HTTP接口，如果在我们的逻辑代码中直接进行HTTP接口的请求会使得代码的耦合性非常高，同时也需要写大量的代码来进行HTTP请求的配置、响应的处理。这促使我去寻找更加通用的工具来满足需求。