这不是概念讲解，全部是选择题/填空题直接套用的数字结论。
每条都带推导，能记住推导就能现场算出来，不靠死背。
已用代码逐一验证，结论可靠。

目录

1. 树：结点 / 边 / 叶子 / 度数
2. 二叉树：层 / 深度 / 完全二叉树 / 满二叉树
3. 二叉链表空指针域 / 线索二叉树
4. AVL 最少结点（斐波那契）
5. 哈夫曼树
6. 卡特兰数（形态数 / 出栈序列 / 括号）
7. 树与森林转换
8. 图：边数 / 度数 / 连通性 / 生成树
9. 线性表：平均移动 / 比较次数
10. 查找：顺序 / 折半 / 哈希装填因子
11. 栈 / 队列 / 串 / 广义表
12. 矩阵压缩存储地址计算
13. 排序：比较次数下界 / 趟数
14. 递推公式速记（汉诺塔 / 斐波那契）
15. 易混易错对照表

一、树：结点 / 边 / 叶子 / 度数

结论 1：n 个结点的树有 n−1 条边

推导：除根结点外，每个结点有且仅有 1 条「父边」指向它。n 个结点中只有根没有父边 → 边数 = n−1。

结论 2（最核心）：任何二叉树 n₀ = n₂ + 1（叶子数 = 度为2的结点数 + 1）

推导（两步）：

• 设度为 0/1/2 的结点数分别为 n₀、n₁、n₂，总结点数 N = n₀ + n₁ + n₂
• 「度」按孩子数算，所有结点的度之和 = 边数 = N−1，即 n₁ + 2n₂ = n₀ + n₁ + n₂ − 1
• 消去 n₁：n₂ = n₀ − 1 → n₀ = n₂ + 1 ✔

结论 3（推广到 m 叉树）：n₀ = 1 + Σ(j−1)·nⱼ（j ≥ 2）

推导：同结论 2，Σ j·nⱼ = N − 1，代入 N = Σ nⱼ 得 n₀ = 1 + n₂ + 2n₃ + 3n₄ + …。

• 特例：满 k 叉树（所有分支结点度为 k），内部结点数 **n_内 = (n₀−1)/(k−1)**，总结点数 **(k·n₀−1)/(k−1)**。

结论 4：已知各度结点数求叶子/总结点

1

边数 E = N − 1 且 Σ(度×个数) = 2E   ← 本质是图的握手定理

例：二叉树中度 1 的结点 3 个、度 2 的结点 5 个 → 叶子 = 5+1 = 6，总结点 = 3+5+6 = 14。

结论 5：森林有 t 棵树、n 个结点，则边数 = n − t

推导：每棵树 nᵢ 个结点有 nᵢ−1 条边，求和 Σ(nᵢ−1) = n − t。

二、二叉树：层 / 深度 / 完全二叉树 / 满二叉树

结论 1：第 i 层最多 2^(i−1) 个结点

等比数列，第一层 1 个，每层翻倍。

结论 2：深度为 k 的二叉树最多 2^k − 1 个结点

1+2+4+…+2^(k−1) = 2^k − 1。达到上限即满二叉树。

结论 3：n 个结点的二叉树

• 最少深度（高度）：⌈log₂(n+1)⌉ = ⌊log₂n⌋ + 1（高度最低=接近满二叉树）
• 最多深度：n（退化为单支链）
• 反推：高度 h 的二叉树，结点数范围 2^(h−1) ≤ n ≤ 2^h − 1

结论 4：完全二叉树（必考）

设 n 个结点（下标从 1 编号）：

n₁ 的推导：n₀ = ⌈n/2⌉，n₂ = n₀−1，故 n₁ = n − n₀ − n₂ = n − 2⌈n/2⌉ + 1。

• n 偶 (2m)：n₁ = 2m − 2m + 1 = 1
• n 奇 (2m+1)：n₁ = 2m+1 − 2(m+1) + 1 = 0

结论 5：满二叉树（深度 k）

• 结点总数 2^k − 1，叶子 **2^(k−1)**，分支结点 2^(k−1) − 1
• 叶子数 = 分支结点数 + 1

结论 6：二叉树 n 个结点，恰好只有 n−1 条边（所有树通用），不可能是 n 条

易混点：二叉树的「度」= 孩子数（≤2）；普通树的「度」= 孩子数；图论里「度」= 邻接边数（含父边）。不同上下文别混用。

三、二叉链表空指针域 / 线索二叉树

结论：n 个结点的二叉链表有 n+1 个空指针域

推导：每个结点 2 个指针域，共 2n 个；n−1 条边用掉 n−1 个（每条边=一个孩子指针），空域 = 2n − (n−1) = n+1。

线索二叉树就是利用这 n+1 个空域存前驱/后继 → 线索数 = n+1。

推广：三叉链表（lchild + rchild + parent）

每条边占 2 个指针（一个孩子指针 + 一个父指针），用掉 2(n−1) 个，共 3n 个域 → 空域 = 3n − 2(n−1) = n+2。

四、AVL 最少结点（斐波那契）

结论：高度为 h 的 AVL 树最少结点数满足

1
2

N(h) = N(h−1) + N(h−2) + 1,   N(0)=0, N(1)=1
即   N(h) = Fib(h+2) − 1

数值速查：

推导：AVL 树左右子树高度差 ≤ 1，要结点最少，就让左子树高度 h−1、右子树高度 h−2（差 1），再加根结点 → 递推式。解斐波那契即得。

反用：含 n 个结点的 AVL 树最大高度 ≈ 1.44·log₂(n+1)（最坏也 O(log n)）。

五、哈夫曼树

结论：n 个叶子（权值）的哈夫曼树有 2n−1 个结点

推导：每次合并两个结点生成一个新内部结点，合并 n−1 次 → 新增 n−1 个内部结点，总 = n + (n−1) = 2n−1。

其他性质

• 哈夫曼树没有度为 1 的结点（n₁ = 0）→ n₀ = n₂ + 1 恒成立
• 权值越小的结点离根越远（编码越长）
• 哈夫曼编码是前缀编码（任一编码不是另一编码的前缀）
• WPL = Σ(权 × 路径长度) 最小；权值互异时 WPL 唯一

六、卡特兰数（形态数 / 出栈序列 / 括号）

公式：Cₙ = C(2n, n) / (n+1)

数值速查：1, 1, 2, 5, 14, 42, 132, 429, 1430…

四大应用（考到就是这几种）

1. n 个结点的二叉树形态数
2. n 个元素进栈，可能的出栈序列数
3. n 对括号的合法匹配数
4. 凸 n+2 边形三角剖分数（即 Cₙ）

记忆推导：把二叉树的左右子树递归拆分，Tₙ = Σ Tₖ·Tₙ₋₁₋ₖ，解出封闭式 C(2n,n)/(n+1)。

例：3 个结点二叉树形态 = C₃ = 5（✓ 符合常识）。

七、树与森林转换

八、图：边数 / 度数 / 连通性 / 生成树

结论 1：握手定理

• 无向图：Σ(顶点度) = 2E，故度之和必为偶数 → 奇度顶点个数必为偶数
• 有向图：Σ入度 = Σ出度 = E

结论 2：完全图边数（必考）

推导：Kₙ 每两点连一条边 = 从 n 个点取 2 个组合数 C(n,2) = n(n−1)/2。

结论 3：连通性最少边数（高频易混，务必分清）

「保证连通」推导：最坏情况是 n−1 个顶点先构成完全图（C(n−1,2) 条边）把第 n 个顶点孤立，再加 1 条边连它 → 任何连线方式下都必然连通。

例：n=5 → 4 个顶点完全图 6 条 + 1 = 7 条（✓ 已验证）。

结论 4：生成树

• 连通图 n 顶点 m 条边 → 生成树恰有 n−1 条边
• 完全图 Kₙ 的生成树个数 = **n^(n−2)**（Cayley 公式）

  K₃ → 3 棵，K₄ → 16 棵

结论 5：平面图（欧拉公式）

• 连通平面图：V − E + F = 2（F 为面数）
• 简单平面图必有 E ≤ 3V − 6；无三角形则 E ≤ 2V − 4
• 推论：K₅、K₃,₃ 都是非平面图

结论 6：欧拉图

• 存在欧拉回路 ⟺ 连通且所有顶点度为偶
• 存在欧拉通路（不回起点）⟺ 连通且恰有 0 或 2 个奇度顶点
• 有向欧拉回路 ⟺ 入度 = 出度（且连通）

结论 7：二分图 ⟺ 无奇环 ⟺ 2-可着色

结论 8：拓扑排序成功 ⟺ 无环（DAG）；序列唯一 ⟺ 每步入度为 0 的顶点恰一个

九、线性表：平均移动 / 比较次数

结论 1：顺序表插入/删除平均移动次数（高频！）

插入推导：在第 i 个位置插入需移动 n−i+1 个，平均 = Σ(n−i+1)/(n+1) = [n+(n−1)+…+0]/(n+1) = n(n+1)/2 ÷ (n+1) = n/2。
删除推导：平均 = Σ(n−i)/n = (n−1)/2。

结论 2：链表插入/删除

• 已知位置指针 → O(1)；已知值 → 需先 O(n) 查找，总体 O(n)。
• 无头结点 vs 有头结点：头插/头删在有头结点时统一逻辑。

十、查找：顺序 / 折半 / 哈希装填因子

结论 1：顺序查找

• 成功 ASL = (n+1)/2；失败 ASL = n+1（比较到末尾再+哨兵）

结论 2：折半查找（基于有序数组）

• 最多比较 ⌊log₂n⌋ + 1 次（判定树高度）
• 成功 ASL ≈ log₂(n+1) − 1（n = 2^k − 1 满判定树时精确）
• 比较次数与元素值无关，只取决于位置（判定树）。

结论 3：哈希表

• 装填因子 α = 表中元素个数 n / 表长 m
• 线性探测：成功 ASL ≈ (1/2)(1 + 1/(1−α))；失败 ASL ≈ (1/2)(1 + 1/(1−α)²)
• 链地址法：成功 ASL ≈ 1 + α/2
• α 越大冲突越多；α > 0.75 时冲突急剧上升（这也是 HashMap 0.75 的由来）

十一、栈 / 队列 / 串 / 广义表

栈

• n 个元素进栈，出栈序列数 = 卡特兰数 Cₙ（见第六节）
• 例：3 个元素进栈有 C₃ = 5 种出栈序列

队列（循环队列，容量 M，头 front 尾 rear）

• 元素个数 = (rear − front + M) % M
• 判空 front == rear；判满 (rear+1) % M == front（留一个空位）
• 判满推导：不留空位的话 front==rear 无法区分空与满（状态数 2^? 表示冲突）

串

• 长度为 n 的串，子串个数 = n(n+1)/2 + 1（含 1 个空串）；非空子串 = n(n+1)/2
• KMP：O(n+m)；朴素匹配最坏 O(n·m)
• next 数组 = 失配时最长公共前后缀长度

广义表

• 长度 = 最外层元素个数；深度 = 括号最大嵌套层数
• 表头 = 第一个元素；表尾 = 除第一个元素外的子表

十二、矩阵压缩存储地址计算（填空必考）

对称矩阵 A[1..n][1..n] 行优先压缩存一维 B

下三角（含对角线）元素总数 = n(n+1)/2。
A[i][j]（i ≥ j）存到 B 的 1-based 下标 k = i(i−1)/2 + j
推导：前 i−1 行共 1+2+…+(i−1) = i(i−1)/2 个元素，第 i 行第 j 列是第 j 个 → k = i(i−1)/2 + j。

• 若 k 从 0 计：k = i(i−1)/2 + j − 1
• 上三角元素 A[i][j]（i<j）用对称性查 A[j][i]

三角矩阵

• 下三角 + 常数 = n(n+1)/2 + 1

三对角矩阵（带宽 1）

• 元素总数 = 3n − 2（第 1、n 行各 2 个，中间 n−2 行各 3 个）

稀疏矩阵

• 三元组表存储：(行, 列, 值)，空间 O(非零元素个数)
• 十字链表适合动态修改

十三、排序：比较次数下界 / 趟数

结论 1：比较排序下界 Ω(n log n)

推导：n 个元素有 n! 种排列，比较排序的决策树是二叉的，区分所有排列至少需要高度 ≥ ⌈log₂(n!)⌉，而 log₂(n!) = n log₂ n − 1.44n ≈ n log₂ n。
→ 归并/快排/堆排的 O(n log n) 就是理论最优（常数内）。

例：n=8 → 至少 ⌈log₂ 8!⌉ = ⌈15.3⌉ = 16 次比较。

结论 2：趟数 / 比较次数速记

结论 3：稳定排序 = 插、冒、归、基（口诀「插冒归基」）

结论 4：已基本有序 → 插入排序最优（O(n)）；内存不够 → 外部归并

十四、递推公式速记（汉诺塔 / 斐波那契）

十五、易混易错对照表

附录：一句话推导精华（考前 5 分钟）

1. 边数 n−1：除根外每点一条父边。
2. n₀=n₂+1：Σ度 = N−1。
3. 完全二叉树叶子 ⌈n/2⌉：满树叶子最多，去掉下层右半边。
4. 空链域 n+1：2n − (n−1)。
5. AVL 最少结点：左高 h−1 + 右高 h−2 + 1 = 斐波那契。
6. 哈夫曼 2n−1：n−1 次合并。
7. **卡特兰 C(2n,n)/(n+1)**：左右子树递归拆分。
8. 握手定理 Σ度=2E：每条边贡献 2。
9. 保证连通 C(n−1,2)+1：最坏 n−1 点全连接 + 1 条边。
10. 顺序表插入 n/2、删除 (n−1)/2：等差求和平均。
11. 折半 ⌊log₂n⌋+1：判定树高度。
12. α = n/m：装填因子。
13. 循环队列 (rear−front+M)%M。
14. 对称矩阵 k = i(i−1)/2 + j。
15. 比较排序下界 n log n：决策树 n! 种排列。

所有数字结论均已用程序验证。考前把「十五、易混易错表」和「附录」过一遍即可。

在分布式系统中，通常一个业务需要跨越多个数据源去远程调用获取数据，而如果在使用传统的单体事务控制，则只能保证调用者所在的数据库的ACID，而无法满足整体的一致性，此时我们就要引入分布式事务

CAP定理

CAP定理，也被称为Brewer定理，是分布式计算中的一个核心概念，它强调了分布式系统中一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）这三个关键属性之间的固有权衡。这一理论由计算机科学家Eric Brewer在2000年首次提出。

CAP定理的组成

• 一致性（Consistency）：在分布式系统中，一致性意味着系统中的所有节点在同一时间看到相同的数据。换句话说，当发生写操作时，所有后续的读操作都应反映该写操作。这是分布式系统数据一致性的基本要求。
• 可用性（Availability）：可用性指的是系统中每个节点对读和写请求的响应能力，即使一些节点经历故障或延迟。一个可用的系统能够确保请求得到响应，但不保证响应中包含最新的写入。
• 分区容忍性（Partition Tolerance）：分区容忍性涉及系统在发生网络分区（即通信失败）时继续运行和提供服务的能力。它要求系统能够容忍消息的丢失或节点间通信的延迟，以保证系统的整体稳定性和可靠性。

