快手许愿(已挂)

球球了 球球了 球球了

想问问大家和快手说两方解约要赔钱吗，有没有类似经历的同学，还是说要去找个留学offer，什么理由之类的，会被拉黑吗

5.19 一面 第二天约二面5.21 二面 一小时后约了5.26三面给邮件里的hr发了短信询问，说还是技术面想问一下暑期的三面技术面都问什么啊真的很想当手孝子5.26 二编-------------30分钟 问了项目简单问题 没问技术细节 职业规划  岗位预期  然后一道手撕感觉好像挂了

一、主从库读写测试步骤1. 环境准备：- 搭建主从架构（1主1从或多从），确保主从复制正常（可通过 SHOW SLAVE STATUS 查看IO和SQL线程状态）。- 主库配置 server-id=1 ，从库配置 server-id=2 ，主库开启二进制日志（ log-bin ）。2. 读写测试核心操作：- 写操作测试：在主库执行增删改（如 INSERT/UPDATE/DELETE ），观察从库数据是否同步（可通过定时查询或触发器验证）。- 读操作测试：在从库执行查询（如 SELECT ），确认数据与主库一致，同时测试从库负载能力（可通过压测工具如 sysbench 模拟并发读）。- 异常场景测试：- 主库宕机：验证从库是否可切换为读写模式（需手动或通过中间件如MHA自动切换）。- 网络延迟：模拟主从网络波动，观察数据同步延迟（ Seconds_Behind_Master 参数）。3. 关键指标记录：- 同步延迟时间、读写性能差异、高并发下的一致性表现。二、主从复制原理1. 核心机制（基于二进制日志）：- 主库（Master）：将数据变更记录到二进制日志（Binlog），包括DDL和DML操作。- 从库（Slave）：通过两个线程实现复制：- IO线程：连接主库，读取Binlog并写入本地中继日志（Relay Log）。- SQL线程：解析中继日志，在从库执行相同操作，实现数据同步。2. 复制模式（3种）：- 异步复制：主库写入Binlog后立即返回，不等待从库确认（性能高，一致性差）。- 半同步复制：主库等待至少一个从库确认接收Binlog后返回（性能和一致性平衡）。- 全同步复制：主库等待所有从库确认后返回（一致性高，性能低）。3. 常见问题与面试考点：- 主从延迟：高并发下从库同步慢，解决方案：升级硬件、读写分离、分库分表。- 数据一致性：异步复制可能丢失数据，可通过半同步或中间件（如Canal）弥补。- 切换与故障恢复：手动切换主从时需锁定主库（ FLUSH TABLES WITH READ LOCK ），避免数据不一致。三、面试场景- 结合场景说优势：主从架构用于读写分离，减轻主库压力，适合读多写少场景（如电商商品页查询）。- 提扩展知识：主从是分布式基础，可延伸到集群架构（如MGR、InnoDB Cluster）或中间件（MyCat、ShardingSphere）。