Mysql常用知识3:Kafka和数据库优化

文章目录

      • 一、分布式消息系统(Kafka相关问题5-10)
        • 5. Kafka如何保证消息不丢失?
        • 6. 项目中Kafka具体怎么使用的?
        • 7. 消息异常未发送成功怎么解决?
        • 8. 重试具体怎么做的,循环吗?
        • 9. 重试多次失败怎么办,抛出异常吗?
        • 10. 消息一直没发出去是什么原因?
      • 二、数据库设计与优化(问题11-18)
        • 11. SQL怎么优化?
        • 12. 怎么判断是慢查询?
        • 13. 怎么设计一个好的数据库?
        • 14. 项目中数据库表怎么设计的?
        • 15. 主键怎么设计?普通递增 vs 分布式雪花算法
        • 16. 除了雪花算法和UUID,还有什么主键不重复方案?
        • 17. 具体字段类型设计:用户名用什么类型?
        • 18. 什么时候用到JOIN?
      • 三、加密算法(问题19-20)
        • 19. 左连接、右连接、外连接的区别?
        • 20. 加密算法有哪些,什么区别?

以下是针对您提出的20个问题的详细解答,分为分布式消息系统(Kafka)数据库设计与优化加密算法三个模块:

一、分布式消息系统(Kafka相关问题5-10)

5. Kafka如何保证消息不丢失?

Kafka通过生产者、Broker、消费者三端机制确保消息不丢失:

  • 生产者端
    • 设置 acks=all(或 acks=-1):等待所有ISR副本确认接收消息。
    • 启用 retries 重试机制(默认10次),处理网络抖动等临时错误。
    • 记录 producer.send() 返回的 RecordMetadata,用于故障后重试(需避免幂等性问题,可通过 enable.idempotence=true 开启幂等生产者)。
  • Broker端
    • 副本机制:消息写入分区的Leader副本后,需等待ISR(In-Sync Replicas)中的Follower副本同步完成才标记为“已提交”。
    • 持久化:消息写入磁盘时使用fsync强制刷盘(可通过log.flush.interval.messages等参数控制)。
  • 消费者端
    • 手动提交offset:关闭自动提交(auto.commit.offset=false),确保消费成功后再提交。
    • 重复消费处理:通过业务层去重(如利用消息唯一ID+Redis存储已消费记录)。
6. 项目中Kafka具体怎么使用的?

典型应用场景

  • 异步解耦:订单系统下单后,通过Kafka通知库存、物流、支付等系统,避免同步调用超时。
  • 流量削峰:秒杀活动中,将用户请求写入Kafka,消费者(如Java服务)按限流速度处理,防止数据库被瞬时流量冲垮。
  • 日志采集:将应用日志发送到Kafka,供ELK(Elasticsearch+Logstash+Kibana)或Flink等系统进行实时分析。

代码示例(Java生产者)

Properties props = new Properties();
props.put("bootstrap.servers", "kafka:9092");
props.put("acks", "all");
props.put("retries", 3);
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");KafkaProducer<String, String> producer = new KafkaProducer<>(props);
ProducerRecord<String, String> record = new ProducerRecord<>("order-topic", "123", "{\"orderId\":\"1001\",\"amount\":1000}");try {producer.send(record, (metadata, exception) -> {if (exception != null) {log.error("消息发送失败:{}", exception.getMessage());} else {log.info("消息已发送至分区{},偏移量{}", metadata.partition(), metadata.offset());}});
} finally {producer.close();
}
7. 消息异常未发送成功怎么解决?

排查步骤

  1. 生产者日志:查看是否有网络异常(如org.apache.kafka.common.errors.NetworkException)、分区不存在等错误。
  2. Broker状态:检查Kafka集群是否正常(节点存活、分区Leader是否存在),使用kafka-topics.sh --describe查看分区ISR状态。
  3. 重试机制:若为临时性错误(如分区负载过高),通过retries自动重试;若为永久性错误(如消息格式错误),需捕获异常并记录到死信队列(Dead Letter Queue,DLQ)。
  4. 监控告警:通过Prometheus+Grafana监控producer_request_error_rate等指标,及时发现发送失败趋势。
