软件架构之冷热分离

冷热分离

冷热分离就是在处理数据时将数据库分成冷库和热库 2 个库，冷库指存放那些走到了终态的数据的数据库，热库指存放还需要修改的数据的数据库。

什么情况下使用冷热分离？

假设你的业务需求出现了如下情况，就可以考虑使用冷热分离的解决方案：
数据走到终态后，只有读没有写的需求，比如订单完结状态；
用户能接受新旧数据分开查询，比如有些电商网站默认只让查询 3 个月内的订单，如果你要查询 3 个月前的订单，还需要访问另外的单独页面。

整体实现思路

（一）如何判断一个数据到底是冷数据还是热数据？

主要采用主表里的 1 个或多个字段组合的方式作为区分标识。例如时间维度，订单状态等
2 个注意要点必须说明
如果一个数据被标识为冷数据，业务代码不会再对它进行写操作；
不会同时存在读冷/热数据的需求。

（二）如何触发冷热数据分离？

修改写操作的业务代码：建议在业务代码比较简单，并且不按照时间区分冷热数据时使用。
监听数据库变更日志：建议在业务代码比较复杂，不敢随意变更，并且不按照时间区分冷热数据时使用。
定时扫描数据库：建议在按照时间区分冷热数据时使用。

（三）如何实现冷热数据分离？

基本逻辑

• 判断数据是冷是热；
• 将要分离的数据插入冷数据库中；
• 再从热数据库中删除分离的数据。

几个问题

• （1）一致性：同时修改多个数据库，如何保证数据的一致性？

  加标识
  flag=pending
  找出所有待搬的数据（ColdFlag=pending）
  冷数据库中保存一份数据，如果存在，继续
  热数据库中删除对应的数据

• （2）数据量：假设数据量大，一次性处理不完，该怎么办？是否需要使用批量处理？

  每次执行上述操作50条

• （3）并发性：假设数据量大到要分到多个地方并行处理，该怎么办？

  多线程同时搬运冷热数据
  第 1 步：如何启动多线程？
  设置多个定时器，并让每个定时器之间的间隔短一些，然后每次定时启动一个线程就开始搬运数据。
  自建一个线程池，然后定时触发后面的操作：先计算待搬动的热数据的数量，再计算要同时启动的线程数，如果大于线程池的数量就取线程池的线程数，假设这个数量为 N，最后循环 N 次启动线程池的线程搬运冷热数据。
  第 2 步：某线程宣布某个数据正在操作，其他线程不要动（锁）。
  获取锁的原子性
  先在表中加上 LockThread 和 LockTime 两个字段，然后通过一条 SQL 语句找出待迁移的未加锁或锁超时的数据，再更新 LockThread=当前线程，LockTime=当前时间，最后利用 MySQL 的更新锁机制实现原子性。
  获取锁必须与开始处理保证一致性
  当前线程开始处理这条数据时，需要再次检查下操作的数据是否由当前线程锁定成功，实际操作为再次查询一下 LockThread= 当前线程的数据，再处理查询出来的数据。
  释放锁必须与处理完成保证一致性
  当前线程处理完数据后，必须保证锁释放出去
  第 3 步：某线程正常处理完后，数据不在热库，直接跑到了冷库
  第 4 步：某线程失败退出了，结果锁没释放怎么办（锁超时）？
  锁无法释放
  给锁设置一个超时时间，如果锁超时了还未释放，其他线程可正常处理该数据。
  尽量给超时的时间设置成超过处理数据的合理时间，且处理冷热数据的代码里必须保证是幂等性的。
  单线程 batch size 到一定数值时效率特别高，比多线程任何 batch size 都快。

（四）如何使用冷热数据？

在功能设计的查询界面上，一般都会有一个选项供我们选择需要查询冷数据还是热数据，如果界面上没有提供，我们可以直接在业务代码里区分。（说明：在判断是冷数据还是热数据时，我们必须确保用户不允许有同时读冷热数据的需求。）

缺点

用户查询冷数据速度依旧很慢，如果查询冷数据的用户比例很低，比如只有 1%，那么这个方案就没问题。
业务无法再修改冷数据，因为冷数据多到一定程度时，系统承受不住。（这点可以通过冷库再分库来解决