线上问题原因及处理方案

一、接口请求响应慢

1、将慢请求接口,打印出请求和耗时日志到Kibana日志平台,方便查看

2、利用Pinpoint、Arthas、Scouter等字节码插桩监控工具,对接口进行耗时分析,找出接口调用链路中耗时多的位置进行优化

3、优化的方式主要比如:多级缓存,慢SQL优化,批量查询,减小长事务,异步处理等

二、队列任务堆积

1、消费端处理不过来,导致任务队列任务积压,也可能导致服务CPU内存飙升告警,比如JOB任务调度平台,MQ任务,Kafka任务积压

2、增加监控告警,出现任务积压通知相关人员

3、先在生产端控制任务的生成,消费端服务恢复正常后,再启动生产端

4、事后复盘,分析任务的消费为啥慢,可能有慢SQL,或者业务确实处理流程长比较慢,可以适当减缓生产任务的速度

三、需要支持大数据量的报表数据异步导出

1、使用分页查询导出、使用流式查询导出

Java实现mysql的分页及流式查询导出_java 流式导出-CSDN博客

四、需要支持大数据量的报表数据异步导入

1、先解析Excel文件将数据和表头信息解析出来,并存储到任务表中,然后单独起一个线程异步处理;

五、服务启动慢

《Java应用提速(速度与激情)》------七、其他提速-阿里云开发者社区

高效开发与设计:提效Spring应用的运行效率和生产力-CSDN博客

六、慢SQL

1、将慢SQL日志传输到Kibana日志平台,方便查看;

2、EXPLAIN 分析这个慢SQL,是否命中索引,扫描了多少行,命中的索引区分度高是否高

3、慢查询日志中有很多查询慢的SQL,大致取出一些在生产环境上重新执行了下,一直是慢,也是命中了索引,但是扫描的数据条数比较多,一般要扫描几十万以上,可能是本身就需要查询这么多数据,也可能是命中的索引区分度不高,单优化SQL语句的话不是很好优化。

针对不修改的日志记录型的亿级大数据查询的处理方案参考:

1.MySQL单表

MySQL数据库我们是算用得最多了。但众所周知,MySQL是单机的。MySQL能存储多少数据,取决于那台服务器的硬盘大小。很多时候MySQL是没法存储那么多数据的,根据行记录头信息、可变字段列表、事务ID、指针字段、字段内容信息等不同存储量极限也会不同,数据存储量范围为一百多万条到将近5亿条数据,业界公认MySQL单表容量在1KW量级是最佳状态,这个感兴趣的可以自己去看看,这里就不再赘述,肯定不能存储几十亿条数据。

2.MySQL分库分表

分库分表确实可以存储更多的数据量,分布式事务和异步复制等技术也进一步提高了写入性能和数据的可靠性,将数据分散到多个物理服务器或表中,减少单个服务器或表的负担,查询性能也还可以,支持在线事务处理。但是有以下不足:

  • MySQL存储数据耗费的资源更多,当数据量达到几十亿时候,如果每列字段都加上索引,索引占用空间的比例甚至超过数据本身的存储空间;

  • 在线分析处理能力一般。因为在线分析处理(OLAP)则需要进行复杂的查询和分析,通常需要使用聚合函数等操作,这些操作会涉及到大量的数据读取和计算,因此需要大量的计算资源和内存空间,在MySQL分库分表中,数据被分散存储在多个节点上,查询数据需要通过网络进行数据的传输和计算,这会导致查询速度的降低和延迟的增加;

  • 由于数据的分散存储,需要进行多个节点的数据聚合和计算,这也会增加系统的负担和延迟;

  • 同时,这也导致当数据量达到几十亿时候,查询性能也会受到很大影响。

3.Elasticsearch

