软件架构场景-数据持久化层

最新推荐文章于 2024-03-08 10:44:12 发布

gonghaiyu

最新推荐文章于 2024-03-08 10:44:12 发布

阅读量890

点赞数

分类专栏： Java 架构设计

本文链接：https://blog.csdn.net/gonghaiyu/article/details/113917762

版权

Java 同时被 2 个专栏收录

72 篇文章 4 订阅

订阅专栏

架构设计

6 篇文章 0 订阅

订阅专栏

本部分内容包括：
（1）数据持久化层场景
（2）缓冲层场景
（3）基于常用组件的微服务场景及微服务踩坑
（4）开发运维场景

数据持久化层场景

场景1：冷热分离

订单功能，里面的主表有几千万的数据量，加上关联表，数据量达到上亿。因为业务员查询的基本是近期常用的数据，常用的数据量大大减少了，可以使用"冷热分离"。

什么情况下使用冷热分离

1.用户能接受新旧数据分开查询，比如有些电商网站默认只让查询 3 个月内的订单。
2.数据走到终态后，只有读没有写的需求，比如订单完结状态。

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

在判断一个数据到底是冷数据还是热数据时，我们主要采用主表里的 1 个或多个字段组合的方式作为区分标识。比如“下单时间”这个字段，“订单状态”字段。还可以采用组合字段的方式来区分，比如我们把下单时间 > 3 个月且状态为“已完结”的订单标识为冷数据，其他的当作热数据。
总之，最终究竟使用哪种字段来判断，还是需要根据你的实际业务来定。

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

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

如何触发冷热数据分离

冷热数据分离的触发逻辑分 3 种。

直接修改业务代码，每次修改数据时触发冷热分离。
如果不想修改原来的业务代码，可通过监听数据库变更日志 binlog 的方式来触发。
通过定时扫描数据库的方式来触发。

冷热分离 3 种触发逻辑优缺点对比表

根据以上表格内容对比，我们可以得出每种触发逻辑的建议场景。
修改写操作的业务代码：建议在业务代码比较简单，并且不按照时间区分冷热数据时使用。
监听数据库变更日志：建议在业务代码比较复杂，不敢随意变更，并且不按照时间区分冷热数据时使用。
定时扫描数据库：建议在按照时间区分冷热数据时使用。

如何分离冷热数据？

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

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

在这里插入图片描述

该注意的问题

一致性：同时修改多个数据库，如何保证数据的一致性？
一致性的解决方案为只要保证每一步都可以重试且操作都有幂等性就行，具体逻辑分为四步。
（1）在热数据库中，给要搬的数据加个标识： ColdFlag=WaittingForMove。（实际处理中标识字段的值用数字就可以，这里是为了方便理解。）
（2）找出所有待搬的数据（ColdFlag=WaittingForMove）：这步是为了确保前面有些线程因为部分原因失败，出现有些待搬的数据没有搬的情况。
（3）在冷数据库中保存一份数据，但在保存逻辑中需加个判断以此保证幂等性（这里需要用事务包围起来），通俗点说就是假如我们保存的数据在冷数据库已经存在了，也要确保这个逻辑可以继续进行。
（4）从热数据库中删除对应的数据。

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

我们每次可以搬 50 条数据：

在热数据库中给要搬的数据加个标识：ColdFlag=WaittingForMove；
找出前 50 条待搬的数据（ColdFlag=WaittingForMove）；
在冷数据库中保存一份数据；
从热数据库中删除对应的数据；
循环执行 b。

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

在定时搬运冷热数据的场景里（比如每天），假设每天处理的数据量大到连单线程批量处理都来不及，我们该怎么办？这时我们就可以开多个线程并发处理了。(虽然大部分情况下多线程较快，但我曾碰到过这种情况：当单线程 batch size 到一定数值时效率特别高，比多线程任何 batch size 都快。所以，希望同学们到时多留意下，如果遇到多线程速度不快，我们就考虑控制单线程。)