CAP定理的核心观点

CAP定理指出，一个分布式系统最多只能同时实现这三个属性中的两个。这是因为在分布式环境中，网络分区是不可避免的，而在分区发生时，系统需要在一致性和可用性之间做出选择。具体来说：

• 如果系统选择保证一致性，那么在网络分区期间可能会牺牲可用性，因为系统需要等待所有节点就绪以保证数据一致。
• 如果系统选择保证可用性，那么在网络分区期间可能会牺牲一致性，因为系统需要允许某些节点响应请求以维持服务。

BASE理论

BASE理论可以看作是CAP定理的一种延伸和补充。CAP定理指出一个分布式系统不可能同时满足一致性、可用性和分区容错性三个属性中的全部，而BASE理论则通过放宽一致性的要求来实现在分区容错性和可用性之间的平衡。因此，在设计分布式系统时，可以根据具体需求选择合适的策略来平衡这三个属性之间的关系。

三个思想

基本可用（Basically Available）

• 定义：系统保证在出现故障或者数据损坏的情况下，依然能够保持核心功能的可用性，并且尽可能地提供其他功能的可用性。这意味着系统应该尽量避免完全不可用的情况，即使部分功能或性能受损，也应保证基本的响应能力。
• 应用场景：在电商网站的高峰期，为了保证系统的整体可用性，可能会采用降级页面或延迟响应等方式，允许部分请求得到响应，但可能牺牲部分实时性或数据一致性。

软状态（Soft State）

• 定义：系统中的数据可以没有时效性，即数据不需要一直保持一致，可以存在一段时间的不一致状态。这种状态是暂时的，系统会通过后续的处理来逐渐将数据状态调整为一致。
• 特点：软状态允许系统在不同节点的数据副本之间进行数据同步的过程存在延时，这种延时不会影响系统的整体可用性。
• 应用场景：在分布式缓存系统中，可能会采用异步复制的方式来进行数据同步，以提高响应速度和吞吐量。这种异步复制方式就体现了软状态的特点。

最终一致性（Eventually Consistent）

• 定义：系统不需要保证在每个节点上的数据都是实时一致的，但是系统会确保所有节点上的数据在经过一定时间的同步后最终达到一致状态。这是一种弱一致性模型，它允许系统在某些时刻不满足强一致性要求，但保证最终数据会一致。
• 应用场景：在社交媒体平台中，用户需要实时地与其他用户进行互动，并获取最新的信息更新。为了提高性能，平台可以采用缓存技术和分布式数据存储，以加速数据访问和查询。在一致性方面，可以采用最终一致性的策略，即用户可以看到稍有延迟的最新数据，而不需要立即保证所有数据副本的一致性。

分布式事务模型

解决分布式事务，各个子系统之间必须能感知彼此的事务状态，才能保持状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。这里的子系统事务称为分支事务，有关联的各个分支事务在一起称为全局事务。

Seata

Seata是一款开源的分布式事务解决方案，由阿里巴巴发起并维护，致力于提供高性能和简单易用的分布式事务服务。它支持多种分布式事务模式，包括AT（原子性事务）、TCC（尝试、确认、取消）、Saga（有限状态机）和XA（两阶段提交）等，为用户打造一站式的分布式解决方案。以下是关于Seata的详细介绍：

三个重要角色

1. TC（Transaction Coordinator）- 事务协调者：

   • 职责：维护全局和分支事务的状态，协调全局事务的提交或回滚。它是事务管理的核心，负责接收来自事务管理器（TM）的请求，并根据这些请求来驱动资源管理器（RM）执行相应的操作。
   • 特点：TC是一个独立的微服务，通常作为单独部署的Server服务端运行，不包含任何业务代码，仅负责事务的协调工作。

2. TM（Transaction Manager）- 事务管理器：

   • 职责：定义全局事务的范围，开始全局事务，提交或回滚全局事务。它是分布式事务的入口，负责在业务逻辑开始时开启一个全局事务，并在业务逻辑结束时根据执行结果来决定是提交还是回滚这个全局事务。
   • 特点：TM通常被嵌入到应用中的Client客户端，通过拦截业务方法的执行来监控全局事务的范围。它会与TC进行交互，以注册全局事务、报告事务状态等。

3. RM（Resource Manager）- 资源管理器：

   • 职责：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。它是事务的参与者，负责执行具体的分支事务操作，如数据库操作、服务调用等。

   • 特点：RM同样被嵌入到应用中的Client客户端，与TM一起协作完成全局事务的执行。它会在TC的协调下，执行本地事务的提交或回滚操作，以确保全局事务的一致性。

Seata工作模式

1.XA模式

• 简介：基于数据库的XA协议来实现两阶段提交（2PC）。
• 工作原理：通过XA协议来管理分布式事务，确保全局事务的一致性和完整性。
• 适用场景：适用于强一致性的场景，如金融、银行等。
• 工作流程：由TM通知TC开启全局事务，TM调用其中的每一个RM，RM开始将自己注册到TC中，并开始执行自己的业务sql，在执行过后向TC报告事务状态，在所有RM执行完后，由TM通知TC要开始决策是提交还是回滚事务，TC根据刚才每一个RM报告的事务状态通知每一个RM是执行提交还是回滚
• 优点：事务的强一致性，满足ACID原则，常用数据库都支持，实现简单，没有代码侵入
• 缺点：TC需要等待每一个RM将状态报告完毕，才能进行决定提交或回滚，这是同步的，性能较差，依赖关系型数据库实现事务

2.AT模式（默认模式）

• 简介：提供无侵入自动补偿的事务模式，目前已支持MySQL、Oracle、PostgreSQL、TiDB和MariaDB等数据库。
• 工作原理：通过协调各个分支事务的执行状态，确保分布式事务的一致性。如果发生异常，Seata能够协调回滚所有相关分支事务，保持数据的一致性。
• 适用场景：适用于需要强一致性的分布式事务场景。
• 工作流程：由TM通知TC开启全局事务，TM调用其中的每一个RM，RM开始将自己注册到TC中，并开始执行自己的业务sql并提交，记录更新前后的快照，向TC报告事务状态，待所有RM执行完后，TM通知TC提交或回滚全局事务，TC根据RM报告的状态是否一致，若全部成功，则通知RM删除快照数据，若有一个失败，则根据之前的快照数据进行回复并删除快照数据
• 与XA区别：XA模式第一阶段不提交事务，锁定资源，AT模式一阶段直接提交事务，不锁定资源。XA模式依赖数据库机制实现回滚，AT模式利用数据快照实现数据回滚。XA模式强一致，AT模式最终一致
• 优点：一阶段直接提交事务，释放数据库资源，性能比较好，利用全局锁实现读写隔离，没有代码侵入，框架自动完成回滚和提交
• 缺点：两阶段中间属于软状态，属于最终一致，框架的快照功能会影响性能，但比XA模式要好很多

3.TCC模式

• 简介：Try Confirm/Cancel，即尝试、确认、取消模式。
• 工作原理：首先执行Try操作，用于尝试执行分支事务；如果所有分支事务的Try操作都成功，则执行Confirm操作，用于确认并提交已经执行的分支事务；如果任何分支事务的Try操作失败，或者在Confirm操作期间发生了异常，则执行Cancel操作，用于回滚已经执行的分支事务。
• 适用场景：对业务代码侵入性较强，必要时可能还要修改数据库，适用于需要高度灵活控制事务流程的场景。
• 工作流程：整体的工作流程与AT模式较为相似，TCC模式通过编程的方式实现事务控制逻辑，需要开发者在业务代码中显式地编写Try、Confirm和Cancel三个阶段的逻辑。Try阶段用于执行业务逻辑并预留必要的资源，Confirm阶段用于在Try阶段成功后实际提交事务，Cancel阶段则用于在Try或Confirm失败时回滚预留的资源。
• 优点：一阶段直接提交事务，释放数据库资源，性能好，相比AT模型，无需生成快照，无需使用全局锁，性能最强。不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
• 缺点：有代码侵入，需要认为编写try,confirm,cancel接口，太麻烦。软状态，事务时最终一致。需要考虑confirm和cancel的失败情况，做好幂等处理

4.Saga模式

• 简介：长事务解决方案，基于状态机来实现。
• 工作原理：业务流程中每个参与者都提交本地事务，当出现某一个参与者失败时，则补偿前面已经成功的参与者。一阶段正向服务和二阶段补偿服务都由业务开发实现。
• 适用场景：业务流程长、业务流程多，参与者包含其它公司或遗留系统服务，无法提供TCC模式要求的三个接口。
• 工作流程：第一阶段直接提交本地事务，的第二阶段成功则什么也不做，失败则通过补偿业务来回滚
• 优点：事务参与者可以基于事件驱动实现异步调用，吞吐高。一阶段直接提交事务，无锁性能好。不用编写TCC的三个阶段，实现简单
• 缺点：软状态持续时间不确定，时效性差。没有锁，没有事务隔离，会有脏写

消息丢失的可能性

• 发送时丢失：
  • 生产者发送的消息未送达exchange
  • 消息到达exchange后未到达queue
• MQ宕机，queue将消息丢失
• consumer接受到消息后未消费就宕机

根据以上几种可能，我们分别有生产者消息确认，消息持久化，消费者消息确认和消费失败重试机制来解决以上的问题

生产者消息确认

RabbitMQ提供了发送者确认和发送者回执两种机制来确认消息不会在发送过程中丢失

Publisher Confirm（发送者确认）

Publisher Confirm机制是RabbitMQ用来确保消息被成功发送到RabbitMQ服务器（至少是成功到达交换机）的一种机制。当启用这个机制时，RabbitMQ会向生产者（publisher）发送一个确认（ack）或否定确认（nack）来告知消息是否被成功处理。

• ack（确认）：当消息成功到达交换机时，RabbitMQ会向生产者发送一个ack，表示消息已经被正确处理。
• nack（否定确认）：如果RabbitMQ因为内部错误（如资源不足）而无法处理消息，它会发送一个nack给生产者。但需要注意的是，在标准的RabbitMQ行为中，如果消息因为路由键不匹配任何队列而被交换机丢弃，RabbitMQ不会发送nack，而是可能通过publisher return机制来处理。

Publisher Return（发送者回执）

Publisher Return是RabbitMQ提供的另一种机制，用于处理那些无法路由到任何队列的消息。当消息被交换机接收，但由于没有匹配的绑定（即没有队列订阅了消息所使用的路由键）而无法投递到任何队列时，RabbitMQ会将这个消息返回给生产者，并附带一个路由失败的原因。

• 返回消息：消息本身会被返回给生产者，同时还会附带一个Basic.Return命令，其中包含路由失败的原因（如路由键未找到匹配的队列）。
• 注意：这里重要的是要理解，publisher return并不与ack或nack直接相关。ack/nack是确认消息是否到达交换机的，而publisher return是处理那些已经到达交换机但无法被路由到任何队列的消息的。

如何实现

首先添加配置

1
2
3
4
5
6
7

spring:
 rabbitmq:    
  publisher-confirm-type: correlated 
  publisher-returns: true     
  template:      
    mandatory: true

配置说明：

• publish-confirm-type：开启publisher-confirm，这里支持两种类型：
  • simple：同步等待confirm结果，直到超时
  • correlated：异步回调，定义ConfirmCallback，MQ返回结果时会回调这个ConfirmCallback
• publish-returns：开启publish-return功能，同样是基于callback机制，不过是定义ReturnCallback
• template.mandatory：定义消息路由失败时的策略。true，则调用ReturnCallback；false：则直接丢弃消息

配置这两方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

@Slf4j
@Configuration
public class CommonConfig implements ApplicationContextAware {
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        // 获取RabbitTemplate
        RabbitTemplate rabbitTemplate = applicationContext.getBean(RabbitTemplate.class);
        //设置confirmCallback  判断是否到达交换机
        rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
            /**
             * @param correlationData  自定义的数据
             * @param ack  是否确认
             * @param cause  原因
             */
            @Override
            public void confirm(CorrelationData correlationData, boolean ack, String cause) {
                    if(ack){
                        // 3.1.ack，消息成功
                        log.debug("消息发送成功, ID:{}", correlationData.getId());
                    }else{
                        // 3.2.nack，消息失败
                        log.error("消息发送失败, ID:{}, 原因{}",correlationData.getId(), cause);
                    }
            }
        });
        // 设置ReturnCallback  处理无法路由到队列的消息
        rabbitTemplate.setReturnCallback((message, replyCode, replyText, exchange, routingKey) -> {
            // 投递失败，记录日志
            log.info("消息发送失败，应答码{}，原因{}，交换机{}，路由键{},消息{}",
                    replyCode, replyText, exchange, routingKey, message.toString());
            // 如果有业务需要，可以重发消息
        });

        
    }

消息持久化

在写代码过程中，交换机，队列和消息都是默认持久化的，不需要做额外的操作，这里为了更好的理解，将显示调用如何持久化，在实际生产过程中，一下步骤并不需要做

交换机持久化

1
2
3
4
5

@Bean
public DirectExchange simpleExchange(){
    // 三个参数：交换机名称、是否持久化、当没有queue与其绑定时是否自动删除
    return new DirectExchange("simple.direct", true, false);
}

队列持久化

1
2
3
4

@Bean
   public Queue simpleQueue(){
       return new Queue("simple.queue",true);
   }

消息持久化

1
2
3
4

Message msg = MessageBuilder
    .withBody(message.getBytes(StandardCharsets.UTF_8)) // 消息体   
    .setDeliveryMode(MessageDeliveryMode.PERSISTENT) // 持久化         
    .build();

消费者消息确认

RabbitMQ支持消费者确认机制，即：消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息。而SpringAMQP则允许配置三种确认模式：

•manual：手动ack，需要在业务代码结束后，调用api发送ack。

•auto：自动ack，由spring监测listener代码是否出现异常，没有异常则返回ack；抛出异常则返回nack

•none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除，此种较为危险，如果消费者获取消息后，在处理消息的过程中发生异常，那么此时消息以及被删除，即消息丢失

配置方式

1
2
3
4
5

spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: none # 关闭ack

在auto方法中，如果消费者消费消息时出现了异常，消息并不会丢失，而是会重新回到队列中再次发消息，知道消息能够接收成功，所以这里就需要搭配上消息重试机制，否则消息就会一直无限次被发往交换机，对服务器的压力会很大

失败重试机制

开启失败重试

我们可以利用Spring的retry机制，在消费者出现异常时利用本地重试，而不是无限制的requeue到mq队列。

修改consumer服务的application.yml文件，添加内容：

1
2
3
4
5
6
7
8
9
10

spring:
  rabbitmq:
    listener:
      simple:
        retry:
          enabled: true # 开启消费者失败重试
          initial-interval: 1000ms # 初识的失败等待时长为1秒
          multiplier: 1 # 失败的等待时长倍数，下次等待时长 = multiplier * last-interval
          max-attempts: 3 # 最大重试次数
          stateless: true # true无状态；false有状态。如果业务中包含事务，这里改为false

重启consumer服务，重复之前的测试。可以发现：