8. 重试具体怎么做的,循环吗?
  • Kafka内置重试
    生产者通过retries参数设置重试次数(默认10次),每次重试间隔由retry.backoff.ms控制(默认100ms)。重试逻辑为指数退避(如第1次重试间隔100ms,第2次200ms,避免频繁重试加剧网络负载)。
  • 业务层重试
    若内置重试耗尽仍失败,可将消息存入数据库(如MySQL)或Redis,通过定时任务(如Spring Task)或分布式调度框架(如Elastic-Job)进行循环重试,直至成功或标记为“需要人工处理”。
9. 重试多次失败怎么办,抛出异常吗?
  • 有限重试后终止
    设定最大重试次数(如5次),超过后不再自动重试,而是:
    1. 发送告警(邮件/短信通知运维人员)。
    2. 将消息写入死信队列(如Kafka的dead-letter-topic),供人工排查(如消息格式错误、下游系统故障)。
  • 异常处理
    在生产者的回调函数中捕获最终异常,记录详细日志(如消息内容、失败原因),但不建议直接抛出异常中断业务流程,应保证主流程继续运行,仅对失败消息做异步处理。
10. 消息一直没发出去是什么原因?

常见原因分析

  • 网络问题
    • 生产者与Broker之间网络断开(如防火墙拦截、VPN中断)。
    • Broker节点负载过高,无法处理新请求(可通过kafka-consumer-groups.sh查看分区Lag)。
  • 元数据问题
    • 生产者未正确获取分区元数据(如首次连接时未等待metadata.max.age.ms刷新)。
    • 主题被删除或分区数变更,导致生产者缓存的元数据失效。
  • 配置错误
    • acks设置为0(不等待Broker确认),但网络故障导致消息丢失。
    • 消息大小超过Broker限制(message.max.bytes默认1MB)。
  • 权限问题
    • 生产者未被授予主题的写入权限(如使用ACL认证时未正确配置)。
  • 下游系统故障
    • 消费者组挂掉或消费速度过慢,导致分区积压,Broker拒绝新消息写入(需调整分区数或消费者并行度)。

二、数据库设计与优化(问题11-18)

11. SQL怎么优化?

优化方向

  1. 索引优化
    • 为高频查询字段添加索引(如WHEREJOINORDER BY字段),避免全表扫描。
    • 避免过度索引(索引会增加写入成本),使用EXPLAIN分析执行计划,查看type是否为range/ref(优于ALL)。
  2. 分页优化
    • 大偏移量分页(如LIMIT 100000, 10)性能差,可通过子查询或WHERE id > last_id优化。
  3. 查询语句优化
    • 避免在索引字段上使用函数(如SELECT * FROM users WHERE YEAR(create_time) = 2023)。
    • EXISTS替代IN查询子集(如SELECT * FROM A WHERE EXISTS (SELECT 1 FROM B WHERE B.a_id = A.id))。
  4. 分库分表
    • 单表数据量超过500万行时,可按业务维度(如用户ID取模)拆分到多个库/表。
12. 怎么判断是慢查询?

方法

  • 开启慢查询日志
    MySQL中通过SET GLOBAL slow_query_log = ON;开启,设置long_query_time阈值(默认10秒,可调整为0.5秒)。
  • 监控工具
    • 使用pt-query-digest分析慢查询日志,统计执行频率、平均耗时、锁等待等。
    • 数据库监控平台(如Prometheus+MySQL Exporter)实时监控slow_queries指标。
  • 执行计划分析
    对疑似慢查询执行EXPLAIN,查看:
    • typeALL表示全表扫描,需优化索引。
    • rows:扫描行数是否过大(理论上应小于总数据量的5%)。
    • Extra:是否包含Using filesort(文件排序)或Using temporary(临时表),这两者通常性能较差。
