表数据量大读写缓慢如何优化（1）【冷热分离】

今天讨论的内容是冷热分离，也许概念并不陌生，对其使用场景也比较熟悉，但涉及锁的内容时仍然须要认真思考，这部份内容在咱们实际开发中的“坑”仍是很多的。

业务场景一

曾经经历过供应链相关的架构优化，当时平台上有一个订单功能，里面的主表有几千万数据量，加上关联表，数据量达到上亿。
这么庞大的数据量，让平台的查询订单变得格外迟缓，查询一次都要二三十秒，并且多点击几回就会出现宕机。好比业务员屡次查询时，数据库的 CPU 会立马狂飙，服务器线程也降不下来。

当时，咱们尝试了优化表结构、业务代码、索引、SQL 语句等办法来提升响应速度，但这些方法治标不治本，查询速度仍是很慢。

考虑到咱们手头上还有其余优先级高的需求须要处理，为此，咱们跟业务方反馈：“这功能之后大家能不用就不用，暂时先忍受一下。”可通过一段时间后，业务方实在受不了了，直接跟咱们放狠话，无奈之下咱们屈服了。

最终，咱们决定采用一个性价比高的解决方案，简单方便地解决了这个问题。在处理数据时，咱们将数据库分红了冷库和热库 2 个库，不经常使用数据放冷库，经常使用数据放热库。

经过这样的方法处理后，由于业务员查询的基本是近期经常使用的数据，经常使用的数据量大大减小了，就不再会出现宕机的状况了，也大大提高了数据库响应速度。

其实上面这个方法，就是“冷热分离”。

1、什么是冷热分离

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

2、什么状况下使用冷热分离？

假设业务需求出现了以下状况，就能够考虑使用冷热分离的解决方案：

• 数据走到终态后，只有读没有写的需求，好比订单完结状态；
• 用户能接受新旧数据分开查询，好比有些电商网站默认只让查询3个月内的订单，若是你要查询3个月前的订单，还须要访问另外的单独页面。

3、冷热分离实现思路

在实际操做过程当中，冷热分离总体实现思路以下：

一、如何判断一个数据究竟是冷数据仍是热数据？

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

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

四、如何使用冷热数据？

接下来，咱们针对以上4个问题进行详细的分析。

（一）如何判断一个数据究竟是冷数据仍是热数据？

通常而言，在判断一个数据究竟是冷数据仍是热数据时，咱们主要采用主表里的 1 个或多个字段组合的方式做为区分标识。其中，这个字段能够是时间维度，好比“下单时间”这个字段，咱们能够把 3 个月前的订单数据看成冷数据，3 个月内的看成热数据。

固然，这个字段也能够是状态维度，好比根据“订单状态”字段来区分，已完结的订单看成冷数据，未完结的订单看成热数据。

咱们还能够采用组合字段的方式来区分，好比咱们把下单时间 > 3 个月且状态为“已完结”的订单标识为冷数据，其余的看成热数据。

而在实际工做中，最终究竟使用哪一种字段来判断，仍是须要根据你的实际业务来定。

关于判断冷热数据的逻辑，这里还有 2 个注意要点必须说明：

• 若是一个数据被标识为冷数据，业务代码不会再对它进行写操做；
• 不会同时存在读冷/热数据的需求。

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

了解了冷热数据的判断逻辑后，咱们就要开始考虑如何触发冷热数据分离了。通常来讲，冷热数据分离的触发逻辑分3种。

一、直接修改业务代码，每次修改数据时触发冷热分离（好比每次更新了订单的状态，就去触发这个逻辑）；

二、若是不想修改原来业务代码，可经过监听数据库变动日志binlog的方式来触发（数据库触发器也可）；

三、经过定时扫描数据的方式来触发（数据库定时任务或经过程序定时任务来触发）；

针对以上三种触发逻辑，选择哪一种比较好呢？看完如下表格的分析，你内心就有答案了。

	修改写操做的业务代码	监听数据库变动日志	定时扫描数据库
优势	一、代码灵活可控。二、保证明时性	一、与业务代码解耦。二、能够作到低延时。	一、与业务代码解耦。二、能够覆盖根据时间区分冷热数据的场景。
缺点	一、不能按照时间区分冷热，当数据变为冷数据，期间可能没有进行任何操做。二、须要修改全部数据写操做的代码。	一、没法按照时间区分冷热，当数据变为冷数据，期间没有进行任何操做。二、须要考虑数据并发操做的问题，即业务代码与冷热变动代码同时操做同一数据。	一、不能作到实时性

根据表格内容对比，咱们能够得出每种出发逻辑的建议场景。

1. 修改写操做的业务代码：建议在业务代码比较简单，而且不按照时间区分冷热数据时使用。
2. 监听数据库变动日志：建议在业务代码比较复杂，不能随意变动，而且不按照时间区分冷热数据时使用。
3. 定时扫描数据库：建议在按照时间区分冷热数据时使用。

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

分离冷热数据的基本逻辑以下：

一、判断数据是冷是热；

二、将要分离的数据插入冷数据中；

三、再从热数据库中删除分离的数据。

这个逻辑看起来简单，而实际作方案时，如下三点咱们都得考虑在内，这一点就不简单了。

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

​ 这里提到的一致性要求，指咱们如何保证任何一步出错后数据仍是一致的，解决方案为只要保证每一步均可以重试且操做都有幂等性就行，具体逻辑分为四步。

• 在热数据库中，给要搬的数据加个标识： flag=1。（1表明冷数据，0表明热数据）