• 在重试3次后，SpringAMQP会抛出异常AmqpRejectAndDontRequeueException，说明本地重试触发了
• 查看RabbitMQ控制台，发现消息被删除了，说明最后SpringAMQP返回的是ack，mq删除消息了

结论：

• 开启本地重试时，消息处理过程中抛出异常，不会requeue到队列，而是在消费者本地重试
• 重试达到最大次数后，Spring会返回ack，消息会被丢弃

在以上重试机制下，如果到达了最大重试次数，消息依然会丢失，所以我们要根据失败重试策略来处理

失败消息处理策略

在开启重试模式后，重试次数耗尽，如果消息依然失败，则需要有MessageRecovery接口来处理，它包含三种不同的实现：

• RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式

• ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队

• RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机

死信交换机

当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）：

• 消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false
• 消息是一个过期消息，超时无人消费
• 要投递的队列消息满了，无法投递

如果这个包含死信的队列配置了dead-letter-exchange属性，指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange，检查DLX）。使用死信交换机需要将队列上绑定deadLetterExchange和deadLetterRoutingKey，根据这里我们可以知道，他的效果与全局配置失败消息处理策略差不多，下面我将对比两者的优劣。

死信交换机的劣势和优势

劣势

1. 配置复杂性：使用死信交换机需要在队列创建时额外配置dead-letter-exchange和dead-letter-routing-key属性，增加了配置的复杂性。
2. 性能开销：当消息被发送到死信交换机时，需要经过额外的路由和存储过程，可能会对系统性能造成一定影响。
3. 管理复杂性：需要管理额外的死信队列和交换机，增加了系统的管理复杂性。

优势

1. 灵活性：可以为不同的队列设置不同的死信交换机和死信队列，提供了更高的灵活性。
2. 可追踪性：所有发送失败的消息都会被收集到死信队列中，便于追踪和定位问题。
3. 可扩展性：可以根据需要增加死信队列的数量和容量，以应对更高的失败消息量。

配置消息失败处理策略的优势和劣势

劣势

1. 全局性：该策略是全局性的，可能无法针对特定队列或消息类型进行细粒度的控制。
2. 局限性：只能实现简单的重试逻辑，无法像死信交换机那样提供多种失败消息处理策略。
3. 缺乏灵活性：无法根据消息的失败原因或类型来动态选择处理策略。

优势

1. 配置简单：只需在全局范围内配置一次，即可应用于所有相关的消息处理。
2. 易于实现：通过实现MessageRecovery接口，可以轻松地定义失败消息的重试逻辑。
3. 性能影响小：由于不需要额外的队列和交换机，对系统性能的影响相对较小。

综合比较

延迟消息

通过死信交换机我们可以达到延迟队列的效果，只需要为需要延迟发放消息的队列设置过期之间或者为消息设置过期时间，并且不给这个队列绑定消费者，到时间过期后，消息就会进入死信交换机，我们将要处理消息的消费者绑定到死信队列上，就可以达到延迟消息的功能，不过rabbitMQ现在推出的有专门做延迟消息的方法，所以这种方法不经常使用

使用 RabbitMQ 插件实现延迟队列

RabbitMQ 社区提供了一个非常方便的插件 rabbitmq-delayed-message-exchange，它允许你直接在交换机级别设置消息的延迟时间，而无需使用死信队列的复杂设置。使用这种方法，你可以：

1. 安装插件：首先，你需要在 RabbitMQ 服务器上安装 rabbitmq-delayed-message-exchange 插件。
2. 定义延迟交换机：在 RabbitMQ 管理界面或通过 API 定义一个类型为 x-delayed-message 的交换机。
3. 发送延迟消息：当发送消息到该交换机时，你可以在消息的头部（header）中指定延迟时间（以毫秒为单位）。
4. 绑定队列：像普通交换机一样，将队列绑定到这个延迟交换机上。
5. 消费者监听：消费者监听这个队列，当消息的延迟时间到达后，消息将被发送到队列中，消费者可以像处理普通消息一样处理它。

惰性队列

消息堆积问题

当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。

解决消息堆积有三种思路：

• 增加更多消费者，提高消费速度。也就是我们之前说的work queue模式
• 扩大队列容积，提高堆积上限
• 在消费者内开启线程池加快消息处理速度

根据第二条思路，我们提出了一种解决办法就是引入惰性队列

引入惰性队列

从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。惰性队列的特征如下：

• 接收到消息后直接存入磁盘而非内存
• 消费者要消费消息时才会从磁盘中读取并加载到内存
• 支持数百万条的消息存储

由于消息存入的时磁盘，所以消息可存储的量大大提高了，并且普通队列可能会因为内存中的消息过多而需要定期将部分消息写入磁盘以释放内存空间，这个过程称为page-out。而惰性队列由于直接写入磁盘，避免了这种间歇性的page-out操作，从而提高了系统的稳定性。

声明惰性队列

1
2
3
4
5
6
7
8
9
10
11
12
13

// 惰性队列
@Bean
public Queue lazyQueue(){
    return QueueBuilder.durable("lazy.queue")
            .lazy()
            .build();
}
// 普通队列
@Bean
public Queue normalQueue(){
    return QueueBuilder.durable("normal.queue")
            .build();
}

不过惰性队列也有缺陷，例如性能受限于磁盘IO，基于磁盘存储，消息时效性也会降低

集群

在面对高并发的问题中，我们通常会选择采用集群来解决，在RabbitMQ中的集群有两种模式

• 普通集群：是一种分布式集群，将队列分散到集群的各个节点，从而提高整个集群的并发能力。

• 镜像集群：是一种主从集群，普通集群的基础上，添加了主从备份功能，提高集群的数据可用性。

镜像集群虽然支持主从，但主从同步并不是强一致的，某些情况下可能有数据丢失的风险。因此在RabbitMQ的3.8版本以后，推出了新的功能：仲裁队列来代替镜像集群，底层采用Raft协议确保主从的数据一致性。

普通集群

优势：

1. 负载均衡：普通集群通过将队列分散到集群的各个节点上，实现了负载均衡，提高了整个集群的并发能力。这有助于优化资源使用，提高系统的响应速度和吞吐量。
2. 高扩展性：随着业务需求的增长，普通集群可以通过添加更多的服务器节点来轻松扩展其性能和存储能力。这种横向扩展能力使得集群能够适应不断变化的需求。
3. 高可靠性：虽然普通集群不直接提供数据冗余，但通过将队列分散到多个节点上，可以在一定程度上提高系统的可靠性。当某个节点出现故障时，其他节点仍然可以处理消息。

劣势：

1. 数据可用性风险：普通集群不保证数据的冗余存储，因此当队列所在的节点宕机时，队列中的消息可能会丢失。这增加了数据丢失的风险。
2. 配置和维护复杂性：管理多个节点和确保它们之间的正确通信需要复杂的配置和维护工作。这可能会增加运维成本和难度。

镜像集群

优势：

1. 高可用性：镜像集群通过在不同节点上创建队列的镜像来提供高可用性。即使某个节点出现故障，其他节点上的镜像队列仍然可以继续处理消息，确保服务的连续性。
2. 数据可靠性：镜像集群通过同步队列的元数据和消息到多个节点，提高了数据的可靠性。即使某个节点上的数据丢失，也可以从其他节点上的副本中恢复。

劣势：

1. 性能开销：由于需要在多个节点之间同步队列的元数据和消息，镜像集群可能会引入额外的性能开销。这可能会影响系统的响应速度和吞吐量。
2. 无法线性扩容：镜像集群中的每个节点都包含整个集群的数据副本，这限制了集群的线性扩容能力。当单个节点的存储容量达到上限时，可能需要采取其他措施（如增加单个节点的存储容量或重新设计集群架构）来扩展集群。

仲裁队列

优势：

1. 高一致性：仲裁队列基于Raft共识算法或其变种，确保了数据在多个节点之间的一致性。这种一致性是强一致的，有助于减少数据丢失的风险。
2. 非阻塞复制：仲裁队列在复制数据时不会阻塞队列的其他操作，这有助于提高系统的可用性和性能。即使某个节点出现故障并重新上线，主副本也可以从从副本中断的地方开始复制消息，而无需同步整个队列的数据。

劣势：

1. 资源消耗：仲裁队列需要消耗更多的内存和磁盘资源来存储数据的多个副本。这可能会增加系统的运行成本。
2. 适用场景限制：仲裁队列适用于对队列容错和数据安全要求高、对延迟和队列特性要求相对低的场景。在可能出现消息大量堆积的场景中，仲裁队列的写入放大会造成成倍的磁盘占用，因此可能不适合使用。

在单点的redis中，redis经常面临着数据丢失，并发能力弱，故障恢复能力弱，以及存储能力弱，这都使其在微服务的架构中难以立足，接下来，我将以这四方面的问题出发，介绍每一种问题的解决办法

Redis持久化

由于redis时基于内存存储，这会导致一旦服务器重启，存储在服务器中redis的数据将会丢失，即使redis中存储的一般是相对与不那么重要的热点数据，但一旦丢失，仍会造成很大的影响，解决这个问题自然要做到redis数据的持久化，常见的持久化分为两种，分别是RDB和AOF

RDB持久化

RDB持久化通过创建Redis在某一时间点的快照（snapshot）来实现数据的持久化。这个快照文件是一个经过压缩的二进制文件，包含了Redis在某个时间点上的数据库状态。简单来说就是把内存中所有数据记录到磁盘中，当redis重启后，从磁盘中读取快照文件，恢复数据

RDB持久化的工作原理

1. 触发条件：RDB持久化可以通过两种方式来触发：
   • 手动触发：通过执行SAVE或BGSAVE命令。SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，因此不推荐在生产环境中使用。而BGSAVE命令会创建一个子进程来负责创建RDB文件，这样Redis服务器进程可以继续处理客户端请求，不会造成阻塞。
   • 自动触发：Redis配置文件中可以设置一些条件，当满足这些条件时，Redis会自动执行BGSAVE命令。例如，可以设置“在一定时间内，如果修改了指定数量的键，则自动执行BGSAVE”，在停机前也会自动触发一次快照。
2. 快照生成：当BGSAVE命令执行时，Redis会创建一个子进程，这个子进程会遍历当前数据库中的所有键值对，并将它们写入到一个临时文件中。当所有键值对都写入完成后，这个临时文件会被替换为旧的RDB文件，从而实现数据的持久化。
3. 数据恢复：当Redis服务器启动时，如果检测到RDB文件存在，Redis会自动加载RDB文件中的数据到内存中，从而实现数据的恢复。

RDB持久化的优缺点

优点：

• RDB文件是一个紧凑的二进制文件，它保存了Redis在某个时间点的完整数据快照，非常适合用于数据备份和灾难恢复。
• RDB文件的生成和加载速度都比较快，因此可以在较短的时间内完成数据的备份和恢复。
• RDB持久化对Redis服务器的性能影响较小，尤其是在使用BGSAVE命令时。

缺点：

• RDB持久化是基于快照的，因此它可能会丢失最后一次快照之后到Redis停机之间的数据。
• 如果Redis中的数据量非常大，那么RDB文件的生成可能会消耗较多的CPU和内存资源，并且生成RDB文件的时间也会比较长。

COW(Copy-On-Write)写时复制

在Redis的RDB持久化过程中，COW技术主要通过操作系统的fork系统调用来实现。具体过程如下：

1. fork子进程：
   • 当Redis执行bgsave命令时，会调用操作系统的fork()函数来创建一个子进程。这个子进程是父进程（即Redis主进程）的一个完整副本，包括内存空间、文件描述符等。
   • fork操作完成后，子进程和父进程共享相同的内存空间，但此时内存空间是被标记为只读的。
2. 写时复制：
   • 在子进程开始执行RDB持久化任务（即将内存数据写入磁盘文件）的过程中，如果父进程（Redis主进程）需要修改内存中的数据，操作系统会检测到这种写操作，并触发COW机制。
   • 触发COW机制后，操作系统会复制被修改的内存页到一个新的位置，并将父进程的内存页指针指向这个新位置。这样，父进程就可以在不影响子进程的情况下继续执行写操作。
   • 子进程则继续在其原始的内存页（只读）上执行RDB持久化任务，直到完成。
3. RDB文件生成：
   • 子进程完成所有内存数据的遍历和写入后，会生成一个完整的RDB文件，并将其保存到磁盘上。
   • 父进程（Redis主进程）则继续处理客户端的请求，不受子进程持久化操作的影响。

AOF持久化

AOF（Append Only File）持久化是Redis数据库中的一种数据持久化方式，主要通过保存数据库执行的写命令来记录数据库的状态。以下是对AOF持久化的详细介绍：

AOF持久化的基本原理

AOF持久化以日志的形式记录每个写操作，包括数据的增加、删除、修改等，但不记录读操作。Redis服务重启时，会根据AOF文件中的命令重新执行一遍，以达到恢复数据的目的。AOF文件是一个仅追加的日志文件，即使在写入过程中发生宕机，也不会破坏已存在的内容。

AOF持久化的流程

AOF持久化主要分为以下几个步骤：

1. 命令追加：
   • 当AOF持久化功能处于开启状态时，服务器在执行完一个写命令后，会将该命令以协议格式追加到AOF文件数据缓冲区（aof_buf）中。
2. 文件写入：
   • 在每一个事件循环结束前，Redis会调用flushAppendOnlyFile函数，将aof_buf中的内容写入到AOF文件中。
3. 文件同步：
   • AOF文件会根据appendfsync参数设置的持久化策略同步到磁盘。Redis提供了三种同步策略：
     • Always：每次写命令写入aof_buf后，都同步将aof_buf中的写命令fsync到磁盘。这种方式可靠性最高，但性能影响最大。
     • Everysec：每次写命令写入aof_buf后，每隔一秒将aof_buf中的写命令fsync到磁盘。这是默认策略，性能适中，最多丢失一秒的数据。
     • No：写命令写入aof_buf后，由操作系统决定何时将aof_buf中的写命令fsync到磁盘。这种方式性能最好，但宕机时丢失的数据最多。

AOF文件重写

随着写入AOF内容的增加，AOF文件会变得越来越大，这不仅会占用大量的磁盘空间，还会增加Redis服务重启时的数据恢复时间。为了解决这个问题，Redis提供了AOF文件重写机制。

AOF文件重写的触发机制有两种：

1. 手动触发：通过执行BGREWRITEAOF命令。
2. 自动触发：与auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个参数有关。当AOF文件大小超过上一次重写后AOF文件大小的指定百分比（默认为100%）且AOF文件大小大于指定最小值（默认为64MB）时，会自动触发重写。

重写过程中，Redis会fork出一个子进程来处理重写操作，父进程继续处理其他客户端命令请求。子进程根据内存中的当前数据状态，生成一个新的AOF文件，并替换掉旧的AOF文件。

AOF持久化的优缺点

优点：

1. 数据安全性高：AOF持久化提供了多种同步策略，可以根据需要选择最适合的同步方式，确保数据的可靠性。
2. 易于恢复：AOF文件内容易于理解，方便进行手动修复和恢复。
3. 灵活性高：AOF文件是追加写入的，即使出现写入故障，也不会破坏已存在的数据。

缺点：

