阿里云瓴羊后端一面30min，全程八股轰炸，能回答50%

面试表现：基础差，项目没​​有深度。
MySQL： 分库分表：根据业务选择ShardingSphere、MyCat、Vitess。
ACID：原子撤消日志、一致性约束、隔离锁/MVCC、持久重做日志。
MVCC：读取快照，写入版本号。
索引：B+树、​​哈希、全文、空格、链接、最左边前缀。
索引错误：主动、NOT、前缀LIKE、OR、分布不均匀。
慢SQL：Slow_query_log，PerconaPMM解析字段EXPLAIN。
数据量：业务预估，百万/千万。
压力测试：JMeter、sysbench、Locust。

重做： 延迟队列：zset按分数排序。
zset结构：zip列表/跳转列表。
跳转表：O(logn)查询，简单范围支持。
Linux： 打包：tar-czvf 解压tar-xzvf。
日志：grep、tail -f、less。
日志框架：Log4 j、Logback、SLF4 J、ELK。

网络： HTTP3 02 ：临时重定向，位置标头。
重定向与转发：客户端与服务器、更改/不变 URL。
HTTP 和 HTTPS：明文和加密，端口 8 0/4 4 3 加密：高效的对称 AES、安全的非对称 RSA。

Maven： 部署：mvndeploy 服务器配置。

弹性搜索： 指标：以逆向指标为主。
倒排索引：词段、倒排列表。
快速ES：倒排索引、分片、缓存、NRT。
Java： 面向对象：封装、继承、多态。

反馈： 基础薄弱：了解 MVCC、跳表和编码。
较差的项目：技术选型和性能优化。

准备工作： 练习题：有关数据库、网络和操作系统的高频问题。
项目：添加分布式事务和高并发设计。
学习：分布式、微服务、云平台。

Mysql分库分表面试题（mysql高可用方案解析）

在上周的面试中，我被问到了部分数据库和增量表的问题。

1 .子库键选择 需要双重平衡：数据量平衡和请求量平衡。
比如2 02 3 年的一个电商项目，选择了用户ID哈希来取模块，但发现单个数据库的数据量仍然超过5 000万条。
后来采用了用户级分区，数据量分布变得正常。

SQL 兼容性很重要。
有一种情况，数据库拆分后聚合函数失败，所有SQL崩溃。
最后，Redi的二次聚合应用到服务层三天。

分布式事务确实是一个令人头疼的问题。
我的朋友正在从事一个社会项目。
他尝试了 2 PC 和 TCC，但都卡住了。
最终他决定将业务进行拆分，采用消息队列+最终一致性的方式来解决问题。

2 多表关联 在5 8 同城这样的高并发场景下，JOIN根本就没有必要。
他们将订单表用户 ID 冗余到订单表中，因此查询链接少得多。

但有一个反例：某金融系统使用Redis来缓存中间关系。
结果导致数据同步延迟，导致一笔贷款审核错误，差点丢了位置。

合并个人搜索的搜索也很慢。
它是一个按日期划分数据库的旅行系统。
当用户查看7 天的行程时，必须在数据库中循环7 次。
最后使用Elasticsearch进行聚合。

3 产能扩张策略 Hash模块扩展的成本非常高。
我参与了一个游戏项目，从4 个数据库扩容到8 个数据库，所有数据都搬走了，服务器停了4 个小时。
后来我使用Canal进行同步，但花了2 周时间才完成历史数据检查。

一致性哈希比较好，但是虚拟节点无法理解。
有一个项目尝试了很久，发现维护脚本写错了，又耽误了一周。

数据段扩容很容易，但是大段的压力会加倍。
我朋友摆姿势的时候，把高并发用户ID切分规则调整了三个版本才达到标准。

4 活跃用户优化 分区表是最方便的。
2 02 3 年第三季度，食品配送系统按活动进行了拆分，在闪购期间扫描区域减少了 6 0%。
但有一个问题：活跃用户数据总是流向几个库，最后添加了一个轮询负载均衡器。

横版记分牌更无情。
某电商公司跨2 0个数据库共享高并发订单表，但表键选择不正确导致跨大表JOIN崩溃。

缓存是关键。
某直播系统将用户画像存储到Redis后，数据库查询慢率从9 9 %下降到0.3 %。
但有一个陷阱：当缓存崩溃时，库实际上崩溃了，最终添加了预热脚本来修复这个问题。

5 主键生成 Snowflake算法是最稳定的。
我参与的项目使用了Snowflake算法+Redis缓存，日请求量1 0万QPS没有任何问题。
但有一个坑：Redis过期时间设置太短，导致ID重复。
重试三次才找到原因。

