测试canal的数据堆积能力，如果canal可以堆积数据，那么就不需要消息队列来堆积。

测试canal的数据堆积能力，如果canal可以堆积数据，那么就不需要消息队列来堆积。

结果发现

1. 如果不确认数据，每次连接后都会从第一次获取，但是由于canal不能根据时间获取数据，所以也是不方便的。

2. 由于canal会维护一个连接的clientId，所以已经连接的会一直获取的是下一次下一次的数据，是连续的数据。只要不确认数据，重新添加一个连接时，都会获取到完整的数据。

3. 另外，canal默认使用的是file-instance.xml，所以即便canal被kiil -9了，再启动，数据也是依然会存在的。

4. 依据以上几点，如果乐意的话，可以考虑记录batchId和时间，自己实现一个可以堆积很多天的数据，然后依据时间点进行确认数据。

5. 今天听了演讲《全球开发者大会》的艺龙旅游的实时价格搜索架构。他们每1个小时进行一次全量索引，每1分钟会有增量索引，每秒会有实时索引（他们的这个是从数据库拉取的，或者使用了阿里的canal或其它类似软件而没有说出来）。

6. 所以基于以上几点，如果canal在堆积在大量数据后不会挂掉，也许可以考虑自己写。

7. 实验发现，canal在同步更新数据时，大约堆积数据超过10万时，速度会变慢，超过20万时就非常非常慢了。而在同步插入数据时，只要1万条就会导致假死，这时，必需确认数据后，才会继续获取到同步数据。

8. 另外，由于数据堆积并且canal没有提供可以通过时间点获取数据，所以会在重新连接后一次性获取到所有数据，这就会导致获取数据非常慢非常慢，甚至卡死。（要不就自己扩展源码实现时间点，但是canal堆积数据能力真的不行）

9. 最终结果证实，在canal中所以这种方式是不现实的。无论canal的内存是1G还是4G，结果是一样的。所以还是需要使用消息队列进行数据堆积，这样的消息队列有Kafka和RocketMQ等。

10. 关于Kafka和RocketMQ的数据堆积能力，大公司们已经验证过了，不过关于我们的使用，我会再一次验证。