1. 文件体积大：AOF文件通常比相同数据集的RDB文件大，占用更多的磁盘空间。
2. 恢复速度慢：当AOF文件很大时，Redis服务重启时的数据恢复时间会比较长。
3. 性能影响：AOF持久化对性能有一定的影响，尤其是在使用Always同步策略时。

两种持久化的对比

Redis主从集群

Redis通过搭建主从集群，主节点负责写操作，将数据同步给从节点，从节点负责读操作，通过这样的读写分离，可显著提高redis处理高并发问题的能力

主从集群的工作原理

1. 数据复制：
   • 当主节点接收到写操作时，它会先将数据写入本地，并将写操作记录到复制缓冲区中。
   • 从节点通过定期发送SYNC命令或PSYNC命令向主节点请求数据同步。
   • 主节点在接收到同步请求后，会将复制缓冲区中的数据发送给从节点，从而实现数据的同步。
2. 读写分离：
   • 客户端通过配置或负载均衡器将写请求发送到主节点，将读请求发送到从节点。
   • 这种方式可以显著提高系统的吞吐量和响应速度，因为读操作通常比写操作更频繁且对实时性要求较低。
3. 故障转移：
   • 在主节点出现故障时，从节点可以通过选举机制或外部管理工具（如Redis Sentinel）自动或手动升级为主节点，以接管写操作。
   • 同时，其他从节点会重新与新的主节点建立同步关系，确保数据的一致性和可用性。

配置主节点

1. 修改Redis配置文件

   （例如，

   1	redis.conf

   ）：

   • 设置bind指令以监听所有网段（如果需要远程访问）或特定IP地址。
   • 开启守护进程模式（daemonize yes）。
   • 配置日志文件和工作目录。
   • 开启AOF或RDB持久化功能（根据需要）。

2. 重启Redis服务：

   • 应用配置文件更改后，重启Redis服务以使更改生效。

配置从节点

1. 复制Redis配置文件：
   • 为每个从节点复制一份Redis配置文件，并进行适当的修改。
2. 修改从节点配置文件：
   • 设置不同的端口号以避免冲突（例如，6380、6381等）。
   • 配置replicaof（在Redis 5.0之前为slaveof）指令，指定主节点的IP地址和端口号。
   • 配置其他必要的参数，如持久化、日志记录等。
3. 启动从节点Redis服务：
   • 使用修改后的配置文件启动从节点的Redis服务。

主从集群的第一次数据同步

建立连接与协商

• 执行命令：在从节点上执行replicaof（Redis 5.0之前使用slaveof）命令，指定主节点的IP地址和端口号。
• 发送请求：从节点向主节点发送数据同步请求。
• 判断首次同步：主节点接收到同步请求后，会判断这是否是第一次同步。判断依据通常是从节点发送的replication ID（简称replid）与主节点不一致，如果是第一次同步，则拒绝增量同步而是用全量同步，通过偏移量（offset）判断是否需要同步数据，在判断是第一次同步后，主节点会将自己的replid和offset传给从节点，让从节点继承他的replid。

准备数据快照

• 生成RDB文件：主节点执行bgsave命令，在后台生成当前数据库的快照（RDB文件）。这个过程中，主节点仍然可以正常处理客户端的请求。
• 记录新命令：在生成RDB文件的过程中，主节点会将新接收到的写操作命令记录在repl_backlog缓冲区中，以确保这些操作在后续能够同步给从节点。

发送RDB文件

• 传输文件：RDB文件生成后，主节点会将该文件发送给从节点。
• 清空并加载数据：从节点接收到RDB文件后，会先清空本地数据库，然后加载RDB文件中的数据。

同步增量数据

• 发送repl_backlog中的命令：在从节点加载完RDB文件后，主节点会将repl_backlog缓冲区中记录的、在RDB文件生成之后接收到的所有写操作命令发送给从节点。
• 执行命令：从节点接收到这些命令后，会重新执行它们，以确保与主节点的数据完全一致。

完成同步

• 建立持续复制：完成上述步骤后，主从节点之间会建立起一个持续复制的连接。主节点会将后续接收到的所有写操作命令实时同步给从节点，以保持数据的一致性。

主从集群的非第一次数据同步

1. 记录偏移量：
   • 主节点和从节点都会维护一个偏移量（offset），用于记录当前复制的位置。
   • 每次主节点处理完写操作后，都会更新自己的偏移量。
2. 从节点请求同步：
   • 从节点会定期（或根据配置）向主节点发送自己的偏移量和复制ID（replid），如果是非第一次同步，则从节点的replid和主节点是一致的，则进行增量同步，请求同步。
3. 主节点判断同步方式：
   • 主节点接收到从节点的请求后，会比较从节点的偏移量和自己的偏移量。
   • 如果从节点的偏移量小于主节点的偏移量，说明从节点有部分数据未同步，此时将执行增量同步，如果从节点的复制偏移量在repl_backlog中找不到对应的数据（即该偏移量对应的数据已经被覆盖），可能是因为repl_backlog的大小达到上限或是从节点断开太久，环形缓冲区中的数据被覆盖，则此时应该改进全量同步。
4. 发送增量数据：
   • 主节点会从自己的repl_backlog缓冲区中，获取从节点偏移量之后的写操作命令。
   • 将这些增量数据发送给从节点。
5. 从节点执行命令：
   • 从节点接收到增量数据后，会按顺序执行这些命令，更新自己的数据集。
6. 更新偏移量：
   • 从节点执行完命令后，会更新自己的偏移量，并上报给主节点。

主从集群优化

• 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO
• Redis单节点上的内存不要占太大，减少RDB导致的过多磁盘IO
• 适当提高repl_backlog的大小，发现slave宕机尽快实现故障修复，尽量避免全量同步
• 限制一个matser的slave的节点数量，如果实在太多slave，尽可能采取主-从-从链式结构，减少matser压力

Redis哨兵集群

Redis的哨兵集群（Redis Sentinel）是一个高可用的解决方案，它主要用于管理多个Redis服务器实例，提供监控、自动故障转移和通知功能。

哨兵集群的组成

• 哨兵节点：哨兵集群由多个哨兵节点组成，每个哨兵节点都是一个运行在特殊模式下的Redis进程，但它不提供读写服务，主要用于监控和管理Redis服务器。
• Redis服务器实例：哨兵集群监控的Redis服务器实例包括主节点（master）和从节点（slave）。主节点负责处理客户端的读写请求，而从节点则复制主节点的数据，并在主节点故障时接替其工作。

哨兵集群的工作原理

1. 监控：哨兵节点会周期性地向所有被监控的Redis服务器实例发送PING命令，以检测它们是否仍然在线运行。如果某个Redis服务器实例在规定时间内没有响应哨兵的PING命令，哨兵就会将其标记为“主观下线”。
2. 客观下线：当多个哨兵节点都将同一个Redis服务器实例标记为“主观下线”时，该实例会被标记为“客观下线”，即确认该实例已经故障。
3. 自动故障转移：一旦主节点被标记为“客观下线”，哨兵集群就会开始自动故障转移流程。首先，哨兵集群会通过投票选举出哨兵中的matser，由他做下面的操作，然后，哨兵集群会从从节点中选择一个作为新的主节点（选主过程涉及多个规则，如从库优先级、复制进度等）。然后，哨兵会更新所有从节点和新主节点的配置，让它们开始复制新的主节点。最后，哨兵会通知客户端新的主节点地址，以便客户端可以重新连接到Redis服务。
4. 通知：在整个故障转移过程中，哨兵节点会通过API向管理员或其他应用程序发送通知，以便及时了解Redis服务的状态变化。

选举master的规则

• 首先会判断slave节点与matser节点断开时间的长短，如果超过指定值(down-after-milliseconds*10)则会排除该slave节点，因为此时该从节点与原主节点的数据严重不匹配
• 再判断slave节点的slave-priority值，越小优先级越高，如果时0则永远不参加选举
• 如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
• 最后判断slave节点的运行id大小，越小优先级越高

实现故障转移

当选举了其中一个slave为新的matser后，会有一下三部

• sentinel给备选的slave节点发送slaveof no one命令，让该节点成为matser
• sentinel给所有其它slave发送slaveof 备选节点的ip 命令，让这些slave成为新matser的从节点，开始从新的matser上同步数据
• 最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的matser的slave节点

哨兵集群的优势

• 高可用性：哨兵集群可以自动处理Redis主节点的故障，确保Redis服务的高可用性。
• 自动故障转移：无需人工干预，哨兵集群可以自动完成故障转移流程，减少服务中断时间。
• 灵活配置：哨兵集群支持多种配置选项，可以根据实际需求进行灵活配置。

注意事项

• 节点数量：为了确保哨兵集群的可靠性和稳定性，建议部署奇数个哨兵节点（如3个、5个等），以满足多数投票机制的需求。
• 网络分区：在部署哨兵集群时，需要考虑网络分区的问题。为了避免因网络分区导致的误判和故障转移，建议将哨兵节点分布在不同的网络区域中。
• 监控和日志：定期监控哨兵集群的运行状态和日志信息，以便及时发现和解决问题。

Redis分片集群

以上的集群以经解决了Redis的持久化，高并发能力，故障转移，但由于主节点只有一个，而仅有主节点可以存储数据，所以我们接下来将搭建分片集群，横向扩展主节点，以提高redis的存储能力，在分片集群中有多个主节点，每个主节点都可以存储数据，每个主节点下也会有多个从节点，主节点间通过ping检测彼此健康状态，彼此承担哨兵的的职责，由于主节点间不会做数据的拷贝同步，所以主节点间的数据是不同的，但客户端访问任意节点，最终都会通过心跳转发到正确节点

工作原理

1. 数据分配：在Redis分片集群中，数据被分为多个片段，每个片段存储在不同的节点上。这些节点可以是物理服务器或虚拟服务器。
2. 请求处理：
   • 客户端发送命令到Redis分片集群中的任意一个节点。
   • 节点根据命令涉及的键的哈希值计算出对应的槽号。
   • 节点根据槽号确定该槽所在的节点，节点之间会通过心跳机制进行重定向，并将命令路由到该节点。
   • 目标节点处理命令并返回结果给客户端。
3. 数据同步与故障恢复：
   • 主节点与从节点之间通过异步复制进行数据同步。
   • 当主节点发生故障时，集群会自动进行故障转移，选举一个从节点作为新的主节点，以保证系统的可用性。

优势与特点

1. 高可用性：通过数据冗余和自动故障转移机制，即使某个节点发生故障，集群仍然可以对外提供服务。
2. 高性能：通过将数据分散到多个节点上，可以实现并行处理，从而提高读写吞吐量和响应速度。
3. 可伸缩性：集群的节点数量可以根据需要进行动态调整，以适应不同的负载和存储需求。
4. 负载均衡：通过智能路由算法将请求分配到不同的节点上，以实现负载均衡，提高系统整体性能。

缓存击穿问题详细介绍

缓存击穿是指在高并发场景下，一个或多个请求查询一个不存在的缓存数据（通常是热点数据）可能是由于该缓存数据已过期，由于缓存中没有该数据，导致这些请求直接穿透到数据库，造成数据库的压力过大，进而导致系统性能下降的问题。

缓存击穿的主要原因包括：

1. 缓存失效：缓存中的数据由于过期或被主动删除，导致大量请求无法从缓存中获取数据，从而直接访问数据库。
2. 并发请求：在高并发场景下，多个进程或线程同时查询一个不存在的缓存数据，导致多个请求同时访问数据库。

缓存击穿可能带来的问题包括：

1. 数据库压力增大：大量请求直接访问数据库，导致数据库负载增大，性能下降，甚至可能发生宕机。
2. 响应时间增加：由于直接访问数据库需要花费更多的时间，因此缓存击穿会导致响应时间增加，降低用户体验。

解决方案

热点数据永不过期

• 方法描述：对于频繁访问且重要的热点数据，可以设置其永不过期。同时，通过异步线程定期刷新缓存中的数据，以保持数据的实时性。
• 优势：可以避免因缓存过期而导致的缓存击穿问题，提高系统的稳定性和性能。
• 注意事项：需要确保定期刷新缓存的线程能够稳定运行，并且及时更新缓存中的数据以保持数据的准确性。

互斥锁

• 方法描述：使用分布式锁或缓存锁机制，保证只有一个请求能够从数据库中加载数据，其他请求等待并使用锁中的数据。当缓存未命中时，请求会尝试获取锁，获取到锁的请求会查询数据库并更新缓存，未获取到锁的请求则等待一段时间后重试。
• 实现方式：可以通过Redis的SETNX命令或其他分布式锁实现方式来实现。
• 优势：可以有效减少数据库的并发访问压力，避免缓存击穿。
• 注意事项：需要合理设置锁的等待时间和重试次数，以避免死锁或过度占用系统资源。

缓存雪崩

缓存雪崩问题介绍

缓存雪崩是指在高并发情况下，由于大量的缓存数据同时过期或缓存服务宕机，导致大量请求直接穿透到数据库，造成数据库压力过大，甚至引发系统崩溃的现象。缓存雪崩影响范围广泛，影响大于缓存击穿，严重时会导致服务不可用

缓存雪崩通常是由于以下原因导致的：

1. 缓存集体过期：大量缓存数据被设置为同一时间过期，当这些缓存数据同时失效时，大量请求会涌入数据库。
2. Redis服务宕机：Redis作为缓存服务，其稳定性直接影响到整个系统的性能。一旦Redis服务宕机，所有缓存数据将无法访问，所有请求都将直接打到数据库上。
3. 大量突发请求：在某些情况下，如秒杀活动、热门事件等，可能会在短时间内产生大量的请求，这些请求如果都未能在缓存中找到数据，就会直接冲击数据库。

缓存雪崩的影响是灾难性的，它不仅会导致数据库负载过高、响应时间延长，甚至可能引发服务挂掉，影响整个系统的正常运行。

解决方案

差异化设置过期时间

• 策略描述：在设置缓存时，避免将大量数据的过期时间设置为同一时刻。可以通过给每个键的过期时间加上一个随机偏移量，使得数据的过期时间分散开来。
• 实施方式：在代码层面调整缓存的过期时间设置逻辑，确保不同数据的过期时间有所差异。
• 效果：减少缓存同时失效的概率，分散数据库压力。

自定义RedisCacheManager对有效期时间进行随机设置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

/**
 * 自定义CacheManager，用于设置不同的过期时间，防止雪崩问题的发生
 */
public class MyRedisCacheManager extends RedisCacheManager {
    public MyRedisCacheManager(RedisCacheWriter cacheWriter, RedisCacheConfiguration defaultCacheConfiguration) {
        super(cacheWriter, defaultCacheConfiguration);
    }
    @Override
    protected RedisCache createRedisCache(String name, RedisCacheConfiguration cacheConfig) {
        //获取到原有过期时间
        Duration duration = cacheConfig.getTtl();
        if (ObjectUtil.isNotEmpty(duration)) {
            //在原有时间上随机增加1~10分钟
            Duration newDuration = duration.plusMinutes(RandomUtil.randomInt(1, 11));
            cacheConfig = cacheConfig.entryTtl(newDuration);
        }
        return super.createRedisCache(name, cacheConfig);
    }
}

使用MyRedisCacheManager

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

