1、问题现状 产品功能逻辑其实比较简单，执行 spark 任务并把 hive 表数据同步写入到 clickhouse 数据库表，每次执行前需删除操作分区下的所有数据并重新插入表，而在 spark 代码中使用的是 alter table 的操作。 2、根因分析 首先我们查看了集群机器状态，发现所有机器的 CPU 负载高居不下。 随后结合 spark 任务与后端接口的报错信息来看，初步推测是 clickhouse 的任务队列存在太多 ddl 操作了，导致连接超时。 登录 clickhouse 数据库后，使用命令查询当前存在哪些 ddl ，真是不查不知道，一查吓一跳，全是 truncate table 语句或者 alter table …

阅读更多

1、开门见山 在我们团队中，大多数项目主要使用了 Spring 或 Spring Boot 技术栈，而 Spring Cloud Gateway 网关与现有团队使用的技术栈几乎一致，经过技术选型及对技术成本与技术栈生态的考虑，最终选择使用 Spring Cloud Gateway 作为我们的业务后端网关，统一收敛并统一微服务的流量入口。 2、程序启动入口 使用过 Spring Boot 或者 Spring Cloud Gateway 的人，对如何启动应用程序均不陌生。 1@SpringBootApplication 2public class DatanexusGatewayApplication { 3 public static …

阅读更多

安装ps命令 1yum install -y procps 2apt-get update 3apt-get install procps 安装 vi 命令 1yum install -y vim 2apt-get update 3apt-get install vim 安装ping命令 1yum install -y iputils 2 3## 同步 /etc/apt/sources.list 和 /etc/apt/sources.list.d 中列出的源的索引，这样才能获取到最新的软件包 4apt-get update 5apt-get install iputils-ping 6apt-get install dnsutils …

阅读更多

1、问题复现 在现网系统中，用户操作前端页面时，需要等待 1s 左右才能出开数据，这给用户带来极不友好的体验，严重的还可能造成用户流失等。 2、精准定位 我们的服务是通过容器部署的，首先登陆到容器 pod 实例，并下载 Arthas 工具： 1wget https://arthas.aliyun.com/arthas-boot.jar 紧接着通过 java -jar arthas-boot.jar 启动 Arthas ： 选择对应的服务应用，此处只有一个进程，因此输入 1 按回车即可，并可输入 help 命令查看 Arthas 有哪些命令功能： 我们需要查询具体接口为什么执行缓慢，因此只需使用到 trace 命令，格式为： …

阅读更多

查询数据库有哪些用户 1use mysql; 2select host,user from user; 查询进程列表 1show full processlist 查看数据库及表容量⼤⼩并排序查看所有数据库容量⼤⼩ 1SELECT 2 table_schema AS '数据库', 3 sum(table_rows) AS '记录数', 4 sum( 5 TRUNCATE (data_length / 1024 / 1024, 2) 6 ) AS '数据容量(MB)', 7 sum( 8 TRUNCATE (index_length / 1024 / 1024, 2) 9 ) AS …

阅读更多

从 grafana 官网上查看了 mac 电脑安装 grafana 的文档，发现文档上并没有 mac m1 芯片的安装方式，即使下载了 grafana 的执行文件到本地后，执行时会提示 bad cpu type in executable 的错误，网上百度一番后发现流程文档很少，因此考虑自己下载源码后在 mac m1 电脑上自行编译、安装。 1、下载源代码 访问 https://github.com/grafana/grafana/releases 页面，下载指定版本的源码，注意：本文下载的源码版本为 9.3.1 2、安装 go 环境（已安装忽略） 3、配置 goproxy 代理（可选） 为防止下载模块访问慢或者失败， …

阅读更多

1、问题背景 前段时间，开发完某产品的需求后，后端调用离线大数据任务平台时总会出现一些失败的任务，经过评查及采样发现失败的任务都有一个共同点：请求大数据平台接口的参数长度大于64 kb，经过与大数据任务平台侧团队沟通排查后，确认是请求参数长度超过限制，导致插入数据库时报错异常，临时的解决方案是拓展数据库字段长度，但字段长度总不能一直扩展，因此需要业务调用方对请求参数的长度做限制或者压缩处理，使之能满足接口的使用要求。 2、东寻西觅 ZIP压缩 1public class CompressUtils { 2 3 private static final Logger logger = …

阅读更多

连接 Clickhouse 1./clickhouse-client -h 9.218.16.160 --port 9000 -u 'yyy' --password 'zzzzz' 查询库表信息 1use databases; 2select * from table; 3show create table; 查询数据库数据量大小 1##按照数据量倒序 2SELECT database, formatReadableSize(on_disk) FROM (SELECT database, sum(bytes_on_disk) AS on_disk FROM system.parts GROUP BY …

阅读更多

连接 Redis 1./redis-cli -h 1.2.3.6 -p 6379 -a 'xxx' --raw 批量删除 1./redis-cli -h 1.10.8.6 -p 6379 -a 'xxx' scan --pattern 'ad_dimension_analysis:*' | xargs redis-cli -h 1.10.8.6 -p 6379 -a 'xxx' del 2 3redis-cli -h 1.10.8.6 -p 6379 -a 'xxx' -n 0 --scan --pattern …

阅读更多

1、问题偶现 最近在排查线上问题时，发现网关打印的响应数据日志偶尔出现乱码现象，但实际上接口下发给客户端的是正常的，无法在服务端查看其原始数据，进一步影响排查问题的效率、解决问题。 2、前思后想 经过一番排查定位后，了解到 spring cloud gateway 的 Mono<DataBuffer>.flatMap()方法在获取数据时，若响应数据较大则只会取其中的一部分，导致日志显示不完成出现乱码，原代码逻辑如下： 1private static class HoldBodyResponseDecorator extends ServerHttpResponseDecorator { 2 3 private …

阅读更多