Fork/Join框架介绍
1. 由一道算法题引发的思考
算法题：如何充分利用多核CPU的性能，快速对一个2千万大小的数组进行排序？
算法题分享：如何高效的实现归并排序
2. Fork/Join框架介绍
2.1 什么是Fork/Join
Fork/Join是一个是一个并行计算的框架，主要就是用来支持分治任务模型的，这个计算框架里的 Fork 对应的是分治任务模型里的任务分解，Join 对应的是结果合并。它的核心思想是将一个大任务分成许多小任务，然后并行执行这些小任务，最终将它们的结果合并成一个大的结果。它适用于可以采用分治策略的计算密集型任务，例如大规模数组的排序、图形的渲染、复杂算法的求解等。
2.2 应用场景
并行计算：
ForkJoinPool 提供了一种方便的方式来执行大规模的计算任务，并充分利用多核处理器的性能优势。通过将大任务分解成小任务，并通过工作窃取算法实现任务的并行执行，可以提高计算效率。
递归任务处理：
ForkJoinPool 特别适用于递归式的任务分解和执行。它可以将一个大任务递归地分解成许多小任务，并通过工作窃取算法动态地将这些小任务分配给工作 ...
两千万数据，20万热点数据如何存储
一、问题本质：缓存系统的“生存游戏”2000万数据中，只有20万是高频访问的“顶流”，剩下1980万都是“冷数据”。这像一场生存游戏——如何让Redis精准淘汰“冷数据”，长期保留“热数据”？以下数据暴露核心矛盾：
Redis内存成本太高
80%请求集中在20%数据（二八法则）
热点数据动态变化（如突发新闻、秒杀商品）
二、三级缓存治理体系1. 第一层：智能淘汰策略（守门员）Redis配置黄金法则：
1# redis.conf关键配置maxmemory 20gb # 按20万数据*1KB计算maxmemory-policy allkeys-lfu # 使用LFU算法（Least Frequently Used）
淘汰策略对比：
策略
特点
适用场景
allkeys-lfu
淘汰访问频率最低
稳定热点（如商品详情）
volatile-ttl
淘汰剩余时间最短
限时活动（如秒杀）
allkeys-random
随机淘汰
无规律访问
2. 第二层：实时热点探测（雷达系统）
Flink实时统计代码：
1234567DataStrea ...
分布式系统幂等性设计
一、重复消费：高并发下的定时炸弹
真相：
生产者发送消息后未收到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 ...
微博点赞宕机分析
一、场景痛点分析：为什么传统方案会崩？
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(ne ...
高效短链系统的设计方案记录
引言当你刷抖音看到“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();so ...
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 选项应始终被声明为一个函数 ...