@Bean
    public RedisCacheManager redisCacheManager(RedisTemplate redisTemplate) {
        // 默认配置
        RedisCacheConfiguration defaultCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig()
                // 设置key的序列化方式为字符串
                .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()))
                // 设置value的序列化方式为json格式
                .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()))
                .disableCachingNullValues() // 不缓存null
                .entryTtl(Duration.ofHours(redisTtl));  // 默认缓存数据保存1小时
        // 构redis缓存管理器
        // RedisCacheManager redisCacheManager = RedisCacheManager.RedisCacheManagerBuilder
        //         .fromConnectionFactory(redisTemplate.getConnectionFactory())
        //         .cacheDefaults(defaultCacheConfiguration)
        //         .transactionAware()
        //         .build();
        //使用自定义缓存管理器
        RedisCacheWriter redisCacheWriter = RedisCacheWriter.nonLockingRedisCacheWriter(redisTemplate.getConnectionFactory());
        MyRedisCacheManager myRedisCacheManager = new MyRedisCacheManager(redisCacheWriter, defaultCacheConfiguration);
        myRedisCacheManager.setTransactionAware(true); // 只在事务成功提交后才会进行缓存的put/evict操作
        return myRedisCacheManager;
    }

服务降级

• 策略描述：在缓存失效或数据库压力过大的情况下，通过服务降级策略来减少对非核心业务的请求处理，确保核心业务的正常运行。
• 实施方式：使用限流组件（如Hystrix、Sentinel等）来限制请求量，或返回默认数据或静态页面等。
• 效果：保护系统不受极端情况的冲击，确保核心业务的服务质量。

使用Redis集群或哨兵模式

• 策略描述：通过部署Redis集群或哨兵模式来提高缓存服务的可用性。当单个Redis节点故障时，可以自动切换到其他节点继续提供服务。
• 实施方式：配置Redis集群或哨兵模式，监控Redis节点的状态，并实现故障自动转移。
• 效果：提高缓存服务的稳定性和可靠性，降低缓存雪崩的风险。

缓存穿透

缓存穿透问题介绍

缓存穿透是指用户查询一个数据库和缓存中都不存在的数据，导致每次查询都会直接打到数据库上，而数据库中也没有该数据，如果用户不断发起这样的请求，数据库压力会非常大，甚至可能拖垮数据库。这种情况通常是由于恶意的查询或者系统设计不当导致的。

危害

缓存穿透的主要危害在于，如果存在大量针对不存在的数据的查询请求，这些请求都会绕过缓存直接访问数据库，导致数据库压力剧增，影响系统性能，甚至可能引发数据库崩溃。

解决方案

针对缓存穿透问题，常见的解决方案有以下几种：

布隆过滤器（Bloom Filter）

• 原理：布隆过滤器是一种空间效率很高的概率型数据结构，用于判断一个元素是否在一个集合中。它通过使用位数组和多个哈希函数来减少误判率，但无法完全避免误判。

• 应用：在查询数据库之前，先通过布隆过滤器判断该数据是否可能存在。如果布隆过滤器判断该数据不存在，则直接返回空值或错误信息，避免对数据库的访问。

