长文多图：一文讲清楚应对单数据表海量数据的六种策略( 五 )

对于上述需要使用userId进行查询的场景，我们完全可以新建库和表，数量和结构与订单库表完全一致，唯一不同点是ShardingKey改用userId ，这样就可以使用userId查询了。
现在又引出一个新问题，业务不可能每次都将数据写入多个数据源，这样会带来性能问题和数据一致行为。怎么解决老库和新库数据同步问题？我们可以使用阿里开源的canal组件解决这个问题，看一张官网介绍canal架构图：

canal组件的主要用途是基于MySQL数据库增量日志解析，提供增量数据订阅和消费服务，工作原理如下：
(1) canal伪装成为MySQL slave模拟交互协议向master发送dump协议(2) master收到canal发送的dump请求，开始推送binlog给canal(3) canal解析binlog并发送到存储目的地，例如MySQL、Kafka、Elasticsearch
canal组件下游可以对接很多其它数据源，这样给业务提供了更多选择。我们可以像上述实例中新建用户维度订单表，也可以将数据存在ES中提供运营检索能力等等。

7 热我们来分析这样一个场景：社交业务有一张用户关系表，主要记录谁关注了谁。其中有一个明星粉丝特别多，如果以userId作为分片，那么其所在分片数据量就会特别大。
不仅分片数据量特别大，而且可以预见这个分片访问频率也会非常高。此时数据量大并且访问频繁，很有可能造成系统压力。

7.1 热点概念我们将访问行为称为热点行为，将访问对应的数据称为热点数据。我们通过实例来分析。
在电商双11活动中百分之八十的访问量会集中在百分之二十的商品上。用户刷新、添加购物车、下单被称为热点行为，相应商品数据就被称为热点数据。
在微博场景中大V发布一条消息会获得大量访问。用户对这条消息的浏览、点赞、转发、评论被称为热点行为，这条消息数据被称为热点数据。
在秒杀场景中参与秒杀的商品会获得极大的瞬时访问量。用户对这个商品的频繁刷新、点击、下单被称为热点行为，参与秒杀的商品数据被称为热点数据。
我们必须将热点数据进行一些处理，使得热点访问更加流畅，更是为了保护系统免于崩溃。我们从发现热点数据、处理热点数据来展开分析。

7.2 发现热点数据我们把发现热点数据分为两种方式：静态发现和动态发现。
静态发现：在开始秒杀活动之前，参与商家一定知道哪些商品参与秒杀，那么他们可以提前将这些商品报备告知平台。
在微博场景中，具有影响力的大V一般都很知名，网站运营同学可以提前知道。技术同学还可以通过分析历史数据找出TOP N数据。对于这些可以提前预判的数据，完全可以通过后台系统上报，这样系统可以提前做出预处理。
动态发现：有些商品可能并没有上报为热点商品，但是在实际销售中却非常抢手。在微博场景中，有些话题热度突然升温。这些数据成为事实上的热点数据。对于这些无法提前预判的数据，需要动态进行判断。
我们需要一个热点发现系统去主动发现热点数据。大体思路是首先异步收集访问日志，再统计单位时间内访问频次，当超过一定阈值时可以判断为热点数据。

7.3 处理热点问题(1) 热点行为热点行为可以采取高频检测方式，如果发现频率过高则进行限制。或者采用内存队列实现的生产者与消费者这种异步化方式，消费者根据能力处理请求。

以上关于本文的内容，仅作参考！温馨提示：如遇健康、疾病相关的问题，请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容，希望对您有所帮助：