1、什么是冷热分离
冷热分离就是在处理的数据的时将数据分成冷库和热库，冷库存放的是已经走到最终状态的数据，同时也是不常使用的数据；热库存放的未走到最终状态的数据，还需要在进行变更的、经常使用的数据。
2、什么情况下要使用冷热分离
假设业务需求出现了以下情况，就可以考虑使用冷热分离的解决方案。
数据走到终态后只有读没有写的需求，比如订单完结状态。
用户能接受新旧数据分开查询，比如有些电商网站默认只让查询3个月内的订单，如果要查询3个月前的订单，还需要访问其他的页面.
3、冷热分离实现思路：冷热数据都用MySQL。
首先我们要解决如下问题：
如何判断一个数据是冷数据还是热数据？
如何触发冷热数据分离？
如何实现冷热数据分离？
如何使用冷热数据？
历史数据如何迁移。
接下来看看我们如何处理上面的问题。
3.1、如何判断一个数据是冷数据还是热数据？
一般而言，在判断一个数据到底是冷数据还是热数据时，主要采用主表里一个字段或多个字段的组合作为区分标识。
这个字段可以是时间维度，比如订单的下单时间，可以把3个月前的订单数据当作冷数据，3个月内的订单数据当作热数据。当然，这个字段也可以是状态维度，比如根据订单状态字段来区分，将已完结的订单当作冷数据，未完结的订单当作热数据。
还可以采用组合字段的方式来区分，比如把下单时间小于3个月且状态为已完结的订单标识为冷数据，其他的当作热数据。而在实际工作中，最终使用哪种字段来判断，还是需要根据实际业务来决定的。
注意：
如果一个数据被标识为冷数据，业务代码不会再对它进行写操作。
不会同时存在读取冷、热数据的需求。
3.2、如何触发冷热数据分离？
方案一
直接修改业务代码，使得每次修改数据时触发冷热分离（比如每次更新订单的状态时，就去触发这个逻辑）。
修改写操作的业务代码建议在业务代码比较简单，并且不按照时间区分冷热数据时使用
场景示例：假设是根据订单的状态来区分冷热数据，订单的状态不会随着时间自动变化，必须有人去修改才会变化，并且很容易找出所有修改订单状态的业务代码，这种情况下可以用这种触发逻辑。
方案二
如果不想修改原来的业务代码，可以通过监听数据库变更日志binlog的方式来触发。具体方法就是另外创建一个服务，这个服务专门用来监控数据库的binlog，一旦发现ticket表有变动，就将变动的订单数据发送到一个队列，这个队列的订阅者将会取出变动的订单，触发冷热分离逻辑。
监听数据库变更日志建议在业务代码比较复杂，不能随意变更，并且不按时间区分冷热数据时使用。
假设是根据订单的状态来区分冷热数据，订单的状态不会随着时间自动变化，必须有人去修改才会变化。其不一样的地方在于，业务代码很复杂，特别是有些用了很多年的系统中，修改订单状态的代码分布在多个位置，甚至多个服务中，不可能都找到，并且因为难以评估影响面，所以修改起来风险很大。这种情况下就适合使用监听数据库变更日志的方式。
方案三
通过定时扫描数据库的方式来触发。这个方式就是通过quartz配置一个本地定时任务，或者通过类似于xxl-job的分布式调度平台配置一个定时任务。这个定时任务每隔一段时间就扫描一次热数据库里面的订单表，找出符合冷数据标准的订单数据，进行冷热分离。
定时扫描数据库建议在按照时间区分冷热数据时使用。
比如业务需求是已经关闭超过1个月的订单视为冷数据，这种场景下，订单变更的那一瞬间，即使订单已经关闭了，也不能将其视为冷数据，而必须再等待1个月。这样的情况非常适合使用定时扫描。
当决定了冷热分离的触发方式后，就进入下一个决策点：如何分离冷热数据。整个方案最复杂的环节就是这里。
1.3.3、如何分离冷热数据？
在讲解如何分离冷热数据之前，先来了解一下分离冷热数据的基本逻辑，只有掌握了基本原理，才能真正理解事物的本质。
判断数据是冷是热。
将要分离的数据插入冷数据库中。
从热数据库中删除分离的数据。
评论区