• 优缺点：

  • 优点：内存占用少，查询速度快。
  • 缺点：存在误判率，且实现相对复杂。

  实现

  关于布隆过滤器的使用，建议使用Google的Guava 或 Redission基于Redis实现，前者是在单体架构下比较适合，后者更适合在分布式场景下，便于多个服务节点之间共享。

  Redission基于Redis，使用string类型数据，生成二进制数组进行存储，最大可用长度为：4294967294。

  • 引入依赖

    1 2 3 4

    <dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> </dependency>

  • 导入redisson配置、

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

    @Configuration public class RedissonConfiguration { @Resource private RedisProperties redisProperties; @Bean public RedissonClient redissonSingle() { Config config = new Config(); SingleServerConfig serverConfig = config.useSingleServer() .setAddress("redis://" + redisProperties.getHost() + ":" + redisProperties.getPort()); if (null != (redisProperties.getTimeout())) { serverConfig.setTimeout(1000 * Convert.toInt(redisProperties.getTimeout().getSeconds())); } if (StrUtil.isNotEmpty(redisProperties.getPassword())) { serverConfig.setPassword(redisProperties.getPassword()); } return Redisson.create(config); } }

  • 自定义布隆过滤器配置

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

    /** * 布隆过滤器相关配置 */ @Getter @Configuration public class BloomFilterConfig { /** * 名称，默认：sl-bloom-filter */ @Value("${bloom.name:sl-bloom-filter}") private String name; /** * 布隆过滤器长度，最大支持Integer.MAX_VALUE*2，即：4294967294，默认：1千万 */ @Value("${bloom.expectedInsertions:10000000}") private long expectedInsertions; /** * 误判率，默认：0.05 */ @Value("${bloom.falseProbability:0.05d}") private double falseProbability;

  • 定义布隆过滤器接口

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

    /** * 布隆过滤器服务 */ public interface BloomFilterService { /** * 初始化布隆过滤器 */ void init(); /** * 向布隆过滤器中添加数据 * * @param obj 待添加的数据 * @return 是否成功 */ boolean add(Object obj); /** * 判断数据是否存在 * * @param obj 数据 * @return 是否存在 */ boolean contains(Object obj); }

  • 编写实现类

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

    @Service public class BloomFilterServiceImpl implements BloomFilterService { @Resource private RedissonClient redissonClient; @Resource private BloomFilterConfig bloomFilterConfig; private RBloomFilter<Object> getBloomFilter() { return this.redissonClient.getBloomFilter(this.bloomFilterConfig.getName()); } @Override @PostConstruct // spring启动后进行初始化 public void init() { RBloomFilter<Object> bloomFilter = this.getBloomFilter(); bloomFilter.tryInit(this.bloomFilterConfig.getExpectedInsertions(), this.bloomFilterConfig.getFalseProbability()); } @Override public boolean add(Object obj) { return this.getBloomFilter().add(obj); } @Override public boolean contains(Object obj) { return this.getBloomFilter().contains(obj); } }

    后续在Controller直接使用布隆过滤器的contains可以直接判断该数据是否存在，从而实现过滤，在新增数据后，也需要使用add方法将数据添加到布隆过滤器，以便后面可以判断。

    局限

    由于布隆过滤器是采用hash算法将key值计算为一个数字存在bitMap中，所有有可能存在两个不同的键计算出的值相同有可能会造成误差，可以通过一个键使用多个hash算法，如果多个hash算法的结果均存在才说明该数据存在，即使这样，也会存在误差

缓存空对象

• 原理：当查询一个不存在的数据时，将空结果（如null或特定空值）缓存起来，并设置一个较短的过期时间。这样，在后续的查询中，如果仍然查询该不存在的数据，则可以直接从缓存中返回空结果，避免对数据库的访问。
• 应用：适用于数据变动不频繁的场景，可以减少对数据库的无效查询。
• 优缺点：
  • 优点：实现简单，维护方便。
  • 缺点：可能会浪费一定的缓存空间，且存在短期数据不一致的风险。

控制层校验

• 原理：在业务系统的控制层（如API接口）增加校验逻辑，对查询参数进行合法性校验。如果查询参数不合法（如查询不存在的数据ID），则直接返回错误信息，避免对缓存和数据库的访问。
• 应用：适用于可以通过校验规则提前判断查询是否有效的场景。
• 优缺点：
  • 优点：能够有效减少无效查询对系统的压力。
  • 缺点：需要维护校验规则，且可能无法覆盖所有无效查询。

Caffeine是一个基于Java8开发的提供了近乎最佳命中率的高性能缓存库，它源自Google Guava的Cache设计，但提供了更多的优化和特性。以下是对Caffeine的详细解析：

Caffeine的特点

1. 高性能：Caffeine通过优化的算法和设计，实现了接近最优的缓存性能。它支持高效的并发访问，能够在大规模数据和高并发访问的场景下保持良好的性能。
2. 灵活性：Caffeine提供了多种配置选项，允许开发者根据具体需求定制缓存行为。这包括缓存大小限制、过期时间、自动加载策略等。
3. 智能淘汰策略：Caffeine采用了基于TinyLFU（Least Frequently Used）的新型淘汰算法，该算法在保持高命中率的同时有效控制缓存大小。这意味着Caffeine能够自动移除“不常用”的数据，以保持内存的合理占用。
4. 易于集成：Caffeine提供了简单易用的API，并且与Guava的Cache有良好的兼容性，支持JSR-107（JCache）规范，可以与其他Java框架无缝融合。
5. 统计和监控：Caffeine还提供了缓存的统计信息，帮助开发者进行性能监控和调优。

Caffeine的基本用法

1. 构建缓存：
   使用Caffeine.newBuilder()方法构建缓存配置，并通过链式调用设置缓存的各项参数，如过期时间、最大容量等。最后，调用build()方法创建缓存实例。

   1 2 3 4

   Cache<Key, Graph> cache = Caffeine.newBuilder() .expireAfterWrite(10, TimeUnit.MINUTES) .maximumSize(10_000) .build();

2. 缓存操作：

   • 添加或更新缓存：使用cache.put(key, value)方法添加或更新缓存元素。
   • 获取缓存元素：
     • cache.getIfPresent(key)：如果缓存中存在该key对应的元素，则返回该元素；否则返回null。
     • cache.get(key, k -> value)：如果缓存中不存在该key对应的元素，则调用给定的函数生成该元素，并将其加入缓存后返回。
   • 移除缓存元素：使用cache.invalidate(key)方法移除缓存中指定key的元素。

3. 自动加载缓存：

   • LoadingCache：当调用get()方法且缓存不存在时，自动调用CacheLoader的load()方法加载缓存元素。
   • AsyncLoadingCache：支持异步加载缓存元素，返回CompletableFuture对象。

Caffeine的缓存策略

基于大小的驱逐策略

定义：
当缓存中的条目数量达到预设的最大阈值时，自动从缓存中移除一部分数据以维持缓存大小不超过限制。

优点：

• 直接控制缓存占用空间：可以确保缓存不会无限制地增长，避免占用过多的系统资源。
• 简单易懂：配置和理解起来相对简单，不需要复杂的算法支持。

缺点：

• 可能移除常用数据：如果缓存大小限制设置得太小，可能会导致一些频繁访问的数据被错误地移除。
• 不够智能：无法根据数据的访问频率或重要性来智能地选择移除对象。

基于时间的驱逐策略

定义：
包括两种主要类型：基于写入时间的驱逐（expireAfterWrite）和基于访问时间的驱逐（expireAfterAccess）。前者是指数据在写入后经过一定时间未被访问则被淘汰，后者是指数据在最后一次访问后经过一定时间未被再次访问则被淘汰。

优点：

• 自动过期处理：能够自动清理过期数据，保持缓存数据的时效性。
• 适用于特定场景：如需要定期更新数据的场景，可以确保缓存中的数据不会过时。

缺点：

• 可能导致数据频繁过期：如果过期时间设置得太短，可能会导致大量数据频繁过期，增加缓存的维护成本。
• 不适用于所有场景：有些场景下数据的有效期可能很难确定，或者需要长期保留。

基于频率的驱逐策略（W-TinyLFU）

定义：
W-TinyLFU是Caffeine默认采用的驱逐算法，它是对传统LFU（Least Frequently Used）算法的优化。该算法通过维护一个频率表来记录每个数据的访问频率，并根据频率来决定数据的淘汰优先级。

优点：

• 高命中率：能够有效保护频繁访问的数据，提高缓存的命中率。
• 优化空间占用：使用Count-Min Sketch算法存储访问频率，极大地节省了空间。
• 应对访问模式变化：通过定期衰减操作和Window机制来应对访问模式的变化，减少缓存污染。

缺点：

• 算法复杂度较高：相比于简单的基于大小或时间的驱逐策略，W-TinyLFU算法的实现更为复杂。
• 需要额外空间：虽然优化了空间占用，但仍然需要额外的空间来存储访问频率信息。

基于引用的缓存策略

这里的“基于引用的缓存策略”并非Caffeine直接提供的一种独立策略，而是可以通过其提供的缓存配置和特性来间接实现的一种管理方式。

在Java中，引用（Reference）主要分为强引用（Strong Reference）、软引用（Soft Reference）和弱引用（Weak Reference）三种。这些引用类型在JVM的垃圾回收过程中扮演着不同的角色，从而影响缓存中对象的生命周期。

• 强引用：最常见的引用类型，只要强引用还存在，垃圾回收器就永远不会回收被引用的对象。
• 软引用：非必须对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。
• 弱引用：也是非必须对象，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。

虽然Caffeine没有直接提供设置引用类型的API，但你可以通过结合Java的引用类型和Caffeine的缓存过期策略、容量限制等特性来实现基于引用的缓存管理。例如，你可以使用软引用或弱引用来包装缓存中的对象，然后在JVM进行垃圾回收时，根据引用类型的不同，缓存中的对象可能会被自动清理。

然而，需要注意的是，这种方法可能会使得缓存的管理变得复杂和不可控，因为缓存的清理将依赖于JVM的垃圾回收机制，而这是不可预测的。因此，在实际应用中，更常见的是直接使用Caffeine提供的基于时间、大小或权重的驱逐策略来管理缓存。

此外，Caffeine还提供了丰富的API和配置选项，允许你根据实际需求定制缓存的行为，包括缓存的加载、写入、刷新、过期、淘汰等各个方面。这使得Caffeine成为了一个非常灵活和强大的缓存解决方案。

应用场景

Caffeine适用于各种需要高效缓存解决方案的场景，包括但不限于：

• Web应用：在高流量的web服务中缓存经常访问的数据以减少数据库压力。
• 大数据处理：在分布式数据存储系统中作为本地缓存层来加速读取操作。
• 流式处理平台：在处理大量事件时缓存中间结果以提高吞吐量。
• 搜索引擎：用于快速响应查询。
• 微服务框架：为微服务提供内置缓存支持。

缓存一致性问题

由于Caffeine的缓存数据存储在JVM的堆内存中，这意味着他只能在其所在的JVM实例访问，而在分布式系统中，往往一个微服务会启动多个节点(JVM实例)来访问共同的资源，此时若其中一个节点修改了数据，但此时其他节点并未修改数据，就会导致缓存一致性问题

解决方案

可以使用redis的分布式缓存解决该问题，Redis分布式缓存中的发布订阅（Pub/Sub）机制是一种强大的通信模式，它允许发送者（发布者）将消息发送给订阅了特定频道的接收者（订阅者），而不需要知道订阅者的具体信息。这种机制在解决缓存不一致问题时具有显著的作用。

工作原理

Redis的发布订阅机制主要包括发布者（Publisher）、订阅者（Subscriber）和频道（Channel）三个部分。发布者将消息发送到指定的频道，所有订阅了该频道的订阅者都能接收到这条消息。这种机制与Redis的键值对存储机制是独立的，它不会影响Redis中的数据结构。

具体方式

当某个节点的应用更新了数据库中的数据，并希望同步更新到Redis缓存中时，该节点可以作为一个发布者，将缓存更新消息（如缓存键名、更新时间等）发送到特定的频道上。其他节点作为订阅者，订阅了这个频道后，就能实时接收到这个缓存更新消息。

简介

基本概述

• 类型：MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。
• 数据存储：MongoDB使用BSON（Binary JSON）格式存储数据，这种格式支持存储复杂的数据类型，类似于JSON对象，但具有更高的存储效率和性能。
• 数据模型：MongoDB采用文档导向的数据模型，文档是一个键值对的集合，类似于关系型数据库中的行，但更为灵活。文档可以包含嵌入式文档、数组和其他复杂类型。

主要特点

1. 高性能：MongoDB使用内存映射文件和预分配空间等技术优化数据读写性能，支持快速的插入、更新和查询操作。
2. 可扩展性：MongoDB支持水平扩展和自动分片，可以方便地增加服务器和处理大规模数据。
3. 模式自由：MongoDB不需要事先定义表格结构，可以存储各种类型的数据，支持嵌入式文档和引用两种数据关联方式。
4. 强大的查询语言：MongoDB提供丰富的查询操作符和聚合管道功能，支持复杂的查询和分析需求。
5. 高可用性：MongoDB通过复制集（Replica Set）提供数据的冗余和故障恢复能力，主从复制可以提高系统的可用性和容错性。

应用场景

• 网站实时数据处理：MongoDB非常适合实时的插入、更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
• 缓存：由于性能很高，MongoDB适合作为信息基础设施的缓存层，在系统重启之后，由它搭建的持久化缓存层可以避免下层的数据源过载。
• 高伸缩性的场景：MongoDB非常适合由数十或数百台服务器组成的数据库，其路线图中已经包含对MapReduce引擎的内置支持。

概念对比

优势对比

MongoDB与MySQL作为两种不同类型的数据库系统，各自具有独特的优势和适用场景。MongoDB作为一种非关系型数据库（NoSQL），与关系型数据库MySQL相比，在以下几个方面展现出明显的优势：

1. 数据模型灵活性

• MongoDB：使用文档型存储模型，类似于JSON格式，每个文档可以有不同的字段，支持嵌套结构和动态模式。这种灵活性使得MongoDB非常适合处理半结构化和非结构化数据，能够轻松应对数据结构的变化。
• MySQL：遵循关系模型，数据以表格的形式存储，有固定的列和行结构。虽然通过外键可以实现数据间的关联，但数据结构的变更相对复杂。

2. 高性能和扩展性

• MongoDB：支持水平扩展，内置分片机制，可以轻松地通过增加服务器来扩展存储和处理能力，实现近乎线性的性能提升。同时，MongoDB的内存映射文件技术和高效的查询语言使得数据读写速度快，特别适合处理海量数据和高并发场景。
• MySQL：虽然也支持一定程度的扩展，但在处理海量数据时，若未进行合理的索引优化或分区分片，可能会出现性能下降。

3. 查询能力

• MongoDB：提供了丰富的查询语言，包括文本搜索、地理位置搜索等功能，可以灵活地满足各种查询需求。其聚合框架还提供了强大的数据汇总和分析功能。
• MySQL：使用标准的SQL语言，提供了丰富的查询功能和高级特性，如复杂的JOIN操作、子查询等。但在处理非结构化或半结构化数据时，可能不如MongoDB灵活。

4. 高可用性和可靠性

• MongoDB：具有内置的复制和故障转移功能，可以保证数据的高可用性和可靠性。同时，MongoDB还提供了透明数据加密、自动备份、数据恢复等功能，进一步增强了其优势。
• MySQL：同样具有高可靠性和稳定性，能够在处理高负载的情况下保持高性能。但相比MongoDB，其高可用性和数据保护机制可能需要额外的配置和管理。

5. 工具和生态系统

• MongoDB：拥有丰富的工具和驱动程序，支持各种编程语言和开发环境，可以方便地集成到现有的应用程序中。同时，MongoDB还提供了专业的数据管理服务（如MongoDB Atlas）和数据传输服务（如DTS），支持管理多种数据库和数据源之间的数据交互。
• MySQL：拥有庞大的社区支持和广泛的工具生态系统，包括图形界面工具、备份和恢复工具、监控工具等。这些工具和资源为MySQL的广泛应用提供了有力支持。

总结

MongoDB相较于MySQL的优势主要体现在数据模型灵活性、高性能和扩展性、查询能力、高可用性和可靠性以及工具和生态系统等方面。然而，选择哪种数据库系统应根据具体的应用场景、数据特性和业务需求来决定。如果数据结构复杂多变、需要高并发读写、对扩展性要求高或对半结构化数据处理有需求，MongoDB可能更为合适；而如果业务场景高度依赖ACID事务、数据结构固定、需要进行复杂的SQL查询和数据分析或对存储空间有严格要求，MySQL可能是更好的选择。

MongoDB语法

库操作

• 查看所有数据库：

  1

  show dbs

• 创建数据库：
  在 MongoDB 中，创建数据库很简单，只需要使用 use 命令，如果数据库不存在，MongoDB 会在需要时自动创建它。

  1	use myDatabase

• 删除数据库：

  1	db.dropDatabase()

集合操作

• 查看当前数据库中的集合：

  1	show collections

• 创建集合：
  在 MongoDB 中，创建集合也是隐式的，当你第一次插入文档时，如果集合不存在，MongoDB 会自动创建它。

  1	db.createCollection("myCollection")

• 删除集合：

  1	db.myCollection.drop()

文档操作

• 插入文档：

  1	db.myCollection.insert({name: "John", age: 30})

  或者插入多个文档：

  1	db.myCollection.insert([{name: "Jane", age: 25}, {name: "Doe", age: 22}])

• 查询文档：

  查询模板

  1	db.mycollection.find([query],[fields])

  • query：可选，使用查询操作符指定查询条件，可理解为sql中where后面的内容
  • fields：可选，使用投影操作指定返回的键，可理解为sql中select后的字段

  1 2	db.myCollection.find({}) # 查询所有文档 db.myCollection.find({name: "John"}) # 查询特定条件的文档

• 更新文档：

  更新模板

  1 2 3 4 5 6 7 8 9

  db.myCollection.update( <query>, <update>, [ upsert: <boolean>, multi: <bollean>, writeConcern: <document> ] )

  • query：update的查询条件，类似sql update查询内where后面的
  • update：update的对象和一些更新的操作符，可理解为sql中update后面set的内容
  • upsert：可选，这个参数的意思是，如果不存在update的记录，是否以一个新的对象插入，默认是false
  • multi：可选，默认是false，只更新找到的第一条记录，如果这个条件是true，就把按条件查出来的多条记录更新
  • writeConcern：可选，抛出异常的级别

  1 2 3 4

  db.myCollection.update( { name: "John" }, { $set: { age: 31 } } )

  或者更新多个文档：

  1 2 3 4

  db.myCollection.update( { }, { $set: { newField: "value" } } )

• 删除文档：

  删除模板

  1 2 3 4 5 6 7

  db.mycollection.remove( <query>, { justOne: <boolean>, writeConcern: <document> } )

  • query：可选，删除文档的条件
  • justOne：可选，如果设为true或1，则只删除一个文档，如果不设置该参数，则使用默认值false，则删除所有匹配的文档
  • writeConcern：可选，抛出异常的级别

  1 2	db.myCollection.remove({name: "John"}) db.myCollection.remove({age: {$lt: 25}})

索引

• 创建索引：

  1	db.myCollection.createIndex({name: 1})

• 查看索引：

  1	db.myCollection.getIndexes()

• 删除索引：

  1	db.myCollection.dropIndex({name: 1})

SpringDataMongoDB

1. 添加依赖

首先，需要在项目的构建文件（如Maven的pom.xml或Gradle的build.gradle）中添加Spring Data MongoDB的依赖项。以Maven为例，可以添加如下依赖：

1
2
3
4

<dependency>  
    <groupId>org.springframework.boot</groupId>  
    <artifactId>spring-boot-starter-data-mongodb</artifactId>  
</dependency>

这个依赖包含了Spring Data MongoDB的核心功能，以及MongoDB Java驱动的依赖。

2. 配置MongoDB

接下来，在Spring Boot的配置文件（如application.properties或application.yml）中配置MongoDB的连接参数。以下是一个application.yml配置示例：

1
2
3
4
5
6
7
8
9
10
11

spring:  
  data:  
    mongodb:  
      uri: mongodb://username:password@localhost:27017/mydatabase  
      # 或者分开配置  
      # host: localhost  
      # port: 27017  
      # database: mydatabase  
      # username: username  
      # password: password  
      # authenticationDatabase: admin # 如果需要认证的话

这里配置了MongoDB的URI，或者分开配置了主机名、端口号、数据库名称、用户名和密码等信息。

3. 创建实体类

使用MongoDB的注解来定义实体类，并将其映射到MongoDB的集合（collection）。常用的注解包括@Document、@Field和@Id等。以下是一个简单的实体类示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import org.springframework.data.annotation.Id;  
import org.springframework.data.mongodb.core.mapping.Document;  
  
@Document(collection = "users")  
public class User {  
    @Id  
    private String id;  
      
    @Field("name")  
    private String name;  
      
    @Field("age")  
    private Integer age;  
      
    // 省略getter和setter方法  
}

4. 创建Repository接口

创建一个继承自MongoRepository（或其他Spring Data MongoDB提供的Repository接口）的接口，用于访问和操作实体类对应的MongoDB数据。Spring Data MongoDB会为这个接口提供一套基本的CRUD方法。

1
2
3
4
5

import org.springframework.data.mongodb.repository.MongoRepository;  
  
public interface UserRepository extends MongoRepository<User, String> {  
    // 可根据需要添加自定义查询方法  
}

5. 使用Repository进行操作

在需要使用MongoDB操作的地方，通过注入Repository接口对象来调用相应的方法。例如，在Service层中使用Repository来保存和查询数据。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

import org.springframework.beans.factory.annotation.Autowired;  
import org.springframework.stereotype.Service;  
  
@Service  
public class UserService {  
      
    @Autowired  
    private UserRepository userRepository;  
      
    public User saveUser(User user) {  
        return userRepository.save(user);  
    }  
      
    public User getUserById(String id) {  
        return userRepository.findById(id).orElse(null);  
    }  
      
    // 省略其他方法  
}

6. 使用MongoTemplate

除了使用Repository接口外，Spring Data MongoDB还提供了MongoTemplate类，它提供了更灵活的数据访问能力。可以在需要的时候注入MongoTemplate来实现更复杂的查询和操作。

增加（Insert）

使用 MongoTemplate 的 insert 方法可以将对象插入到 MongoDB 的集合中。如果对象包含了一个 _id 字段，并且该字段的值已经存在于集合中，那么该操作会抛出一个异常。如果不希望自动生成 _id，可以在实体类中设置 @Id 注解的 autoGenerated 属性为 false（注意：通常我们让 MongoDB 自动管理 _id）。

1
2
3

public void insertUser(User user) {  
    mongoTemplate.insert(user, "users");  
}

这里 "users" 是 MongoDB 中的集合名称。

删除（Delete）

删除操作可以通过 remove 方法或 findAllAndRemove 方法来完成。remove 方法可以根据查询条件删除一个或多个文档。

1
2
3
4
5
6
7
8
9
10
11

// 根据ID删除  
public void deleteUserById(String id) {  
    Query query = new Query();  
    query.addCriteria(Criteria.where("id").is(id));  
    mongoTemplate.remove(query, User.class, "users");  
}  
  
// 删除所有  
public void deleteAllUsers() {  
    mongoTemplate.removeAll(User.class, "users");  
}

更新（Update）

更新操作通常使用 updateFirst 或 updateMulti 方法。updateFirst 会更新查询到的第一个文档，而 updateMulti 会更新所有匹配的文档。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 更新第一个匹配的文档  
public void updateUserFirstName(String id, String firstName) {  
    Query query = new Query();  
    query.addCriteria(Criteria.where("id").is(id));  
    Update update = new Update();  
    update.set("firstName", firstName);  
    mongoTemplate.updateFirst(query, update, User.class, "users");  
}  
  
// 更新所有匹配的文档  
public void updateAllUsersAge(int newAge) {  
    Query query = new Query();  
    // 这里可以添加更具体的查询条件  
    Update update = new Update();  
    update.set("age", newAge);  
    mongoTemplate.updateMulti(query, update, User.class, "users");  
}

查询（Query）

查询操作非常灵活，MongoTemplate 提供了多种查询方法，如 findOne、findAll、find 等，它们可以接受 Query 对象作为参数来定义查询条件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// 根据ID查询单个文档  
public User findUserById(String id) {  
    return mongoTemplate.findById(id, User.class, "users");  
}  
  
// 查询所有文档  
public List<User> findAllUsers() {  
    return mongoTemplate.findAll(User.class, "users");  
}  
  
// 使用Query对象进行复杂查询  
public List<User> findUsersByAge(int age) {  
    Query query = new Query();  
    query.addCriteria(Criteria.where("age").is(age));  
    return mongoTemplate.find(query, User.class, "users");  
}

在使用 MongoTemplate 进行查询时，你可以通过 Query 和 Criteria 类来构建复杂的查询条件，包括分页、排序等高级功能。

总的来说，MongoTemplate 提供了丰富的API来执行 MongoDB 的增删改查操作，使得开发者能够以更灵活和强大的方式来操作 MongoDB 数据库。

Neo4j是一个高性能的、基于Java的NoSQL图形数据库，它将结构化数据存储在网络（从数学角度称为图）上而不是传统的表中。Neo4j因其嵌入式、高性能、轻量级等优势，在数据存储、检索、分析和挖掘等方面有着广泛的应用。以下是对Neo4j的详细介绍

一、Neo4j的基本特性

1. 高性能的图引擎：Neo4j可以被看作是一个高性能的图引擎，具有成熟和健壮的数据库的所有特性。它支持大规模可扩展性，可以处理数十亿节点/关系/属性的图，并且可以扩展到多台机器并行运行。
2. 面向对象的网络结构：程序员在Neo4j中工作在一个面向对象的、灵活的网络结构下，而不是严格、静态的表中。这种结构使得Neo4j非常适合表示复杂、互连接、低结构化的数据。
3. 完全的事务特性：Neo4j是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎。它支持完整的ACID（原子性、一致性、隔离性和持久性）规则，确保数据的一致性和完整性。
4. CQL查询语言：Neo4j使用CQL（Cypher Query Language）作为查询语言，这是一种声明性模式匹配语言，其语法简单且人性化、可读性强。CQL遵循SQL语法，使得熟悉SQL的程序员可以快速上手。

二、Neo4j的优势

1. 性能优势：Neo4j对长程关系的查询速度快，能够迅速遍历节点与边，其遍历速度与构成图的数据量没有直接关系。此外，Neo4j还提供了非常快的图算法、推荐系统和OLAP风格的分析。
2. 数据表示优势：Neo4j很容易表示连接的数据和半结构化数据。检索、遍历和导航更多的连接数据是非常容易和快速的。它不需要复杂的连接来检索连接的/相关的数据，因为它可以很容易地检索相邻节点或关系细节。
3. 灵活性和可扩展性：Neo4j的图形数据模型非常灵活，可以轻松地适应不断变化的业务需求。同时，Neo4j支持大规模可扩展性，可以处理大规模的数据集。

三、Neo4j的应用场景

1. 社交媒体：Neo4j可以用于存储和检索社交媒体中的用户关系、帖子、评论等数据，支持复杂的社交网络分析。
2. 推荐系统：Neo4j可以根据用户的行为和偏好构建推荐系统，通过图分析发现用户之间的潜在联系和兴趣点。
3. 身份和访问管理：使用图形数据库进行身份和访问管理时，可以快速有效地跟踪用户、资产、关系和授权。
4. 金融风控：Neo4j可以用于金融领域的风控分析，通过图分析发现潜在的欺诈行为和洗钱网络。
5. 其他领域：Neo4j还可以应用于知识图谱、物流网络、生物信息学等多个领域。

结构

节点（Nodes）

• 定义：节点是图的基本单位，用于表达各种实体，如人、部门、物品等。每个节点都有唯一的ID，用于在图中唯一标识该节点。
• 功能：节点用于存储和表示现实世界中的实体或对象，以及这些实体或对象的属性。
• 示例：在社交网络中，节点可以代表用户；在推荐系统中，节点可以代表商品或用户。

关系（Relationships）

• 定义：关系是图形数据库中连接节点的边，用于表示节点之间的连接、关联或依赖关系。关系可以具有方向性，即从一个节点指向另一个节点。
• 功能：关系用于描述节点之间的相互作用或联系，是图数据库的核心组成部分。通过关系，可以轻松地遍历和查询图中的节点。
• 属性：关系也可以包含属性，这些属性用于存储关于关系本身的信息，如关系的类型、权重、时间戳等。
• 示例：在社交网络中，关系可以表示用户之间的好友关系、关注关系等；在推荐系统中，关系可以表示用户与商品之间的购买关系、浏览关系等。

属性（Properties）

• 定义：属性是用于描述图节点和关系的键值对。属性以键值对的形式存在，其中键是一个字符串，值可以是任何Neo4j支持的数据类型。
• 功能：属性用于存储节点或关系的详细信息，如节点的名称、年龄、性别等，或关系的类型、权重等。这些属性使得节点和关系更加丰富和具体。
• 示例：在社交网络中，用户节点的属性可以包括用户名、年龄、性别等；在推荐系统中，商品节点的属性可以包括商品名称、价格、描述等。

标签（Labels）

• 定义：标签是Neo4j中的一种元数据，用于对节点进行分类和组织。每个节点可以有一个或多个标签，这些标签用于标识节点的类型或属性。
• 功能：通过为节点添加标签，可以更好地组织和管理数据，提高查询性能。标签可以用作索引，加快查询速度。同时，标签也使得数据模型更加灵活和可扩展。
• 示例：在社交网络中，用户节点可以被打上“用户”或“VIP用户”等标签；在推荐系统中，商品节点可以被打上“电子产品”、“服装”等标签。

综上所述，节点、关系、属性和标签共同构成了Neo4j图形数据库的基本数据模型。通过这些元素，Neo4j能够高效地存储、检索和分析复杂的数据关系网络。

Cypher语句

Cypher是neo4j的查询语言，类似于关系型数据库中的SQL，一些关键词来源于SQL，比如:CREATE，WHERE，RETURN等，对关键词的大小写不敏感

匹配语句

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Match (n) return n
//查询所有的数据
MATCH (n:Person) RETURN n
//该语句返回所有带有person标签的节点
MATCH (n:Person {name: 'Alice'}) RETURN n
//返回所有具有Person标签且name属性为'Alice'的节点。
MATCH (a:Person)-[:FRIEND]->(b:Person) RETURN a, b
//返回所有具有FRIEND关系且两端都是Person节点的关系对。
MATCH (n:OLT {name: "北京市转运中心"}) -- (m) RETURN n,m
//查询所有与“北京市转运中心”有关系的节点
MATCH (n:OLT {name:"北京市转运中心"}) --> (m:OLT) RETURN n,m 
//查询所有"北京市转运中心"关联的一级转运中心
    
    
//分页查询网点，按照bid正序排序，每页查询2条数据，第一页
MATCH (n:AGENCY) 
RETURN n ORDER BY n.bid ASC SKIP 0 LIMIT 2

//第二页
MATCH (n:AGENCY) 
RETURN n ORDER BY n.bid ASC SKIP 2 LIMIT 2

创建语句

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

CREATE (n {name: $value}) RETURN n   //创建节点,该节点具备name属性，n为该节点的变量,创建完成后返回该节点
CREATE (n:$Tag {name: $value}) //创建节点，指定标签
CREATE (n)-[r:KNOWS]->(m)  //创建n指向m的关系，并且指定关系类型为：KNOWS
                 
//示例
CREATE (n {name:'迪士尼营业部'})
CREATE (n:AGENCY {name:'航头营业部'})
                   
//创建浦东新区转运中心、上海转运中心节点，并且创建关系为：IN_LINE，创建完成后返回节点和关系
//TLT -> Two Level Transport（二级转运中心）
//OLT -> One Level Transport（一级转运中心）
CREATE (n:TLT {name:'浦东新区转运中心'}) -[r:IN_LINE]-> (m:OLT {name:'上海转运中心'}) RETURN n,r,m

//关系也是可以反向，并且可以为关系中指定属性
CREATE (n:TLT {name:'浦东新区转运中心'}) <-[r:OUT_LINE]- (m:OLT {name:'上海转运中心'}) RETURN n,r,m

合并语句

合并语句是创建语句和匹配语句的结合体，先尝试找到给定模式匹配的节点和关系，如果不存在则创建他们

1
2

MERGE (a:Person {name: 'Alice'})-[:FRIEND]->(b:Person {name: 'Bob'})
//如果Alice和Bob之间的Friend关系不存在，则创建他们

设置语句

1
2

MATCH (n:Person {name: 'Alice'}) SET n.age = 31 RETURN n
//将Alice的Person节点的age属性更新为31

删除语句

1
2
3
4
5
6
7

MATCH (n:Person {name: 'Alice'}) DELETE n
//删除名为Alice的节点
MATCH (a:Person)-[r:FRIEND]->(b:Person) WHERE a.name = 'Alice' AND b.name = 'Bob' DELETE r
//删除Alice和Bob之间的Friend关系

//带有关系的节点不能删，可以先删关系或者强制删除节点和关系
Match (n:Agency {name:"北京市昌平区新龙城"}) Detach Delete n

SDN(Spring Data Neo4j)

1. 添加依赖

首先，你需要在你的 Spring Boot 项目的 pom.xml（如果是 Maven 项目）或 build.gradle（如果是 Gradle 项目）中添加 Spring Data Neo4j 的依赖。

Maven 示例

1
2
3
4
5
6
7
8

<dependencies>  
    <!-- Spring Boot Starter Data Neo4j -->  
    <dependency>  
        <groupId>org.springframework.boot</groupId>  
        <artifactId>spring-boot-starter-data-neo4j</artifactId>  
    </dependency>  
    <!-- 其他依赖 -->  
</dependencies>

2. 配置 Neo4j

在 application.properties 或 application.yml 文件中配置 Neo4j 数据库的连接信息。

1
2
3
4
5
6

spring:
   neo4j:
    authentication:
      username: username
      password: password
    uri: 链接uri

3. 定义图实体和仓库

使用 Spring Data Neo4j 的注解来定义你的图实体和仓库接口。

实体类示例

1
2
3
4
5
6
7
8
9
10
11

import org.neo4j.springframework.data.core.schema.Id;  
import org.neo4j.springframework.data.core.schema.Node;  
  
@Node  //里面是在neo4j中的标签
public class Person {  
    @Id  
    private Long id;  
    private String name;  
  
    // 构造函数、getter 和 setter 省略  
}

仓库接口示例

1
2
3
4
5
6
7
8
9
10
11
12
13

import org.neo4j.springframework.data.repository.Neo4jRepository;  
  
public interface PersonRepository extends Neo4jRepository<Person, Long> {  
  
    // 继承自Neo4jRepository的标准方法，如save、findAll等  
  
    // 自定义查询方法，通过方法命名约定  
    List<Person> findByName(String name);  
  
    // 使用@Query注解定义复杂的Cypher查询  
    @Query("MATCH (p:Person)-[:KNOWS]->(friend:Person) WHERE p.name = $name RETURN friend")  
    List<Person> findFriendsByName(String name);  
}

4. 使用仓库

在你的服务层或控制器中注入仓库，并使用它来执行数据库操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import org.springframework.beans.factory.annotation.Autowired;  
import org.springframework.stereotype.Service;  
  
@Service  
public class PersonService {  
  
    @Autowired  
    private PersonRepository personRepository;  
  
    public List<Person> findAllPersons() {  
        return personRepository.findAll();  
    }  
  
    // 其他业务逻辑  
}

正向索引

定义与结构

• 正向索引是从文档到单词的映射索引结构，它将文档中的每个单词与包含该单词的文档进行关联。这种索引结构适合于根据文档查找单词。
• 正向索引通常是以文档的ID为关键字，表中记录文档中每个单词的位置信息。

优点

• 结构简单：建立和维护相对简单。
• 易于维护：当有新文档加入或旧文档删除时，索引的更新相对容易。

局限性

由于其在对包含关键字的查询中需要逐行排查，所以此种查询效率极低，只适合与数据库系统等较为简单的查询作用，并不适合庞大的搜索引擎

倒排索引

定义与结构

• 倒排索引是一种索引方法，用于存储在全文搜索下某个单词在一个文档或一组文档中的存储位置的映射。它主要由“单词词典”和“倒排文件”两部分组成。单词词典记录了文档集合中出现过的所有单词，而倒排文件则包含了每个单词对应的倒排列表，即包含该单词的所有文档的列表及其相关信息（如文档编号、词频、位置等）。
• 倒排索引的设计是从单词到文档的映射，即它能够快速根据单词找到包含该单词的所有文档。

查询过程

将搜索语句分为一个一个词，去词条列表中查询文档id，根据id去查询文档存入结果集

优点

• 查询效率高：能够快速根据单词找到包含该单词的所有文档，适用于全文搜索和复杂查询。
• 相关性分析：可以基于词频、文档频率等信息进行相关性分析，提高检索结果的准确性。

局限性

• 存储需求大：对于大规模数据集，倒排索引可能需要大量的存储空间。
• 更新复杂：当文档集合发生变化时，倒排索引的更新相对复杂。

此种索引由于其复杂查询的高效性与准确性，所以可以用于搜索引擎

区别

IK分词器

作用

顾名思义，作用就是对一大段话进行分词，例如创建倒排索引时，对文档分词，用户搜索时，对输入的内容分词，由于其是通过遍历一个语句中的任意相邻组合结果与自己的词库中对比，从而达到的分词效果，所以对一些新词需要自己通过配置加入到词库中

分词算法

• ik_smart：ik_smart为最少切分，即做最粗粒度的拆分，已被分出的词语将不会再次被其它词语占有
• ik_max_word:ik_max_word为最细粒度划分，将文本做最细粒度的拆分，尽可能多的拆分出词语。

扩展词条

利用config目录中的IKAnalyzer.cfg.xml文件添加拓展词典，在词典中添加拓展词条

相关概念

Mapping映射属性

mapping是索引库中对文档的约束，常见的mapping属性包括：

type：字段数据类型，常见的简单类型有

• 字符串：text(可分词的文本，一般为较长的文本)，keyword（精确值，例如：品牌，国家，ip地址，一般不可分词，因为此种类型分此后便失去了本来的含义）
• 数值：long，integer，short，byte，double，float
• 布尔：boolean
• 日期：date
• 对象：object

index：是否创建索引，默认为true，为true即代表会为这个字段创建倒排索引，将来可以根据这个字段去做搜索排序

analyzer：使用哪种分词器

properties：该字段的子字段，例如在json格式中嵌套了另一个json格式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Put /heima
{
   "mapping":{
      "properties":{
         "info":{
            "type":"text",
            "analyzer":"ik_smart"
          },
 "age":{
   "type":"byte"
 },
 "email":{
   "type":"keyword",
   "index":false
 },
          "name":{
              "type":"object",
              "properties":{
                  "firstName":{
                      "type":"keyword"
                  },
                  "lastName":{
                      "type":"keyword"
                  }
              }
          }
      }
   }
}

文档CRUD

• 创建文档：POST/索引库名/_doc/文档id{Json文档}
• 查询文档：GET/索引库名/_doc/文档id
• 删除文档：DELETE/索引库名/_doc/文档id
• 修改文档：
  • 全量修改：PUT/索引库名/_doc/文档id{Json文档}全量修改的原理是删掉旧的文档，添加为这个文档，所以如果id值不存在的情况下，其作用等同于增加，注意：如果是修改，Json文档中的字段要写全
  • 增量修改：POST/索引库名/_update/文档id{"doc":{字段}}增量修改中，只需要写你需要修改的字段即可

批量处理

1
2
3
4
5
6
7
8
9

POST /_bulk
{"index":{"_index":"索引库名","_id":"新增id"}}
{"字段1":"值1","字段2":"值2"}
//这两行为新增，第一行为指定索引库以及数据id，第二行是具体数据，在批量处理中，可以同时执行多个
{"delete":{"_index":"索引库名","_id":"删除id"}}
//这一行为删除，只需指定删除的索引库名以及具体id即可
{"update":{"_index":"索引库名","_id":"更新id"}}
{"doc":{"字段1":"值1"}}
//这两行为修改，第一行指定索引库名和id，第二行是修改的具体内容

客户端JavaClient

索引库操作

客户端初始化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class ElasticTest{
    private RestHighLevelClient client;
    
    @BeforeEach
    void setUp(){
        client = new RestHighLevelClient(RestClient.builder(
            HttpHost.create("http://192.168.150.101:9200")
        ));
    }
    
    @AfterEach
    void tearDown() throw IOException {
        if(client != null){
            client.close();
        }
    }
}

添加索引库

1
2
3
4
5
6
7
8
9

@Test
void testCreateHotelIndex()throws IOException{
    //1.创建request对象
    CreteIndexRequest request = new CreteIndexRequest("索引库名");
    //2.请求参数，MAPPING_TEMPLATE是静态常量字符串，内容是JSON格式请求体
    request.source(MAPPING_TEMPLATE,XContentType.JSON);
    //3.发起请求
    client.indics.create(request,RequestOptions.DEFAULT);
}

删除索引库

1
2
3
4
5
6
7

@Test
void testCreateHotelIndex () throws IOException {
    //1.创建Request对象
    CreteIndexRequest request = new CreteIndexRequest("索引库名");
    //2.发起请求
    client.indics.delete(request,RequestOptions.DEFAULT);
}

查询索引库

1
2
3
4
5
6
7

@Test
void testCreateHotelIndex () throws IOException {
    //1.创建Request对象
    CreteIndexRequest request = new CreteIndexRequest("索引库名");
    //2.发起请求
    client.indics.get(request,RequestOptions.DEFAULT);
}

索引库一般不支持修改已有的字段，但支持修改未有的字段，换句话说，就是支持增加新的字段

文档操作

新增文档

1
2
3
4
5
6
7
8
9

@Test
void testIndexDocument () throws IOException {
    //1.创建request对象
    IndexRequest request = new IndexRequest("索引库名").id("新增id");
    //2.准备Json文档
    request.source(JSONUtil.toJsonStr(item),XContentType.JSON);
    //3.发送请求
    client.index(request,RequestOptions.DEFAULT);
}

删除文档

1
2
3
4
5
6
7

@Test
void testIndexDocument () throws IOException {
    //1.创建request对象
    DeleteRequest request = new DeleteRequest("索引库名","删除id");
    //2.发送请求
    client.delete(request,RequestOptions.DEFAULT);
}

查询文档

1
2
3
4
5
6
7
8
9
10
11

@Test
void testIndexDocument () throws IOException {
    //1.创建request对象
    GetRequest request = new GetRequest("索引库名","查询id");
    //2.发送请求，得到结果
    GetReponse response = client.get(request,RequestOptions.DEFAULT);
    //3.解析结果
    String json = response.getSourceAsString();
    Item item = JSONUtil.toBean(json,Item.class);
    System.out.println(item);
}

修改文档

• 全量更新：与新增文档的API完全相同，只不过第一次使用如果没有id，就是新增，再次使用就是修改，注意要传入完整的参数

• 局部更新：只更新指定字段

  1 2 3 4 5 6 7 8 9 10 11 12

  @Test void testIndexDocument () throws IOException { //1.创建Request对象 UpdateRequest request = new UpdateRequest("索引库名","修改id"); //2.准备参数 request.doc( "age",18, "name","Rose" ); //3.更新文档 client.update(request,RequestOptions.DEFAULT); }

批量处理

1
2
3
4
5
6
7
8
9
10

@Test
void testBulk () throws IOException{
    //1.创建Bulk请求
    BulkRequest request = new BulkRequest();
    //2.添加要批量提交的请求
    request.add(new IndexRequest("索引库名").id("添加id").source("json source",XContentType.JSON));
    request.add(new IndexRequest("索引库名").id("添加id").source("json source",XContentType.JSON));
    //3.发起bulkqingq
    client.bulk(request,RequestOptions.DEFAULT);
}

DSL查询

由于以上的查询，都只能通过id查询，但是搜索引擎中一定要具备根据复杂条件查询的功能，所以DSL查询可以达到这种功能

基本语法

1
2
3
4
5
6
7
8

GET /索引库名/_search
{
    "query":{
        "查询类型":{
            "查询条件":"条件值"
        }
    }
}

叶子查询

全文检索查询：利用分词器对用户输入内容分词，然后去词条列表中匹配，拿到相应的文档id，最后根据id查到文档。例如：match_query，multi_match_query

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

GET /索引库名/_search
{
    "query":{
        "match":{
            "FILED":"TEXT"
        }
    }
}
//multi_match允许同时查询多个字段
GET /索引库名/_search
{
    "query":{
        "multi_match":{
            "query":"TEXT",
            "fields":["FIELD1","FIELD2"]
        }
    }
}

精确查询：不对用户输入的内容分词，直接精确匹配，一般是查找keyword，数值，日期，布尔等类型。例如：ids,range,term

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

//term查询
GET /索引库名/_search
{
    "query":{
        "term":{
            "FIELD":{
                "value":"VALUE"
            }
        }
    }
}
//range查询
GET /索引库名/_search
{
    "query":{
        "range":{
            "FIELD":{
                "gte":10,
                "lte":20
            }
        }
    }
}

地理查询：用于搜索地理位置，搜索方式有很多，例如：geo_distance,gep_bouding_box

复合查询

由多个叶子查询组成的称为符合查询，分为两类，一类是基于逻辑运算组合叶子查询，实现组合条件，例如布尔查询

另一类是基于某种算法修改查询时的文档相关性算分，从而改变文档排名

布尔查询是一个或多个查询子句的组合。子查询的组合方式有：

• must：必须匹配每个子查询，类似”与”
• should：选择性匹配子查询，类似”或”
• must_not：必须不匹配，不参与算分，类似”非”
• filter：必须匹配，不参与算分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Get /索引库名/_search
{
    "query":{
        "bool":{
            "must":[
                {"match":{"name":"手机"}}
            ],
            "should":[
                {"term":{"brand":{"value":"vivo"}}},
                {"term":{"brand":{"value":"小米"}}}
            ],
            "must_not":[
                {"range":{"price":{"gte":2500}}}
            ],
            "filter":[
                {"range":{"price":{"lte":1000}}}
            ]
        }
    }
}

排序与分页

默认根据相关性算分来排序，也可以指定字段排序。可以排序字段类型有：keyword类型，数值类型，地理坐标类型，日期类型等

1
2
3
4
5
6
7
8
9
10
11

GET /索引库名/_search
{
    "query":{
        "match":{...}
    },
        "sort":[
            {
                "FIELD":"desc" 
            }
        ]
}

ES默认情况下只返回top10的数据。如果想要查询更多数据就需要修改分页参数。ES通过修改from，size参数来控制要返回的分页结果，from时从第几个文档开始，size：总共查询几个文档

1
2
3
4
5
6
7
8
9
10
11

Get/索引库名/_search
{
    "query":{
        "match":{...}
    },
    "from":0,
    "size":10,
    "sort":[
        {"price":"asc"}
    ]
}

深度分页问题

例如我要查第一千页的数据，每页有十条，那也就是第9990条数据到第一万条数据，然后我实际需要查到前一万条数据，再从其中选出需要的数据，在分片集群中，我就需要在每一个分片中查一万条数据汇总取出前一万，以此类推，随着查询页数的增加，我要在每个分片中查到的数据增多，最后又可能造成爆内存的现象，这就是深度分页问题

解决方案 search after

search_after是一种基于游标的分页机制，它允许你指定从某个特定的文档之后开始检索数据，从而避免了传统的分页方式中需要跳过大量数据的问题。具体来说，search_after需要你在首次查询时指定排序字段和排序方向，并在查询结果中获取最后一个文档的排序字段值。在后续的查询中，你可以将这个值作为search_after参数传递给Elasticsearch，以从该文档之后开始检索数据。避免从零开始获取from + size条数据的低效方式。相反，search_after允许我们根据上一次查询结果中最后一个文档的排序字段值（即游标）来继续向后获取数据段。

• 优点：显著提高查询性能，支持深度分页
• 缺点：只能向后逐页查询，不能随即分页

高亮显示

要想使查询关键词在文档中高亮，我们需要在文档中拿到所有关键词，在html页面中为其加入一个统一的标签，在css样式中为这种标签加入同意的样式就可以实现高亮显示了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

GET /索引库名/_search
{
    "query":{
        "match":{
            "FIELD":"TEXT"
        }
    },
    "highlight":{
        "fields":{  //指定要高亮的字段
            "FIELD":{
                "pre_tags":"<em>",  //高亮的前置标签
                "post_tags":"</em>"  //高亮的后置标签
            }
        }
    }
}

JavaClient查询

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@Test
void testMAtchAll () throws IOException{
    //1.准备request
    SearchRequest request = new SearchRequest("索引库名");
    //2.组织DSL参数
    request.source()
        .query(QueryBuilders.matchAllQuery());
    //3.发送请求，得到响应结果
    SearchResponse response = client.search(request,RequestOptions.DEFAULT);
    //4.解析结果
    SearchHits searchHits = response.getHits();
    //4.1查询的总条数
    Long total = searchHits.getTotalHits().value;
    //4.2查询的结果数组
    SearchHits[] hits = searchHits.getHits();
    for(SearchHit : hits){
        String json = hit.getSourceAsString();
        Item item = JSONUtil.toBean(json,Item.class);
    }
}

复杂查询以及分页排序高亮显示

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

//组织DSL参数
request.source().query(QueryBuilders.boolQuery
                      .must(QueryBuilders.matchQuery("name","脱脂牛奶"))
                      .filter(QueryBuilders.termQuery("brand","德亚"))
                      .filter(QueryBuilders.rangeQuery("price").lt(30000))
);
//分页
request.source.from(0).size(5);
//排序
request.source.sort("price",SortOrder.ASC);
//高亮显示
request.source.highlighter(
    SearchSourceBuilder.highlight()
                .filed("name")
                .preTags("<em>")
                .postTags("</em>")
);

数据聚合

聚合可以实现对文档数据的统计，分析，运算。聚合常见的有三类

• 桶(Bucket)聚合：用来对文档做分组

  TermAggregation：按照文档字段值分组

  Date Histogram：按照日期阶梯分组，例如一周为一组，一月为一组

• 度量(Metric)聚合：用于计算一些值，比如：最大值，最小值，平均值等

  Avg：求平均值

  Max：求最大值

  Min：求最小值

  Stats：同时求max，min，avg，sum等

• 管道(popeline)聚合：其他聚合的结果为基础做聚合

DSL聚合

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

//普通桶聚合
GET /索引库名/_search
{
    "query":{"match_all":{}},  //可以省略
    "size": 0,  //设置size为0，结果中不包含文档，只包含聚合结果
    "aggs":{  //定义聚合
        "cateAgg":{  //给聚合起个名字
            "terms" :{  //聚合的类型，按照品牌值聚合，所以选term
                "field":"category", //参与聚合的字段
                "size":20  //希望获取的聚合结果数量
            }
        }
    }
}
//度量聚合
GET /索引库名/_search
{
    "query":{
        "trem":{"category":"手机"}
    },
    "size": 0,
    "aggs":{
        "brand_agg":{
            "terms":{
                "field":"brand"
            },
            "aggs":{ //做度量聚合，要在桶聚合内在嵌套一个聚合
                "price_stats":{
                    "stats":{
                        "field":"price"
                    }
                }
            }
        }
    }
}

Java客户端数据聚合

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

request.source.query(QueryBuilders.term("category":"手机"));
request.source.size(0);
request.source.aggregation(
    AggregationBuilders
          .terms("brand_agg")
          .field("brand")
          .size(20)
);
//解析聚合结果
Aggregations aggregations = response.getAggregations();
//根据名称获取聚合结果
Terms brandTerms = aggregations.get("brand_agg");
//获取桶
List<? extends Term.Bucket> buckets = brandTerms.getBuckets();
//遍历
for(Terms.Bucket bucket : buckets){
    //获取key，也就是品牌信息
    String brandName = bucket.getKeyAsString();
    System.out.println(brandName);
}

方法自调用导致的事务失效

• 场景：在Spring中，声明式事务通常是通过AOP（面向切面编程）实现的，这意味着事务管理是通过代理对象对目标方法的调用进行增强的。然而，当同一个类中的方法A调用方法B，且方法B上使用了@Transactional注解时，如果这种调用是直接进行的（即非通过代理对象），那么事务的增强处理就不会被触发，从而导致事务失效。
• 原因：AOP代理通常是通过Spring的容器在运行时动态生成的，它仅对外部调用进行拦截和处理。对于类内部的直接方法调用，由于绕过了代理对象，因此无法应用事务的增强。
• 解决方案：既然调用的不是代理对象，那我们就想办法获取代理对象，通过AopContext.currentProxy()获取当前类的代理对象，并通过该代理对象调用方法B。但请注意，这种方式需要确保在Spring配置中启用了@EnableAspectJAutoProxy(exposeProxy = true)

异常处理不当导致的事务失效

• 场景：如果@Transactional注解的方法内部捕获了异常，并且没有将异常重新抛出，或者没有将捕获的异常类型指定为需要回滚的异常类型，那么Spring默认不会触发事务的回滚。

• 原因：Spring根据异常的抛出情况来决定是否回滚事务。默认情况下，只有运行时异常（RuntimeException及其子类）和错误（Error）会触发回滚。对于受检异常（Exception的子类，但排除RuntimeException及其子类），除非在@Transactional注解中明确指定，否则不会触发回滚。

• 解决方案

  确保事务内部的方法被正确抛出

  使用@Transactional注解的rollbackFor属性来指定需要回滚的异常类型，包括受检异常。

非Public方法上的事务失效

• 场景：如果@Transactional注解被放置在非public方法上（如private、protected或默认访问权限的方法），那么事务将不会生效。
• 原因：Spring在创建代理对象时，仅会扫描和处理public方法的注解。非public方法由于访问权限的限制，无法被代理对象拦截和处理。
• 解决方案：将事务的方法改为public修饰

事务传播行为不对导致的事务失效

• 场景：在一个事务方法中如果调用了其他事务方法，而事务的传播行为不当，例如使用了REQUIRES_NEW，就表示了进入该方法创建了一个新事务，这样会导致事务失效
• 原因：在抛出异常时，该方法作为独立事务，不会随主方法进行回滚
• 解决方案：慎用传播行为

没有被Spring管理导致的事务失效

• 场景：若一个方法没有被Spring管理，则事务失效
• 原因：若不被Spring管理，就没有人替你生成代理对象，事务自然失效
• 解决方案：注意该类有没有被Spring所管理

额外知识补充（事务传播行为）

1. PROPAGATION_REQUIRED（默认）：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
2. PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式执行。
3. PROPAGATION_MANDATORY：如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
4. PROPAGATION_REQUIRES_NEW：创建一个新的事务，并暂停当前事务（如果存在）。
5. PROPAGATION_NOT_SUPPORTED：以非事务方式执行，如果当前存在事务，则把当前事务挂起。
6. PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。
7. PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则行为等同于PROPAGATION_REQUIRED。

高并发时的优化方案

变同步为异步

适用范围

变同步为异步主要用于那些业务逻辑复杂、处理时间较长、且对实时性要求不是非常高的场景。具体来说，当系统面临大量并发请求，且每个请求都需要进行多个数据库操作或调用多个远程服务时，采用同步处理方式会导致线程阻塞，影响系统整体的并发能力。此时，可以考虑将部分或全部业务逻辑异步化，以提高系统的响应速度和吞吐量。

优化方案

我们可以通过MQ(消息队列)将同步业务变为异步业务，从而提高效率，在业务处理流程中，当需要异步处理的任务产生时，将任务封装成消息发送到MQ的交换机中。交换机根据路由规则将消息发送到指定的队列。创建消费者监听队列中的消息。当队列中有消息时，消费者从队列中获取消息并进行处理。

优点

• 无需等待复杂业务处理，大大减少响应时间
• 利用MQ暂存消息，起到流量削峰整形作用
• 降低写数据库频率，减轻数据库并发压力

缺点

• 依赖于MQ的可靠性
• 降低了些频率，但是没有减少数据库写次数

合并写请求

适用范围

合并写请求主要用于那些写操作频繁且数据关联度较高的场景。例如，在电商系统中，用户可能同时购买多个商品并生成多个订单记录，这些订单记录可以合并为一个写请求发送到数据库进行处理。此外，对于日志记录、数据同步等场景，也可以考虑将多个写请求合并为一个进行处理。

优化方案

合并写请求就是指当写数据库并发较高时，不再直接写到数据库。而是先将数据缓存到Redis，然后定期将缓存中的数据批量写入数据库。由于redis时内存操作，所以写的效率大大提高，同时减少了DB操作，对数据库的压力减小

优点

• 写缓存速度快，响应时间大大减少
• 降低数据库的写频率和写次数，大大减轻数据库压力
• 降低网络开销，提高数据传输效率

缺点

• 实现相对复杂
• 依赖Redis可靠性
• 不支持事务和复杂业务