如何启动多线程。有两种方式，一种多进程中的多线程。即设置多个定时器，每个定时器间隔短一些，每次定时启动一个线程。一种是单进程中的多线程，即线程池。先计算待搬动的热数据的数量，再计算要同时启动的线程数，如果大于线程池的数量就取线程池的线程数，假设这个数量为 N，最后循环 N 次启动线程池的线程搬运冷热数据。
某线程宣布某个数据正在操作，其他线程不要动（锁）。
关于这个逻辑，我们需要考虑 3 个特性。
（1）获取锁的原子性：当一个线程发现某个待处理的数据没有加锁，然后给它加锁，这 2 步操作必须是原子性的，即要么一起成功，要么一起失败。实际操作为先在表中加上 LockThread 和 LockTime 两个字段，然后通过一条 SQL 语句找出待迁移的未加锁或锁超时的数据，再更新 LockThread=当前线程，LockTime=当前时间，最后利用 MySQL 的更新锁机制实现原子性。
（2）获取锁必须与开始处理保证一致性：当前线程开始处理这条数据时，需要再次检查下操作的数据是否由当前线程锁定成功，实际操作为再次查询一下 LockThread= 当前线程的数据，再处理查询出来的数据。
（3）释放锁必须与处理完成保证一致性：当前线程处理完数据后，必须保证锁释放出去。
某线程失败退出了，结果锁没释放怎么办（锁超时）？
锁无法释放：如果锁定这个数据的线程异常退出了且来不及释放锁，导致其他线程无法处理这个数据，此时该怎么办？解决方案为给锁设置一个超时时间，如果锁超时了还未释放，其他线程可正常处理该数据。
设置超时时间时，我们还应考虑如果正在处理的线程并未退出，因还在处理数据导致了超时，此时又该怎么办？解决方案为尽量给超时的时间设置成超过处理数据的合理时间，且处理冷热数据的代码里必须保证是幂等性的。
最后，我们还得考虑一个极端情况：如果当前线程还在处理数据，此时正在处理的数据的锁超时了，另外一个线程把正在处理的数据又进行了加锁，此时该怎么办？我们只需要在每一步加判断容错即可，因为搬运冷热数据的代码比较简单，通过这样的操作当前线程的处理就不会破坏数据的一致性。
考虑到前面逻辑比较复杂，这里我们特地画了一个分离的流程图，如下图所示：

如何使用冷热数据？

在界面上可以使用查询条件进行区分，比如最近3个月就是热数据，这种情况我们可以在业务代码中来区分，前提是不允许同时读冷热库的需求。

整体方案

在这里插入图片描述

历史数据迁移

一般而言，只要跟持久化层有关的架构方案，我们都需要考虑历史数据的迁移问题。因为前面的分离逻辑在考虑失败重试的场景时，刚好覆盖了这个问题，所以这个问题的解决方案也很简单，我们只需要给所有的历史数据加上标识：ColdFlag=WaittingForMove 后，程序就会自动迁移了。

场景2：查询分离

冷热分离存在诸多不足，比如：查询冷数据慢、业务无法再修改冷数据、冷数据多到一定程度系统依旧扛不住，我们如果想把这些问题一一解决掉，可以用另外一种解决方案——查询分离。
如：SaaS 客服系统的架构优化，系统里有一个工单查询功能，工单表中存放了几千万条数据，且查询工单表数据时需要关联十几个子表，每个子表的数据也是超亿条。
加上工单表中有些数据是几年前的，客户说这些数据涉及诉讼问题，需要继续保持更新，因此我们无法将这些旧数据封存到别的地方，也就没法通过前面的冷热分离方案来解决。
我们采用了查询分离的解决方案，才得以将这个问题顺利解决：将更新的数据放在一个数据库里，而查询的数据放在另外一个系统里。因为数据的更新都是单表更新，不需要关联也没有外键，所以更新速度立马得到提升，数据的查询则通过一个专门处理大数据量的查询引擎来解决，也快速地满足了客户的需求。

何种场景下使用查询分离？

数据量大；
所有写数据的请求效率尚可；
查询数据的请求效率很低；
所有的数据任何时候都可能被修改；
业务希望我们优化查询数据的功能。

查询分离实现思路

如何触发查询分离？

(1) 修改业务代码：在写入常规数据后，同步写入重库。
在这里插入图片描述
(2) 修改业务代码：在写入常规数据后，异步建立查询数据。可以通过MQ实现异步。

(3) 监控数据库日志：如有数据变更，更新查询数据。

通过观察以上 3 种触发逻辑示意图，你发现了什么吗？3 种触发逻辑的优缺点对比表如下：
在这里插入图片描述
什么叫业务逻辑灵活可控？ 举个例子：一般来说，写业务代码的人能从业务逻辑中快速判断出何种情况下更新查询数据，而监控数据库日志的人并不能将全部的数据库变更分支穷举，再把所有的可能性关联到对应的更新查询数据逻辑中，最终导致任何数据的变更都需要重新建立查询数据。