• 找出全部待搬的数据（flag=1）：这步是为了确保前面有些线程由于部分缘由失败，出现有些待搬的数据没有搬的状况。

• 在冷数据库中保存一份数据，但在保存逻辑中需加个判断以此保证幂等性（这里须要用事务包围起来），通俗点说就是假如咱们保存的数据在冷数据库已经存在了，也要确保这个逻辑能够继续进行。

• 从热数据库中删除对应的数据。

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

​ 前面说的3种冷热分离的触发逻辑，前 2 种基本不会出现数据量大的问题，由于每次只须要操做那一瞬间变动的数据，但若是采用定时扫描的逻辑就须要考虑数据量这个问题了。

​ 这个实现逻辑也很简单，在搬数据的地方咱们加个批量逻辑就能够了。为方便理解，咱们来看一个示例。

​ 假设咱们每次能够搬 50 条数据：

​ a. 在热数据库中给要搬的数据加个标识：flag=1；

​ b. 找出前 50 条待搬的数据（flag=1）；

​ c. 在冷数据库中保存一份数据；

​ d. 从热数据库中删除对应的数据；

​ e. 循环执行 b。

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

​ 在定时搬运冷热数据的场景里（好比天天），假设天天处理的数据量大到连单线程批量处理都来不及，咱们该怎么办？这时咱们就能够开多个线程并发处理了。(虽然大部分状况下多线程较快，但我曾碰到过这种状况：当单线程 batch size 到必定数值时效率特别高，比多线程任何 batch size 都快。因此，须要留意：若是遇到多线程速度不快，咱们就考虑控制单线程。)

​ 当多线程同时搬运冷热数据，咱们须要考虑以下实现逻辑。

​ 第 1 步：如何启动多线程？

​ 由于咱们采用的是定时器触发逻辑，这种触发逻辑性价比最高的方式是设置多个定时器，并让每一个定时器之间的间隔短一些，而后每次定时启动一个线程就开始搬运数据。

​ 还有一个比较合适的方式是自建一个线程池，而后定时触发后面的操做：先计算待搬动的热数据的数量，再计算要同时启动的线程数，若是大于线程池的数量就取线程池的线程数，假设这个数量为 N，最后循环 N 次启动线程池的线程搬运冷热数据。

​ 第 2 步：某线程宣布某个数据正在操做，其余线程不要动（锁）。

​ 关于这个逻辑，咱们须要考虑 3 个特性。

• 获取锁的原子性： 当一个线程发现某个待处理的数据没有加锁，而后给它加锁，这 2 步操做必须是原子性的，即要么一块儿成功，要么一块儿失败。实际操做为先在表中加上 LockThread 和 LockTime 两个字段，而后经过一条 SQL 语句找出待迁移的未加锁或锁超时的数据，再更新 LockThread=当前线程，LockTime=当前时间，最后利用 MySQL 的更新锁机制实现原子性。

• 获取锁必须与开始处理保证一致性： 当前线程开始处理这条数据时，须要再次检查下操做的数据是否由当前线程锁定成功，实际操做为再次查询一下 LockThread= 当前线程的数据，再处理查询出来的数据。

• 释放锁必须与处理完成保证一致性： 当前线程处理完数据后，必须保证锁释放出去。

  第 3 步：某线程正常处理完后，数据不在热库，直接跑到了冷库，这是正常的逻辑，倒没有什么特别须要注意的点。

  第 4 步：某线程失败退出了，结果锁没释放怎么办（锁超时）？

  锁没法释放： 若是锁定这个数据的线程异常退出了且来不及释放锁，致使其余线程没法处理这个数据，此时该怎么办？解决方案为给锁设置一个超时时间，若是锁超时了还未释放，其余线程可正常处理该数据。

  设置超时时间时，咱们还应考虑若是正在处理的线程并未退出，因还在处理数据致使了超时，此时又该怎么办？解决方案为尽可能给超时的时间设置成超过处理数据的合理时间，且处理冷热数据的代码里必须保证是幂等性的。

  ​ 最后，咱们还得考虑一个极端状况：若是当前线程还在处理数据，此时正在处理的数据的锁超时了，另一个线程把正在处理的数据又进行了加锁，此时该怎么办？咱们只须要在每一步加判断容错便可，由于搬运冷热数据的代码比较简单，经过这样的操做当前线程的处理就不会破坏数据的一致性。

（四）如何使用冷数据

​ 在功能设计的查询界面上，通常都会有一个选项供咱们选择须要查询冷数据仍是热数据，若是界面上没有提供，咱们能够直接在业务代码里区分。（说明：在判断是冷数据仍是热数据时，咱们必须确保用户不容许有同时读冷热数据的需求。）

历史数据如何迁移？
通常而言，只要跟持久化层有关的架构方案，咱们都须要考虑历史数据的迁移问题，即如何让旧架构的历史数据适用于新的架构？

​ 由于前面的分离逻辑在考虑失败重试的场景时，恰好覆盖了这个问题，因此这个问题的解决方案也很简单，咱们只须要给全部的历史数据加上标识：flag=1 后，程序就会自动迁移了。

冷热分离解决方案的不足

​ 不得不说，冷热分离解决方案确实能解决写操做慢和热数据慢的问题，但仍然存在诸多不足。

​ 不足一： 用户查询冷数据速度依旧很慢，若是查询冷数据的用户比例很低，好比只有 1%，那么这个方案就没问题。

​ 不足二： 业务没法再修改冷数据，由于冷数据多到必定程度时，系统承受不住。（这点能够经过冷库再分库来解决，后面再来探讨）