分布式系统幂等性设计
一、重复消费：高并发下的定时炸弹
真相：
生产者发送消息后未收到ACK，自动重试。
消费者处理完业务但提交Offset失败，消息被二次投递。后果：资金损失、数据错乱、用户投诉！
二、终极方案：四层防御，滴水不漏
1. 生产端：从源头扼杀重复
招式一：唯一ID
每条消息携带业务主键（如订单ID），类似快递单号。
1Message msg = new Message(); msg.setKey("ORDER_20231111001"); // 唯一标识
招式二：事务消息（如RocketMQ）
本地事务与消息发送绑定，要么全成功，要么全回滚。
2. 消息队列：过滤重复投递
Kafka：开启生产者幂等性+事务。
1enable.idempotence=true transactions.id=my_tx_id
RocketMQ：Broker端根据Message Key去重。
3. 消费端：幂等性设计（核心！）
三大神器：
数据库唯一索引：插入前校验主键。
1INSERT INTO orders (ord ...
微博点赞宕机分析
一、场景痛点分析：为什么传统方案会崩？
String直接计数：INCR命令导致热Key瓶颈（单Key每秒百万级QPS）
重复写入：用户疯狂点击造成数据库雪崩
数据丢失：Redis宕机后点赞数“一夜回到解放前”
💥 传统架构崩溃现场模拟：
1// 错误示例：直接操作Stringpublic void likePost(String postId) { redisTemplate.opsForValue().increment("post:" + postId); // 热Key警告！}
二、终极解决方案：4层架构抵御流量海啸1. 数据结构优化：分片Hash + 二级索引🔑 核心代码：
12345// 分片Hash存储（1024个分片）String postShardKey = "post_like:" + postId + ":shard_" + (postId.hashCode() % 1024);// 原子操作：记录用户点赞并更新计数redisTemplate.execute(new De ...
高效短链系统的设计方案记录
引言当你刷抖音看到“https://v.douyin.com/xyz123”时，当你点开微博的“t.cn/abcd56”时——这些仅有6-8个字符的链接，就是现代互联网的“空间折叠术”：**短链**。
短链是什么？
定义：通过算法将原始长链接（如商品页URL）压缩成极短字符串，实现“轻量化跳转”。
1原链接 → https://www.某电商.com/product/123456789?source=weibo 短链 → t.cn/AbcD12
核心价值：
用户体验：避免长链接在社交平台“刷屏污染”
流量追踪：统计点击量、用户来源等关键数据
安全控制：隐藏真实URL参数，防止恶意篡改
为什么需要千亿级短链系统？以抖音为例：
日均生成量：10亿+条（电商链接、视频分享、广告追踪）
峰值QPS：每秒超50万次生成请求（顶流明星发帖时）
存储规模：千亿级数据需保存3-6个月
一、*场景痛点：为什么你的短链系统会崩？*1. 经典错误方案复现1// 错误案例：直接Hash生成短码（面试中这样答直接挂！） public String createShortUr ...
3tb日增量200gb的es搜索面试题
第一题：分片容量设计（P7必考）面试官：“现有3TB商品数据，日均增长200GB，要求支持万级QPS搜索，如何设计分片策略？”
技术拆解：
避坑指南：
错误案例：某公司直接设置number_of_shards=5导致单分片超过200GB
正确公式：主分片数 = ⌈总数据量 * 1.2 / 30GB⌉
动态扩容方案：
1# 通过_split API扩容POST /products/_split/products_v2{ "settings": { "number_of_shards": 12 }}
冷热数据分离架构：
第二题：深度分页性能压榨（P6+高频考点）面试场景：“用户投诉翻到第50页时系统卡死，日志显示from 10000查询耗时8秒，如何优化？”
技术解析：
优化方案对比：
代码级优化：
12345// 使用Search After实现深度分页SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();sourceBu ...
0心跳检测方案
一、痛点开场：为什么心跳机制“累死人不偿命”？这就是传统心跳机制的痛点：
高开销
每秒百万级心跳请求，服务端CPU直接飙红。
低效
正常服务时浪费资源，故障时检测延迟（比如租约时间是30秒，实际故障可能延迟15秒才被发现）。
问题来了：有没有更优雅的方式？
二、零心跳架构的核心思想：“状态变化由事件驱动，网络状态由底层感知”就像智能路灯：
事件驱动
只有下雨时才亮灯（服务状态变化时才上报）。
被动感知
路灯坏了，路人会立刻通知（TCP层检测连接断开）。
三、零心跳架构设计详解1. 架构图：
** **2. 关键技术实现① 事件驱动：用“智能助手”主动上报状态
角色：Sidecar代理（如Envoy）
像贴身保镖一样挂在应用旁边，监控应用的健康状态（CPU、内存、端口）。
无需应用改代码
Sidecar自动上报状态变化（启动、崩溃、迁移）。
示例配置
12345678# Envoy配置片段：监控应用的HTTP健康检查 health_check: path: "/actuator/health" # 应用的健康检查接口 ...
表1亿数据like查询优化
业务场景某餐饮平台用户评论表 comments 累积了 1亿条数据，包含以下核心字段：
title（评论标题，VARCHAR 255）
content（评论内容，TEXT）
tags（标签，JSON数组，如 ["网红店","火锅","适合拍照"]）
** **用户希望筛选出所有标题含“火锅”、内容提到“服务好”且标签包含“网红店”的评论。对应的SQL语句为：
1SELECT * FROM comments WHERE title LIKE '%火锅%' AND content LIKE '%服务好%' AND tags LIKE '%网红店%';
核心难点：
1.全模糊查询：LIKE '%xx%'导致索引失效，触发全表扫描
B+树按值有序存储，LIKE '%火锅%'需要遍历所有可能的字符组合（如“重庆火锅”“火锅店”），无法通过前缀定位，相当于随机查找。
2.多字段组合：三个字段交叉过滤，传统索引束手无策
即使创建 ...
nacos 是ap还是cp？
某电商平台在促销期间因Nacos集群Leader节点宕机，导致部分服务注册失败，引发线上故障。核心问题：
Nacos作为注册中心，是AP还是CP架构？
Leader节点宕机后，服务注册是否会被阻塞？
一、*CAP理论回顾：为什么注册中心需要AP？*在分布式系统中，CAP理论指出三者不可兼得：
C（一致性）：所有节点数据实时一致
A（可用性）：请求总能获得响应
P（分区容忍性）：网络分区时系统仍能工作
关于更多一致性理论，可以阅读我之前的文章：
分布式事务模型详解
注册中心的抉择：
Zookeeper（CP）：强一致性优先，Leader选举期间服务不可用
Eureka（AP）：高可用优先，容忍短暂数据不一致
Nacos（灵活切换）：支持AP/CP双模式，默认AP模式。AP 是通过 Nacos 自研的 Distro 协议来保证的，CP 是通过 Nacos 的 JRaft 协议来保证的。
****
问题：Nacos 中哪些地方用到了 AP 和 CP？
针对临时服务实例，采用 AP 来保证注册中心的可用性，Distro 协议。
针对持久化服务实例，采用 CP 来保 ...
vue3快速上手（尚硅谷b站）
1. Vue3简介
2020年9月18日，Vue.js发布版3.0版本，代号：One Piece（n
经历了：4800+次提交、40+个RFC、600+次PR、300+贡献者
官方发版地址：Release v3.0.0 One Piece · vuejs/core
截止2023年10月，最新的公开版本为：3.3.4
1.1. 【性能的提升】
打包大小减少41%。
初次渲染快55%, 更新渲染快133%。
内存减少54%。
1.2.【 源码的升级】
使用Proxy代替defineProperty实现响应式。
重写虚拟DOM的实现和Tree-Shaking。
1.3. 【拥抱TypeScript】
Vue3可以更好的支持TypeScript。
1.4. 【新的特性】
Composition API（组合API）：
setup
ref与reactive
computed与watch
……
新的内置组件：
Fragment
Teleport
Suspense
……
其他改变：
新的生命周期钩子
data 选项应始终被声明为一个函数 ...
redis 基础
Redis 是完全开源免费的，遵守 BSD 协议，是一个高性能的 key-value 数据库
Redis 与其它 key/value 缓存产品有以下三个特点：
1、 Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用；2、 Redis不仅支持key-value类型的数据，还提供list，set，zset，hash等数据结构的存储；3、 Redis支持数据的备份，即master-slave模式的数据备份；
Redis 优势
1、 高性能：Redis能读的速度是110000次/s,写的速度是81000次/s；2、 丰富的数据类型：Redis支持Strings,Lists,Hashes,Sets及OrderedSets数据类型操作；3、 **原子型操作:**Redis的所有操作都是原子性的，还支持对几个操作全并后的原子性执行；4、 **丰富的特性:**Redis支持publish/subscribe,通知,key过期等等特性；
Redis 与其它 key-value 存储有什么不同？
1、 Redis支持更多的数 ...
事务详解
一、事务的特性数据库的事务在实现时，会将一次事务中包含的所有操作全部封装成一个不可分割的执行单元，这个单元中的所有操作要么全部执行成功，要么全部执行失败。只要其中任意一个操作执行失败，整个事务就会执行回滚操作
1.原子性事务的原子性指的是构成事务的所有操作要么全部执行成功，要么全部执行失败，不可能出现部分执行成功，部分执行失败的情况
比如A 向 B 转账 100 元，数据库需要进行两个操作，A 的账户要减少 100 元，B 的账户要增加 100 元，这两个操作要么全部执行成功，要么全部执行失败
2.一致性事务的一致性指的是在事务执行之前和执行之后，数据始终处于一致的状态
还是上面转账的例子，如果转账完成后，A 的账户没有减少 100 元或者 B 的账户没有增加 100 元，这就是数据处于不一致状态
3.隔离性事务的隔离性指的是并发执行的两个事务之间互不干扰。也就是说，一个事务在执行过程中不能看到其他事务运行过程的中间状态
还是上面转账的例子，在转账完成之前，其他事务查询 A 的账户或者 B 的账户，余额应该是转账完成之前的余额，而不会查询到 A 的账户减少了 100 元，而 B 的账户 ...