什么叫减缓写操作速度？ 建立查询数据的一个动作能减缓多少写操作速度？答案：很多。举个例子：当你只是简单更新了订单的一个标识，本来查询数据时间只需要 2ms，而在查询数据时可能会涉及重建（比如使用 ES 查询数据时会涉及索引、分片、主从备份，其中每个动作又细分为很多子动作，这些内容后面我们会讲到），这时建立查询数据的过程可能就需要 1s 了，从 2ms 变成 1s，你说减缓幅度大不大？

查询数据更新前，用户可能查询到过时数据。这里我们结合第 2 种触发逻辑来讲，比如某个操作正处于订单更新状态，状态更新时会通过异步更新查询数据，更新完后订单才从“待审核”状态变为“已审核”状态。假设查询数据的更新时间需要 1 秒，这 1 秒中如果用户正在查询订单状态，这时主数据虽然已变为“已审核”状态，但最终查询的结果还是显示“待审核”状态。

根据前面的对比表，总结每种触发逻辑的适用场景如下：
在这里插入图片描述

如何实现查询分离？

下面重点讲解第2种方式。

写操作较多且线程太多，最终撑爆 JVM；
建查询数据的线程出错了，如何自动重试；
多线程并发时，很多并发场景需要解决。
面对以上三种情况，此时使用 MQ 管理这些线程即可解决。
MQ 的具体操作思路为每次主数据写操作请求处理时，都会发一个通知给 MQ，MQ 收到通知后唤醒一个线程更新查询数据，示意图如下：

问题一：MQ 如何选型？
（1）召集技术中心所有能做技术决策的人共同投票选型。
（2）不管我们选择哪个 MQ ，最终都能实现想要的功能，只不过是易用不易用、多写少写业务代码的问题，因此我们从易用性和代码工作量角度考量即可。
问题二：MQ 宕机了怎么办？
（1）每次写操作时，在主数据中加个标识：NeedUpdateQueryData=true，这样发到 MQ 的消息就很简单，只是一个简单的信号告知更新数据，并不包含更新的数据 id。
（2）MQ 的消费者获取信号后，先批量查询待更新的主数据，然后批量更新查询数据，更新完后查询数据的主数据标识 NeedUpdateQueryData 就更新成 false 了。
（3）当然还存在多个消费者同时搬运动作的情况，这就涉及并发性的问题，因此问题与 01 讲冷热分离中的并发性处理逻辑类似。
（4）但如果一直失败，我们可以在主数据中多添加一个尝试搬运次数，比如每次尝试搬运时 +1，成功后就清零，以此监控那些尝试搬运次数过多的数据。
问题三：消息的幂等消费
RocketMQ和状态控制可以完成幂等操作。

MQ 的作用
服务的解耦：这样主业务逻辑就不会依赖更新查询数据这个服务了。
控制更新查询数据服务的并发量：如果我们直接调用更新查询数据服务，因写操作速度快，更新查询数据速度慢，写操作一旦并发量高，会给更新查询数据服务造成超负荷压力。如果通过消息触发更新查询数据服务，我们就可以通过控制消息消费者的线程数来控制负载。

查询数据如何存储？

我们应该使用什么技术存储查询数据呢？目前，市面上主要使用 Elasticsearch 实现大数据量的搜索查询，当然还可能会使用到 MongoDB、HBase 这些技术，这就需要我们对各种技术的特性了如指掌，再进行技术选型。比如当初我们设计架构方案时，为什么选择用 Elasticsearch，除 ES 对查询的扩展性支持外，最关键的一点是我们团队对 Elasticsearch 很熟悉。

查询数据如何使用？

查询数据不一致怎么办？**这里我分享 2 种解决思路。

在查询数据更新到最新前，不允许用户查询。（我们没用过这种设计，但我确实见过市面上有这样的设计。）
给用户提示：您目前查询到的数据可能是 1 秒前的数据，如果发现数据不准确，可以尝试刷新一下，这种提示用户一般比较容易接受。

整体方案

在这里插入图片描述

历史数据迁移

在这个方案里，我们只需要把所有的历史数据加上这个标识：NeedUpdateQueryData=true，程序就会自动处理了。

查询分离解决方案的不足