13. 怎么设计一个好的数据库?

设计原则

  1. 需求分析
    • 明确业务场景(如电商订单、社交动态),识别核心实体(用户、订单、商品)及关系(一对一、一对多)。
  2. 范式设计
    • 遵循3范式(如消除重复数据、确保依赖关系正确),但可适当反范式(如冗余字段)提升查询性能。
  3. 字段设计
    • 选择合适的数据类型(如INT存储用户ID,VARCHAR(255)存储用户名),避免TEXT等大字段滥用。
    • 允许NULL的字段需添加默认值(如create_time DEFAULT CURRENT_TIMESTAMP)。
  4. 性能考量
    • 主键设计:使用自增ID或雪花算法(分布式场景),确保主键查询高效。
    • 分区分表:按时间(如按年/月分表)或业务维度拆分,降低单表数据量。
  5. 扩展性
    • 预留字段(如extend_info JSON)应对未来需求变化,避免频繁修改表结构。
14. 项目中数据库表怎么设计的?

示例:电商订单系统核心表

-- 用户表
CREATE TABLE user (user_id BIGINT PRIMARY KEY AUTO_INCREMENT,  -- 自增主键username VARCHAR(50) NOT NULL UNIQUE,       -- 用户名(唯一索引)password VARCHAR(64) NOT NULL,              -- 密码(加密存储)mobile CHAR(11) UNIQUE,                     -- 手机号(唯一索引)create_time DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB CHARSET=utf8mb4;-- 商品表
CREATE TABLE product (product_id BIGINT PRIMARY KEY AUTO_INCREMENT,product_name VARCHAR(100) NOT NULL,category_id INT NOT NULL,                   -- 分类ID(外键关联category表)price DECIMAL(10, 2) NOT NULL,              -- 价格(精确到分)stock INT NOT NULL DEFAULT 0
) ENGINE=InnoDB;-- 订单表
CREATE TABLE order (order_id BIGINT PRIMARY KEY,                -- 雪花算法生成user_id BIGINT NOT NULL,                    -- 买家ID(外键)total_amount DECIMAL(10, 2) NOT NULL,status TINYINT NOT NULL DEFAULT 0,          -- 订单状态(0待支付,1已支付,2已发货)create_time DATETIME DEFAULT CURRENT_TIMESTAMP,FOREIGN KEY (user_id) REFERENCES user(user_id)
) ENGINE=InnoDB;-- 订单详情表
CREATE TABLE order_detail (order_id BIGINT NOT NULL,                   -- 订单ID(联合主键)product_id BIGINT NOT NULL,                 -- 商品ID(联合主键)quantity INT NOT NULL,price DECIMAL(10, 2) NOT NULL,PRIMARY KEY (order_id, product_id),FOREIGN KEY (order_id) REFERENCES order(order_id),FOREIGN KEY (product_id) REFERENCES product(product_id)
) ENGINE=InnoDB;
15. 主键怎么设计?普通递增 vs 分布式雪花算法
  • 单库场景
    使用AUTO_INCREMENT自增主键,简单高效,适合单节点数据库。
  • 分布式场景
    • 雪花算法(Snowflake):生成64位唯一ID(时间戳+工作节点+序列号),支持高并发,如Java的Twitter雪花算法实现
    • UUID:生成36位字符串(如550e8400-e29b-41d4-a716-446655440000),虽全球唯一但占用空间大,不适合作为主键(可作为业务唯一标识)。
16. 除了雪花算法和UUID,还有什么主键不重复方案?
  • 数据库自增+分库键
    分库场景下,为每个库设置不同的自增起始值和步长(如库1起始1,步长2;库2起始2,步长2),确保跨库唯一。
  • Redis生成ID
    使用INCR命令原子性生成递增ID,适合分布式系统,如:
    import redis
    r = redis.Redis(host='localhost', port=6379)
    order_id = r.incr('order_id_counter')
    
  • UUID变种
    • UUID without hyphens:去掉连字符(如550e8400e29b41d4a716446655440000),节省空间。
    • ULID(Universally Unique Lexicographical Identifier):比UUID更短(26字符),按字典序排列,适合索引。
17. 具体字段类型设计:用户名用什么类型?
  • 推荐类型
    • VARCHAR(n)n根据业务需求设定(如VARCHAR(50)),存储用户名文本(支持中文、字母、数字混合)。
    • CHAR(n):固定长度(如CHAR(20)),适合长度一致的场景(如学号),但浪费空间,不推荐用户名。
  • 注意事项
    • 字符集使用utf8mb4(支持Emoji和生僻字):CREATE TABLE ... CHARSET=utf8mb4;
    • 唯一性约束:UNIQUE KEY(username),避免重复注册。
    • 密码字段:绝不存储明文,使用SHA-256+盐值加密(如password VARCHAR(64) NOT NULL存储哈希值)。
18. 什么时候用到JOIN?

适用场景

  • 关联多张表查询数据(如查询订单对应的用户姓名和商品信息)。
  • 替代子查询,提升性能(如SELECT u.name, o.total_amount FROM user u JOIN order o ON u.user_id = o.user_id;)。

JOIN类型选择

  • INNER JOIN:仅返回两张表中匹配的行(如用户存在且订单存在)。
  • LEFT JOIN:返回左表所有行,右表匹配不到的行用NULL填充(如查询所有用户及其订单,包括未下单用户)。
  • RIGHT JOIN:与LEFT JOIN相反,返回右表所有行,实际中较少使用,可用LEFT JOIN+表交换替代。
  • FULL OUTER JOIN(外连接):返回左右表所有行,匹配不到的用NULL填充(MySQL不支持,需用LEFT JOIN UNION RIGHT JOIN模拟)。

三、加密算法(问题19-20)

19. 左连接、右连接、外连接的区别?
类型定义示例(表A: 用户,表B: 订单)
INNER JOIN仅返回A和B中ON条件匹配的行只返回有订单的用户
LEFT JOIN返回A的所有行,B中无匹配的行用NULL填充返回所有用户,无订单的用户订单字段为NULL
RIGHT JOIN返回B的所有行,A中无匹配的行用NULL填充返回所有订单,无用户的订单(异常数据)字段为NULL
FULL OUTER JOIN返回A和B的所有行,无匹配的行用NULL填充(MySQL不支持)需用A LEFT JOIN B UNION A RIGHT JOIN B模拟
20. 加密算法有哪些,什么区别?

常见加密算法分类及对比

类别算法名称密钥类型用途特点
对称加密AES(AES-128/256)单密钥数据加密(如敏感字段存储、通信加密)速度快,密钥需安全传输(常用作HTTPS底层加密)
DES/3DES单密钥历史系统兼容(已逐渐被AES取代)密钥长度短(56位),安全性低
Blowfish单密钥快速加密(如VPN)可变密钥长度(32-448位),适合资源受限环境
非对称加密RSA(2048/4096位)公钥+私钥数字签名、密钥交换(如HTTPS证书)安全性高,但速度慢,适合少量数据加密
ECC(椭圆曲线)公钥+

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.pswp.cn/diannao/85172.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

常见的RAG文档解析辅助工具汇总及企业选型思考

以下当前比较知名的RAG的文档解析辅助工具的开源项目汇总&#xff0c;包含核心功能、License信息及GitHub地址&#xff1a; 1. RAGFlow 核心功能&#xff1a;支持PDF/扫描件/CAD等23种格式解析&#xff0c;OCR准确率98%&#xff0c;知识图谱融合&#xff0c;混合检索&#xf…

基于Sqoop的MySQL-Hive全量/增量同步解决方案(支持多表批量处理

一、全量同步方案设计 1.1 基础命令模板 sqoop import \ --connect jdbc:mysql://mysql_host:3306/db_name \ --username user \ --password pass \ --table source_table \ --hive-import \ --hive-table target_table \ --hive-overwrite \ # 覆盖已有表 --num-mappers 8 …

前端学习(7)—— HTML + CSS实现博客系统页面

目录 一&#xff0c;效果展示 二&#xff0c;实现博客列表页 2.1 实现导航栏 2.2 实现个人信息 2.3 实现博客列表 三&#xff0c;实现博客正文页 3.2 复用 3.4 实现博客正文 四&#xff0c;实现博客登录页 4.1 版心 4.2 登录框 五&#xff0c;实现博客编辑页 5.1 …

【技能拾遗】——家庭宽带单线复用布线与配置(移动2025版)

&#x1f4d6; 前言&#xff1a;在家庭网络拓扑中&#xff0c;客厅到弱电箱只预埋了一根网线&#xff0c;由于已将广电的有线电视取消并改用IPTV。现在需要解决在客厅布置路由器和观看IPTV问题&#xff0c;这里就用到单线复用技术。 目录 &#x1f552; 1. 拓扑规划&#x1f55…

VTK|实现类似CloundCompare的测量功能

文章目录 CloundCompare在点、线、面三种模式下的显示内容✅ 图1&#xff1a;点模式✅ 图2&#xff1a;线模式✅ 图3&#xff1a;面模式 增加控制菜单栏实现测量功能类如何调用项目git链接 CloundCompare在点、线、面三种模式下的显示内容 点 线 面 三张图展示了 CloudComp…

4000万日订单背后,饿了么再掀即时零售的“效率革命”

当即时零售转向价值深耕&#xff0c;赢面就是综合实力的强弱。 文&#xff5c;郭梦仪 编&#xff5c;王一粟 在硝烟弥漫的外卖行业“三国杀”中&#xff0c;饿了么与淘宝闪购的日订单量竟然突破了4000万单。 而距淘宝闪购正式上线&#xff0c;还不到一个月。 在大额福利优惠…

vedio.ontimeupdate()和video.onloadeddata()

video.onloadeddata &#xff08;&#xff09; video.onloadeddata 是 JavaScript 中用于监听 HTML <video> 元素 「当前帧数据已加载」 的事件处理器。当视频的第一帧画面数据加载完成&#xff08;足以开始播放&#xff09;时&#xff0c;会触发此事件。 1. 基本用法 …

Baklib内容中台革新企业知识实践

Baklib智能知识中枢构建 作为现代企业知识管理的核心架构&#xff0c;Baklib内容中台通过整合多源异构数据形成智能化知识中枢&#xff0c;实现从信息采集到价值转化的全链路管理。其底层采用跨平台数据贯通技术&#xff0c;支持API接口与企业现有CRM、ERP系统无缝对接&#x…

用不太严谨的文字介绍遥测自跟踪天线的基本原理

前两天跟一个客户见面的时候&#xff0c;客户问我&#xff1a;遥测自跟踪天线能够跟踪目标&#xff0c;是什么原理&#xff1f;不需要目标的位置&#xff0c;怎么做到自跟踪的&#xff1f; 突然一瞬间&#xff0c;有点语塞。 难道要介绍天线、馈源、极化、左旋、右旋、和差网…

VS配置redis环境、redis简单封装

一、安装redis数据库 1.下载redis的压缩包 wget https://download.redis.io/releases/redis-6.0.5.tar.g 2.解压缩redis压缩包&#xff0c;一般就在当前路径 tar -zvxf redis-6.0.5.tar.gz -C /usr/local/redis 方便找我把它解压缩在/usr/local/redis&#xff0c;如果没有r…

C++23 已移除特性解析

文章目录 引言C23 已移除特性介绍1. 垃圾收集的支持和基于可达性的泄漏检测&#xff08;P2186R2&#xff09;背景与原理存在的问题移除的影响 2. 混合宽字符串字面量拼接非良构&#xff08;P2201R1&#xff09;宽字符串编码概述混合拼接的问题示例分析移除的意义 3. 不可编码宽…

Cloudflare

Cloudflare 是一个网络基础设施和网站安全服务提供商&#xff0c;它的主要作用是让网站 更快、更安全、更可靠。简单来说&#xff0c;它是一个“护盾 加速器”。 &#x1f9e9; Cloudflare 的主要功能&#xff1a; 1. &#x1f680; 加速网站访问&#xff08;CDN&#xff09…

Spring Boot启动慢?Redis缓存击穿?Kafka消费堆积?——Java后端常见问题排查实战

Spring Boot启动慢&#xff1f;Redis缓存击穿&#xff1f;Kafka消费堆积&#xff1f;——Java后端常见问题排查实战 引言 Java后端系统因其丰富的技术栈和复杂的业务逻辑&#xff0c;常常面临启动延迟、性能瓶颈、异常错误等多种挑战。从核心语言、Web框架到分布式微服务及缓…

数字人引领政务新风尚:智能设备助力政务服务

在信息技术飞速发展的今天&#xff0c;政府机构不断探索提升服务效率和改善服务质量的新途径。实时交互数字人在政务服务中的应用正成为一大亮点&#xff0c;通过将“数字公务员”植入各种横屏智能设备中&#xff0c;为民众办理业务提供全程辅助。这种创新不仅优化了政务大厅的…

ToolsSet之:十六进制及二进制编辑运算工具

ToolsSet是微软商店中的一款包含数十种实用工具数百种细分功能的工具集合应用&#xff0c;应用基本功能介绍可以查看以下文章&#xff1a; Windows应用ToolsSet介绍https://blog.csdn.net/BinField/article/details/145898264 ToolsSet中Number菜单下的Hex Operate工具可以进…

DSP处理数字信号做什么用的?

DSP&#xff08;数字信号处理器&#xff09;的核心任务是高效、实时地处理数字信号&#xff0c;通过专用硬件架构和算法优化&#xff0c;完成对信号的转换、增强、分析和控制。以下是DSP处理数字信号的主要用途及典型场景&#xff1a; 1. 信号增强与优化 降噪&#xff08;Noise…

电脑如何保养才能用得更久

在这个数字化的时代&#xff0c;电脑已经成为了我们生活和工作中不可或缺的伙伴。无论是处理工作文档、追剧娱乐&#xff0c;还是进行创意设计&#xff0c;电脑都发挥着至关重要的作用。那么&#xff0c;如何让我们的电脑“健康长寿”&#xff0c;陪伴我们更久呢&#xff1f;今…

设计模式-监听者模式

文章目录 监听者模式 监听者模式 监听器模式指的是事件源经过事件的封装传给监听器&#xff0c;当事件源触发事件之后&#xff0c;监听器收到事件的通知并执行事件回调方法。 -监听者观察者概念定义当范围对象的状态发生变化时&#xff0c;服务器自动调用监听器对象中的方法来…

小程序33-列表渲染

列表渲染 就是指通过循环遍历一个数组或对象&#xff0c;将其中的每个元素渲染到页面上 在组件上使用 wx:for 属性绑定一个数组或对象&#xff0c;既可使用每一项数据重复渲染当前组件 每一项的变量名默认为item&#xff0c;下标变量名默认为index 在使用 wx:for进行遍历的时候…

[ Qt ] | QRadioButton和QCheckBox的使用

目录 QRadioButton 常用属性 clicked(bool)信号、pressed信号、released信号 小项目 QRadioButton QRadioButton是一个单选按钮&#xff0c;也是继承自QAbstractButton(继承自QWidget) 常用属性 checkable 是否能选中 checked 是否已经被选中 autoExclusive 是否排…