Elasticsearch是一个分布式的搜索引擎,并采用数据分片和高可用性等技术,可以存储海量数据。采用倒排索引的方式存储数据,可以快速检索数据。也可以进行实时数据分析。但是有以下不足:

  • 由于分词等特性,写吞吐量上有着明显的瓶颈;

  • 分词会增加写入操作的延迟和负载;

  • 热点问题比较难解决。如果资源冗余不足,就会导致稳定性下降,数据写入会发生延迟;

  • 当数据量增加时,Elasticsearch 的查询速度会变慢,因为它必须扫描整个索引才能找到符合查询条件的数据;

  • 压缩率不高,存储成本也比较高。

4.Hbase

HBase是基于HDFS分布式文件系统去构建的,集群的管理基于 ZooKeeper 实现,设计是为了海量数据的快速存储和随机访问,列式存储也减少数据的读取量。列族设计、MemStore 缓存、批量写入、数据压缩等使其写入性能也非常优秀。但是有以下不足:

  • 它并不是一个实时计算和数据分析的框架;

  • 数据存储方式问题:HBase的数据存储方式是以列族和列的方式存储数据,这种方式适合存储结构化数据,但是在存储非结构化数据时效率较低。在实时数据分析场景下,数据可能是半结构化或者非结构化的,这种数据存储在HBase中需要进行额外的处理,导致效率下降;

  • RowKey的设计对查询也有一定限制,所以Hbase不太适合;

  • 数据读取效率问题:HBase的数据读取方式是通过扫描整个表或者通过索引查找特定行来实现的,这种方式在处理大量数据时效率较低,尤其是在实时数据分析场景下,需要快速响应用户的查询请求,但是HBase的读取速度无法满足这个需求。

5.ClickHouse

ClickHouse的特点是高速、可扩展、高效、低成本,它可以适应各种数据存储和处理需求,包括在线分析处理(OLAP)、实时数据分析、数据仓库、日志分析等场景。它支持SQL语言和多种数据格式,包括CSV(逗号分隔值)、JSON、XML等,并且可以通过JDBC、ODBC和HTTP等协议进行访问。

ClickHouse的性能非常出色,可以在秒级别内处理数十亿条数据,而且它支持数据压缩和分区等功能,可以大大降低存储和查询成本。基于以上特性,选择ClickHouse来存储、查询和分析数据。

6.本地缓存+Redis缓存+分库分表

stock_movement表中的数据,从2018年到现在的数据都在这个表中,是否可以将最近的相对热点的数据放到缓存中。同时按时间对表进行分库分表。

参考:

对比MySQL和ES后,毫不犹豫把百亿数据存到ClickHouse了_es是存储量最大的数据库吗-CSDN博客

explain分析sql语句性能详解_explain sql-CSDN博客

MySQL索引原理及慢查询优化 - 美团技术团队

相关推荐
青云交16 小时前
大数据新视界 -- 大数据大厂之 Impala 性能优化:为企业决策加速的核心力量(下)(14/30)
大数据·性能优化·impala·查询优化·企业决策·数据整合·系统融合
橘色的喵16 小时前
嵌入式ARM平台Linux网络实时性能优化
linux·网络·arm开发·性能优化·实时·内核优化
杰克逊的日记16 小时前
‌MySQL 5.7和8.0版本在多个方面存在显著区别,主要包括性能优化、新特性引入以及安全性提升
数据库·mysql·性能优化
货拉拉技术17 小时前
货拉拉是如何实现symbolic demangle?
ios·性能优化
我怀里的猫21 小时前
glide性能优化实战
性能优化·glide
键盘上的蚂蚁-1 天前
独立站 API 接口的性能优化策略
性能优化
斗-匕1 天前
MySQL 高性能优化规范建议总结
mysql·oracle·性能优化
Hello.Reader3 天前
InfluxDB性能优化指南
性能优化
Edward-tan3 天前
PostgreSQL 性能优化全方位指南:深度提升数据库效率
数据库·postgresql·性能优化
可缺不可滥3 天前
前端 性能优化 (图片与样式篇)
前端·性能优化