查询分离这个解决方案虽然能解决一些问题，但我们也要清醒地认识到它的不足。
不足一：使用 Elasticsearch 存储查询数据时，注意事项是什么（此方案并未详细展开）？
不足二：主数据量越来越大后，写操作还是慢，到时还是会出问题。
不足三：主数据和查询数据不一致时，假设业务逻辑需要查询数据保持一致性呢？

Elasticsearch 注意的三点

对于 Elasticsearch 而言，我们想掌握好这门技术，除需要对它的用法了如指掌外，还需要对技术中的各种坑了然于心。因此，03 讲我结合个人实战经验总结出了关于 ES 的 3 大知识要点：如何使用 Elasticsearch 设计表结构？Elasticsearch 如何修改表结构？ES 的坑有哪些？

如何使用Elasticsearch 设计表结构？

我们知道 ES 是基于索引的设计，它没办法像 MySQL 那样使用 join 查询，所以，查询数据时我们需要把每条主数据及关联子表的数据全部整合在一条记录中。

ES 的存储结构

（1）Lucene 和 MySQL 的概念对比
在这里插入图片描述
（2）无结构文档的倒排索引（Index）

简单倒排索引后，显示的结果如下表所示：

我们发现：无结构的文档经过简单的倒排索引后，字典表主要存放关键字，而倒排表存放该关键字所在的文档 id。
（3）有结构文档的倒排索引（Index）
再来举一个更复杂的例子，比如每个 Doc 都有多个 Field，Field 有不同的值（包含不同的 Term），倒排索引的结构参考如下图所示：
在这里插入图片描述
也就是说：有结构的文档经过倒排索引后，字段中的每个值都是一个关键字，存放在左边的 Term Dictionary（词汇表）中，且每个关键字都有对应地址指向所在文档。

（4） ES 的 Document 怎么定义结构和字段格式

{
 "mappings": {
 "doc": {
    "properties": {
    "order_id": {
    "type": "text"
 },
    "order_invoice": {
    "type": "nested"
 },
    "order_product_item": {
    "type": "nested",
    "properties": {
    "product_count": {
    "type": "long"
 },
    "product_name": {
    "type": "text"
 },
    "product_price": {
    "type": "float"
 }
 }
 },
    "total_amount": {
    "type": "long"
 },
    "user": {
    "properties": {
    "user_id": {
    "type": "text"
 },
    "user_name": {
    "type": "text"
 }
 }
 }
 }
 }
 }
}

Elasticsearch如何修改表结构？

我们使用 reindex 功能会导致原来保存的旧字段名的索引数据失效，这种情况该如何解决？此时我们可以使用 alias 索引功能，代码示例如下：

PUT trips
{
  "mappings": {
    "properties": {
      "distance": {
        "type": "long"
      },
      "route_length_miles": {
        "type": "alias",
        "path": "distance" 
      },
      "transit_mode": {
        "type": "keyword"
      }
    }
  }
}

说到修改表结构，使用普通 MySQL 时，我并不建议直接修改字段的类型，改名或删字段。因为每次更新版本时，我们都要做好版本回滚的打算，为此设计每个版本对应数据库时，我们会尽量兼容前面版本的代码。

因 ES 的结构基于 MySQL 而设计，两者之间存在对应关系，所以我也不建议直接修改 ES 的表结构。

那如果我们真有修改的需求呢？一般而言，我们会先保留旧的字段，然后直接添加并使用新的字段，直到新版本的代码全部稳定工作后，我们再找机会清理旧的不用的字段，即分成 2 个版本完成修改需求。

ES 的坑有哪些？

坑一：ES 是准实时的？

当你更新数据至 ES 且返回成功提示（注意这一瞬间），你会发现通过 ES 查询返回的数据仍然不是最新的。

数据索引整个过程因涉及 ES 的分片，Lucene Index、Segment、 Document 的三者之间关系等知识点，所以我们有必要先把这部分内容串起来说明。

ES 的一个分片（这里跳过 ES 分片相关介绍）就是一个 Lucene Index，每一个 Lucene Index 由多个 Segment 构成，即 Lucene Index 的子集就是 Segment，如下图所示：

在这里插入图片描述
关于 Lucene Index、Segment、 Document 三者之间的关系，你看完下面这张图就一目了然了，如下图所示：

在这里插入图片描述
通过上面这个图，我们知道一个 Lucene Index 可以存放多个 Segment，而每个 Segment 又可以存放多个 Document。

掌握了以上基础知识点，接下来就进入正题——数据索引的过程详解。

