冷热分离
当数据库表数据体量大，即使是做了很多SQL层面的优化(索引、执行计划、优化语句、表结构设计)读写依然很慢可以考虑从冷热数据分离去提高速度
热数据：对用户而言，是需要经常用到的数据。从数据获取后需要快速反应面向用户/系统使用，数据需要保持质量和稳定、有效。
在数据处理层面上也是优先的。
比如：在订单系统中，还未完成的订单中的数据可以认为是热数据，及时反应给用户/系统作查询比对处理
冷数据：不是经常用到的。也可以是历史数据，对业务进度影响不大，可以用做离线处理的数据。
比如：订单中已经完成的数据，我们需要对订单数据做聚合统计，订单庞大，统计分析时间长，但是无需给用户做出立刻的反应。
冷热分离：冷数据和热数据的最终形态(通过一系列业务处理后)存放在冷库和热库中，分别存储。
注意：
冷热分离数据的特效有：
1) 如果一个数据被标记为冷数据，我们可以认为：我们不会对它再进行业务操作(UPDATE、DELETE操作)
2) 不会同时的对冷热数据进行读取操作
冷热分离确实可以在某种程度上解决写读写数据慢的问题，但是仍然存在诸多不足。具体表现有：
1）用户查询冷数据速度依旧很慢。
2）由于冷数据多到一定程度，业务就无法再修改冷数据，因为数据量太大系统承受不住。
实现方案1：修改业务代码
在业务层就去判断冷热数据，触发分离，可以使用触发器等。（同步/异步根据业务逻辑进行具体考量）
比如TIMESTAMPDIFF某个字段到现在已经有一定的时间了，可以认为他是冷数据，我们就从热库中删除，在冷库中写入，
从而减少了热库的数据量。但缺点就是需要不断的运行维护，对代码的侵入性比较高。
实现方案2：CDC（Change Data Capture 变更数据获取）
监测并捕获数据库的变动（包括数据 或 数据表的插入INSERT、更新UPDATE、删除DELETE等）
将这些变更按发生的顺序完整记录下来，写入到消息中间件中以供其他服务进行订阅及消费。
基于查询的CDC：Sqoop、Kafka JDBC source等（后面学习）
基于Binlog的CDC：Canal、Debezium等
canal 作为 MySQL binlog 增量获取和解析工具，可将变更记录投递到 MQ 系统中，比如 Kafka/RocketMQ，可以借助于 MQ 的多语言能力(主要用于解决异构通信问题)。
MySQL主备复制原理
Mysql的Master将数据变更写入binlog，Slave就将binlog拷贝到Slave的中继日志relaylog，通过relaylog同步做到主从备份
- canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
- MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
- canal 解析 binary log 对象(原始为 byte 流)
实现方案3：定时任务扫描
通常使用Springboot的Quartz 或者 Python的Schedule库写脚本，来对库表数据进行定时扫描和处理，
当条件满足后做数据状态的变更或者产生新的数据插入到表中。
这个有很多考量，值得后面再去应对业务深挖。
总结：解决读写缓慢冷热分离是个有效的手段，但是数据一致性如何保证也是一个问题
标签：canal,冷热,分离,业务,笔记,MySQL,数据,数据库 From： https://www.cnblogs.com/leehl8016/p/16784142.html