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

DELETE FROM biz_tableWHERE id >= #{minId}AND id <= #{maxId}AND id <= #{endId}LIMIT 500

3 换换是指换一个存储介质，当然并不是说完全替换，而是用其它存储介质对数据库做一个补充。例如海量流水记录，这类数据量级是巨量的，根本不适合存储在MySQL数据库中，那么这些数据可以存在哪里呢？
现在互联网公司一般都具备与之规模相对应的大数据服务或者平台，那么作为业务开发者要善于应用公司大数据能力，减轻业务数据库压力。

3.1 消息队列这些海量数据可以存储至Kafka ，因为其本质上就是分布式的流数据存储系统。使用Kafka有如下优点：
第一个优点是Kafka社区活跃功能强大，已经成为了一种事实上的工业标准。大数据很多组件都提供了Kafka接入组件，经过生产验证并且对接成本较小，可以为下游业务提供更多选择。
第二个优点是Kafka具有消息队列本身的优点例如解耦、异步和削峰。

假设这些海量数据都已经存储在Kafka ，现在我们希望这些数据可以产生业务价值，这涉及到两种数据分析任务：离线任务和实时任务。
离线任务对实时性要求不高，例如每天、每周、每月的数据报表统计分析，我们可以使用基于MapReduce数据仓库工具Hive进行报表统计。
实时任务对实时性要求高，例如根据用户相关行为推荐用户感兴趣的商品，提高用户购买体验和效率，可以使用Flink进行流处理分析。例如运营后台查询分析，可以将数据同步至ES进行检索。
还有一种分类方式是将任务分为批处理任务和流处理任务，我们可以这么理解：离线任务一般使用批处理技术，实时任务一般使用流处理技术。

3.2 API上一个章节我们使用了Kafka进行海量数据存储，由于其强大兼容性和集成度，可以作为数据中介将数据进行中转和解耦。
当然我们并不是必须使用Kafka进行中转，例如我们直接可以使用相关Java API将数据存入Hive、ES、HBASE等。
但是我并不推荐这种做法，因为将保存流水这样操作耦合进业务代码并不合适，违反了高内聚低耦合的原则，尽量不要使用。

3.3 缓存从广义上理解换这个字，我们还可以引入Redis远程缓存，把Redis放在MySQL前面，拦下一些高频读请求，但是要注意缓存穿透和击穿问题。
缓存穿透和击穿从最终结果上来说都是流量绕过缓存打到了数据库，可能会导致数据库挂掉或者系统雪崩，但是仔细区分还是有一些不同，我们分析一张业务读取缓存流程图。

我们用文字简要描述这张图：

(1) 业务查询数据时首先查询缓存，如果缓存存在数据则返回，流程结束
(2) 如果缓存不存在数据则查询数据库，如果数据库不存在数据则返回空数据，流程结束
(3) 如果数据库存在数据则将数据写入缓存并返回数据给业务，流程结束

假设业务方要查询A数据，缓存穿透是指数据库根本不存在A数据，所以根本没有数据可以写入缓存，导致缓存层失去意义，大量请求会频繁访问数据库。
缓存击穿是指请求在查询数据库前，首先查缓存看看是否存在，这是没有问题的。但是并发量太大，导致第一个请求还没有来得及将数据写入缓存，后续大量请求已经开始访问缓存，这是数据在缓存中还是不存在的，所以瞬时大量请求会打到数据库。

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

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