怎样将mysql窄表实时同步成宽表

比如BBS，可以用帖子的URL地址作为ROWKEY保存

而后面的每一个回复，作为单独的COLUMNS

回复越多，COLUMNS就越多，表就变宽了

COLUMNS的qualifier名称设计很简单

假设你的表 FC = "_0"

前言

上篇文章简单介绍canal概念，本文结合常见的缓存业务去讲解canal使用。在实际开发过程中，通常都会把数据往redis缓存中保存一份，做下简单的查询优化。如果这时候数据库数据发生变更 *** 作，就不得不在业务代码中写一段同步更新redis的代码，但是这种 数据同步的代码和业务代码糅合在一起 看起来不是很优雅，而且还会出现数据不一致问题。那能不能把这部分同步代码从中抽离出来，形成独立模块呢？答案是肯定的，下面通过canal结合Kafka来实现mysql与redis之间的数据同步。

架构设计

通过上述结构设计图可以很清晰的知道用到的组件：MySQL、Canal、Kafka、ZooKeeper、Redis。

Kafka&Zookeeper搭建

首先在 官网 下载Kafka：

下载后解压文件夹，可以看到以下几个文件：

Kafka内部自带了zookeeper，所以暂不需要去下载搭建zookeeper集群，本文就使用Kafka自带zookeeper来实现。

通过上述zookeeper启动命令以及Kafka启动命令把服务启动，可以通过以下简单实现下是否成功：

Canal搭建

canal搭建具体可以参考上文，这里只讲解具体的参数配置：

找到/conf目录下的canal.properties配置文件：

然后配置instance，找到/conf/example/instance.properties配置文件：

经过上述配置后，就可以启动canal了。

测试

环境搭建完成后，就可以编写代码进行测试。

1、引入pom依赖

2、封装Redis工具类

在application.yml文件增加以下配置：

封装一个 *** 作Redis的工具类：

3、创建MQ消费者进行同步

创建一个CanalBean对象进行接收：

最后就可以创建一个消费者CanalConsumer进行消费：

测试Mysql与Redis同步

mysql对应的表结构如下：

启动项目后，新增一条数据：

可以在控制台看到以下输出：

如果更新呢？试一下Update语句：

同样可以在控制台看到以下输出：

经过测试完全么有问题。

总结

既然canal这么强大，难道就没缺点嘛？答案当然是存在的啦，比如：canal只能同步增量数据、不是实时同步而是准实时同步、MQ顺序问题等； 尽管有一些缺点，毕竟没有一样技术或者产品是完美的，最重要是合适。比如公司目前有个视图服务提供宽表搜索查询功能就是通过 同步Mysql数据到Es采用Canal+Kafka的方式来实现的。

你那些极限参数我都没有去给你查，有兴趣自己到MYSQL网站查询，或者给开发团队发MAIL。因为我认为开发团队设计的极限参数，肯定可以应对绝大多数情况，即使有点变态。比如表的个数，我认为几千甚至万把个表，MYSQL也能转起来，字段数也是如此。

表太多的库，一般情况下没什么大的问题，也不是很有必要划分为多个库。除非这个库里面，许多表是平时基本上不使用的，少数表是需要反复频繁使用的，那么有必要把频繁使用的表移到一个库里面。因为 *** 作系统一般对目录下的文件是不排序的，数据库请求 *** 作系统打开某文件的时候， *** 作系统实际上是顺序搜索目录表（FDT），这样当目录下的文件数太多的时候，效率会很差。经过我自己的实验，在WINDOWS下当文件个数达到5000左右的时候我无法忍受，在FREEBSD下也差不多。

字段数较多的表，在数据库理论里面称为宽表。它是有的情况下必须要有的，比如我什么零件库，零件的参数就有上千个，是正常的。一般我们不需要把宽表划分为几个表，因为程序会变得复杂，而每次查询都需要关联多表，更新更是麻烦。

但是在某些情况下，把宽表进行划分是有效的。比如一部分字段是比较固定的，而另外一些字段是需要反复更新的。把需要反复更新的字段单独分为一个表，能提高更新的效率，也能减少更新期间系统故障时带来的风险。

对宽表的划分，应该照顾逻辑属性。比如对论坛的表进行划分，可以把论坛ID、标题等固定属性分为一个表，而把论坛状态、最后回复者、帖子数等状态属性分为一个表。

对于基本上不需要修改的表，无论字段有好多，也无论文件有多大，都没有必要划分为多个表。

---