Sequence的解决方案很简单，但是Oracle的SEQUENCE居然死了一次，花了半天时间才恢复数据。
我尝试MySQL自动增加步长，但是跨库同步时发现步长计算错误。

6 动态切换双写迁移是最安全的。
当特定的物流系统与DataX同步时，衍生工具卡在历史数据上，最终添加临时脚本来批量完成。
当我检查一致性时，发现两个数据库的时间戳相差5 分钟。

灰度发布风险较高。
当某游戏系统流量减少3 0%时，突然发现旧数据库中有很多慢速搜索。
很快就回滚了，分库key又变了2 周。

7 共享策略 垂直零件是最常见的。
在一种特定的支付系统删除登录数据库后，限时抢购界面的速度实际上提高了 8 0%。
但同步延迟导致用户收不到验证码，时间较长，临时添加异步补偿。

水平分表最为复杂。
某O2 O系统按照用户ID对数据进行哈希分片后，发现跨大表的JOIN仍然卡住，最后切换到维度表。
但出现了一个问题：新添加的维度表实际上将主库的CPU提高到了1 00%，最终通过添加分区锁解决了这个问题。

算了，这取决于你。

技术面试必躲不过的一道题：热点账户（数据）处理

哎，说起采访，我当年也遇到过类似的场景。
记得2 01 8 年，在一家互联网公司面试时，被问及热门账号数据的处理。
当时我刚刚接触这个领域，还很不确定。

面试官问：“请告诉我，如果系统中有大量用户同时操作一个热点账户，比如限时抢购期间的产品库存，您会如何设计系统来保证在激烈的竞争下正确更新？”然后我需要实时分析。
闪购场景要求实时性强，数据必须实时更新，不能有延迟。
”
面试官点点头：“那么，强实时场景下，你是如何解决数据更新问题的呢？反超额预订技术，例如事务回滚、无符号整数、条件判断等。
该解决方案的优点？ ”
我说：“我的解决方案可以保证数据一致性，提高系统性能和可扩展性。
比如我可以引入一个缓存层，使用Redis来保证高并发，通过限流、熔断来防止系统过载。
”
面试官听完后点点头说：“是的，你看的很透彻。
”
最终我通过了面试。
这件事让我意识到面试不仅考验你的技术能力，更考验你的思维能力和解决问题的能力。

10年Java开发经验，超过500人面试阿里的同学，总结出这108道面试题！

1 、MySQL索引优化要点：B+树结构、最左前缀原则、覆盖索引。
2 .了解事务隔离级别：未提交读、提交读、重复读、序列化。
3 、Redis主从复制应对雪崩：设置随机过期时间，多级缓存。
4 、三路握手步骤：SYN客户端、SYN+ACK服务器、ACK客户端。
5 、HTTPS加密过程：非对称加密密钥交换、对称加密数据。
6 . URL加载过程：DNS解析、TCP连接、HTTP请求、服务器处理、响应显示。
7 、HashMap的基本结构：数组+链表+红黑树。
8 、堆排序可能的场景：TopK问题，时间复杂度O(nlogk)。
9 、链表常用操作：反转、循环检测、有序链表合并。
1 0、二叉树遍历：层次遍历、最近共同祖先、序列化/反序列化。
1 1 、动态规划典型问题：背包问题、最长公共子序列。
1 2 、进程和线程的区别：进程是资源的单位，线程是调度的单位。
1 3 .Linux OOM 故障排除：top、jmap-heap、jstack。
1 4 、IO模型：阻塞IO、非阻塞IO、复用。
1 5 . JVM垃圾收集算法：标记扫描、复制算法、附加标记。
1 6 、Synchronized和ReentrantLock对比：Synchronized是可重入的，ReentrantLock功能更丰富。
1 7 .线程池参数：核心池大小、最大池大小、保持活动时间、作业队列。
1 8 .单例模式实现：双重检查键、静态内部类、枚举。
1 9 、Spring原理：IOC通过反射和AOP动态代理生成bean。
2 0、闪购系统设计：分层架构、异步下单、库存预热。
2 1 、判定死锁的条件：互斥、占有等待、无优先级、循环等待。
2 2 、项目难点：高并发数据一致性、分布式事务、服务降级。
2 3 、项目优化策略：缓存策略、去同步、限流、链路跟踪。
2 4 .阿里巴巴面试重点：基础深度、项目经验、架构能力。
2 5 .称量一下自己的体重。