第一步：当新的 Document 被创建，数据首先会存放到新的 Segment 中，同时旧的 Document 会被删除，并在原来的 Segment 上标记一个删除标识。当 Document 被更新，旧版 Document 会被标识为删除，并将新版 Document 存放新的 Segment 中。
第二步：Shard 收到写请求时，请求会被写入 Translog 中，然后 Document 被存放 memory buffer （注意：memory buffer 的数据并不能被搜索到）中，最终 Translog 保存所有修改记录。
在这里插入图片描述
第三步：每隔 1 秒（默认设置），refresh 操作被执行一次，且 memory buffer 中的数据会被写入一个 Segment 并存放 filesystem cache 中，这时新的数据就可以被搜索到了，如下图所示：

通过以上数据索引过程的说明，我们发现 ES 并不是实时的，而是有 1 秒延时，因延时问题的解决方案我们在 02 讲中介绍过，提示用户查询的数据会有一定延时即可。

坑二：ES 宕机恢复后，数据丢失
在数据索引的过程这部分内容，我们提及了每隔 1 秒（根据配置），memory buffer 中的数据会被写入 Segment 中，此时这部分数据可被用户搜索到，但没有被持久化，一旦系统宕机了，数据就会丢失。

比如下图中灰色的桶，目前它可被搜索到，但还没有持久化，一旦 ES 宕机，数据将会丢失。
在这里插入图片描述

如何防止数据丢失呢？使用 Lucene 中的 commit 操作就能轻松解决这个问题。
commit 具体操作：先将多个 Segment 合并保存到磁盘中，再将灰色的桶变成上图中绿色的桶。
不过，使用 commit 操作存在一点不足：耗 IO，从而引发 ES 在 commit 之前宕机的问题。一旦系统在 translog fsync 之前宕机，数据也会直接丢失，如何保证 ES 数据的完整性便成了亟待解决的问题。
遇到这种情况，我们采用 translog 解决就行，因为 Translog 中的数据不会直接保存在磁盘中，只有 fsync 后才保存，这里我分享两种 Translog 解决方案。
第一种：将 Index.translog.durability 设置成 request ，如果我们发现系统运行得不错，采用这种方式即可；
第二种：将 Index.translog.durability 设置成 fsync，每次 ES 宕机启动后，先将主数据和 ES 数据进行对比，再将 ES 缺失的数据找出来。

强调一个知识点：Translog 何时会 fsync ？当 Index.translog.durability 设置成 request 后，每个请求都会 fsync，不过这样影响 ES 性能。这时我们可以把 Index.translog.durability 设置成 fsync，那么每隔 Index.translog.sync_interval 后，每个请求才会 fsync 一次。

坑三：分页越深，查询效率越慢
ES 分页这个坑的出现，与 ES 的读操作请求的处理流程密切关联，为此我们有必要先深度剖析下 ES 的读操作请求的处理流程，如下图所示：
在这里插入图片描述
关于 ES 的读操作流程主要分为两个阶段：Query Phase、Fetch Phase。
Query Phase：协调的节点先把请求分发到所有分片，然后每个分片在本地查询建一个结果集队列，并将命令中的 Document id 以及搜索分数存放队列中，再返回给协调节点，最后协调节点会建一个全局队列，归并收到的所有结果集并进行全局排序。
Query Phase 我需要强调：在 ES 查询过程中，如果 search 带了 from 和 size 参数，Elasticsearch 集群需要给协调节点返回 shards number * (from + size) 条数据，然后在单机上进行排序，最后给客户端返回 size 大小的数据。比如客户端请求 10 条数据（比如 3 个分片），那么每个分片则会返回 10 条数据，协调节点最后会归并 30 条数据，但最终只返回 10 条数据给客户端。
Fetch Phase：协调节点先根据结果集里的 Document id 向所有分片获取完整的 Document，然后所有分片返回完整的 Document 给协调节点，最后协调节点将结果返回给客户端。（关于什么是协调节点，我们先忽略它。）

在整个 ES 的读操作流程中，Elasticsearch 集群实际上需要给协调节点返回 shards number * （from + size) 条数据，然后在单机上进行排序，最后返回给客户端这个 size 大小的数据。

比如有 5 个分片，我们需要查询排序序号从 10000 到 10010（from=10000，size=10）的结果，每个分片到底返回多少数据给协调节点计算呢？告诉你不是 10 条，是 10010 条。也就是说，协调节点需要在内存中计算 10010*5=50050 条记录，所以在系统使用中，如果用户分页越深查询速度会越慢，也就是说并不是分页越多越好。

那如何更好地解决 ES 分页问题呢？为了控制性能，我们主要使用 ES 中的 max_result_window 配置，这个数据默认为 10000，当 from+size > max_result_window ，ES 将返回错误。

由此可见，在系统设计时，我们一般需要控制用户翻页不能太深，而这在现实场景中用户也能接受，这也是我之前方案采用的设计方式。要是用户确实有深度翻页的需求，我们再使用 ES 中search_after 的功能也能解决，不过就是无法实现跳页了。

我们举一个例子，查询按照订单总金额分页，上一页最后一条 order 的总金额 total_amount 是 10，那么下一页的查询示例代码如下：

{
    "query": {
        "bool": {
            "must": [
                {
                    "term": {
                        "user.user_name.keyword": "李大侠"
                    }
                }
            ],
            "must_not": [],
            "should": []
        }
    },
    "from": 0,
    "size": 2,
    "search_after": [
        "10"
    ],
    "sort": [
        {
            "total_amount": "asc"
        }
    ],
    "aggs": {}
}

这个 search_after 里的值，就是上次查询结果的排序字段的结果值。

分表分库：单表数据量大读写缓慢如何解决？

京东大客户也有采用Client模式，即采用sharding-jdbc。关于sharding-jdbc的更全面的知识点，可以参考相关章节。

学到这，我们已经知道市面上开源中间件的设计模式，那我们到底该选择哪种模式呢？简单对比下这 2 个模式的优缺点，你就能知道答案了。

业务代码如何修改？

近年来，分表分库操作愈发容易，不过我们需要注意几个要点。

我们已经习惯微服务了，对于特定表的分表分库，其影响面只在该表所在的服务中，如果是一个单体架构的应用做分表分库，那真是伤脑筋。
在互联网架构中，我们基本不使用外键约束。
随着查询分离的流行，后台系统中有很多操作需要跨库查询，导致系统性能非常差，这时分表分库一般会结合查询分离一起操作：先将所有数据在 ES 索引一份，再使用 ES 在后台直接查询数据。如果订单详情数据量很大，还有一个常见做法，即先在 ES 中存储索引字段（作为查询条件的字段），再将详情数据存放在 HBase 中（这个方案我们就不展开了）。

一般来说，业务代码的修改不会很复杂，最麻烦的是历史数据的迁移。

历史数据迁移？

在这里插入图片描述
此数据迁移方案的基本思路：存量数据直接迁移，增量数据监听 binlog，然后通过 canal 通知迁移程序搬运数据，新的数据库拥有全量数据，且校验通过后逐步切换流量。

数据迁移解决方案详细的步骤如下：

上线 canal，通过 canal 触发增量数据的迁移；
迁移数据脚本测试通过后，将老数据迁移到新的分表分库中；
注意迁移增量数据与迁移老数据的时间差，确保全部数据都被迁移过去，无遗漏；
第二步、第三步都运行完后，新的分表分库中已经拥有全量数据了，这时我们可以运行数据验证的程序，确保所有数据都存放在新数据库中；
到这步数据迁移就算完成了，之后就是新版本代码上线了，至于是灰度上还是直接上，需要根据你们的实际情况决定，回滚方案也是一样。

未来的扩容方案是什么？

随着业务的发展，如果原来的分片设计已经无法满足日益增长的数据需求，我们就需要考虑扩容了，扩容方案主要依赖以下两点。
分片策略是否可以让新表数据的迁移源只是 1 个旧表，而不是多个旧表，这就是前面我们建议使用 2 的 N 次方分表的原因；
数据迁移：我们需要把旧分片的数据迁移到新的分片上，这个方案与上面提及的历史数据迁移一样，我们就不重复啰唆了。

gonghaiyu

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
软件架构场景-数据持久化层

本部分内容包括：（1）数据持久化层场景（2）缓冲层场景（3）基于常用组件的微服务场景及微服务踩坑（4）开发运维场景数据持久化层场景场景1：冷热分离订单功能，里面的主表有几千万的数据量，加上关联表，数据量达到上亿。因为业务员查询的基本是近期常用的数据，常用的数据量大大减少了，可以使用"冷热分离"。什么情况下使用冷热分离1.用户能接受新旧数据分开查询，比如有些电商网站默认只让查询 3 个月内的订单。2.数据走到终态后，只有读没有写的需求，比如订单完结状态。如何判断一个数据到底是冷数据还.
复制链接

扫一扫