经验分享
未读Hexo的用法示例此部分为Hexo使用知识汇总，方便后续创作使用，汇集各位大佬的总结，此处注明大部分来自安知鱼大佬
Front-matter 的基本认识Front-matter 是 markdown 文件最上方以 —- 分隔的区域，用于指定个别档案的变数。其中又分为两种
如果标注可选的参数，可根据自己需要添加，不用全部都写在 markdown 里
Page Front-matter 用于页面配置
Post Front-matter 用于文章页配置
Page Front-matterPost Front-matter12345678910111213141516---title:date:updated:type:comments:description:keywords:top_img:mathjax:katex:aside:aplayer:highlight_shrink:type:---
写法
解释
title
【必需】页面标题
date
【必需】页面创建日期
type
【必需】标签、分类、关于、音乐馆、友情链接、相册、相册详情、朋友圈、即刻页面需 ...
此文为转载文章来自大佬安知鱼,为方便后面创作时使用。
段落文本 p标签语法配置参数样式预览示例源码1{% p 样式参数(参数以空格划分), 文本内容 %}
字体: logo, code
颜色: red,yellow,green,cyan,blue,gray
大小: small, h4, h3, h2, h1, large, huge, ultra
对齐方向: left, center, right
彩色文字在一段话中方便插入各种颜色的标签，包括：红色、黄色、绿色、青色、蓝色、灰色。
超大号文字文档「开始」页面中的标题部分就是超大号文字。Volantis
A Wonderful Theme for Hexo
123456- 彩色文字 在一段话中方便插入各种颜色的标签，包括：{% p red, 红色 %}、{% p yellow, 黄色 %}、{% p green, 绿色 %}、{% p cyan, 青色 %}、{% p blue, 蓝色 %}、{% p ...
索引优化、事务锁、主从复制和分库分表能帮你“跑得快、扛得住”，但数据一旦误删、磁盘损坏或勒索软件加密，backup 才是最后一道防线。本文聚焦 MySQL 备份与恢复：从 mysqldump 到 XtraBackup，再到 binlog 定点恢复，把“能回滚”这件事讲透。
一、备份是最后一道防线很多团队把备份当成“有就行”，直到出事才发现：
备份文件损坏，无法解压。
只备份了 schema，没备份数据。
恢复演练从没做过，真正恢复时耗时半天。
binlog 没开，误删后只能回档到昨晚的全量。
所以备份的核心目标不只是“存一份数据”，而是在可接受的时间内，恢复到可接受的状态。
二、备份分类与策略2.1 逻辑备份 vs 物理备份
维度
逻辑备份（mysqldump）
物理备份（XtraBackup）
形式
SQL 文本 / CSV
数据文件副本
速度
慢（逐行导出）
快（拷贝页 + redo）
体积
大，可压缩
接近原库，可压缩
恢复
逐条执行 SQL
直接替换数据文件
适用
小库、跨版本、部分表
大库、生产全量、热备
一致性
--single-tr ...
主从复制和读写分离能扛住读流量，却扛不住写流量无限增长。当单库写性能、磁盘容量或连接数触及天花板时，分库分表就成了必经之路。本文从拆分策略讲到 ShardingSphere 落地，帮你把“拆”这件事拆明白。
一、单库撑不住时，先别急着分分库分表是把双刃剑：它解决了容量与性能问题，却引入了复杂度。在决定拆分之前，先确认是否已经把单库优化到极致。
1.1 什么指标说明该拆了
瓶颈类型
常见阈值
说明
单表数据量
5000 万 ~ 1 亿行
InnoDB B+Tree 层级变深，范围查询变慢
单库数据量
500 GB ~ 1 TB
备份、恢复、迁移成本陡增
单库连接数
80% max_connections
应用池化再好也会被打满
单库写 TPS
CPU / IO 长期 80%+
索引维护、redo log、锁竞争放大
1.2 拆分前的三板斧
SQL 与索引优化：慢查询、索引失效、大事务往往是真正元凶，详见 MySQL 索引优化专题。
读写分离：把读流量拆到从库，主库只负责写，成本比分片低得多。
缓存与归档：热数据放 Redis，冷数据归档，能大幅推迟拆分 ...
“线上读写都在一台 MySQL，CPU 飙到 90% 怎么办？””主库挂了，多久能切换？”主从复制和读写分离是 MySQL 横向扩展与容灾的必经之路。本文从复制原理到生产落地一次性讲透。
一、为什么需要主从复制单节点 MySQL 同时承担读和写时，随着流量增长，很快会碰到三大瓶颈：
瓶颈
表现
影响
读压力
查询量过大，CPU/内存/IO 飙升
影响写入稳定性
可用性
单点故障导致整个业务不可用
RTO 无法保证
备份
在业务库上直接做全量备份
锁表、抖动、影响线上
主从复制（Replication）把主库（Master）的数据实时同步到一个或多个从库（Slave），做到：
读扩展：把读流量分散到从库。
高可用：主库故障时，从库可快速切换。
离线备份：在从库上做备份、归档、报表，不打扰主库。
二、复制依赖：binlog 与 relay logMySQL 复制本质上是基于 binlog 的逻辑日志复制。主库把变更记录到 binlog，从库读取并重放。
2.1 binlog 的三种格式
格式
记录内容
优点
缺点
适用场景
STATEME ...
“我用的是 RR 隔离级别，为什么还是出现了幻读？””两个事务各更新一行，结果直接死锁了？”事务和锁是 MySQL 里最容易翻车、也最常被面试官追问的部分。本文从原理到实战一次讲透，建议收藏对照。
一、为什么需要事务没有事务时，一组操作要么全部成功、要么全部失败就无法保证。典型场景：账户 A 给账户 B 转账 100 元，需要执行「A 扣 100」「B 加 100」两条 SQL。如果在两条语句之间数据库宕机，就会出现 A 的钱扣了、B 的钱没加的数据不一致。
事务（Transaction）的作用，就是把多个操作打包成一个不可分割的整体，保证业务的正确性。
二、事务的四大特性：ACID
特性
含义
InnoDB 如何实现
Atomicity 原子性
事务内的操作要么全做、要么全不做
undo log（回滚日志）
Consistency 一致性
事务前后数据都满足业务约束
由 A、I、D 共同保证
Isolation 隔离性
并发事务之间互不影响
锁 + MVCC
Durability 持久性
提交后数据永久保存
redo log（重做日志）
2.1 原 ...
“我明明建了索引，为什么还是全表扫描？”这是 MySQL 优化里最常遇到的问题。索引失效的原因很多，但归根结底就两大类：写法让索引没法用，或者优化器算完账觉得不用更快。本文把两类都拆开讲。
一、先搞懂 InnoDB 的索引结构不理解 B+Tree，就记不住那些失效规则，只能死记硬背。
1.1 为什么是 B+Tree 而不是 BTree
对比项
BTree
B+Tree
数据存储位置
每个节点都存数据
只有叶子节点存数据
叶子节点连接
无
有双向链表相连
单点查询性能
可能更快（根附近就命中）
稳定，都要走到叶子
范围查询
需要中序遍历
沿链表顺序扫描，极快
非叶子节点容量
小（要存数据）
大（只存键值），树更矮
B+Tree 的优势集中在一句话上：非叶子节点不存数据，所以一个页能装下更多键值，树高更矮，磁盘 IO 次数更少。
粗略估算：InnoDB 默认页大小 16 KB，主键为 bigint（8 字节）+ 指针（6 字节）约 14 字节，一个非叶子页能放约 1170 个键值。
树高 2 层：约 1170 × 16 ≈ 1.8 万行
树高 3 ...
Redis 大多数人都”会用”，但线上事故往往出在选型和边界情况上：一个 KEYS * 拖垮整个实例，一次缓存雪崩打穿数据库。本文不讲安装，只讲生产环境真正会遇到的问题。
一、数据结构怎么选选错数据结构的代价，往往是内存翻几倍、或者用一堆笨拙的组合去模拟本该原生支持的能力。
1.1 五种基础类型对比
类型
底层实现
典型场景
单键建议上限
String
SDS 动态字符串
缓存、计数器、分布式锁、Session
值不超过 10 KB
Hash
压缩列表 / 哈希表
对象存储（购物车、用户资料）
field 不超过 1000
List
快速链表
消息队列、最新列表、粉丝列表
元素不超过 1 万
Set
哈希表 / 整数集合
去重、标签、共同好友、抽奖
元素不超过 1 万
ZSet
跳表 + 哈希表
排行榜、延迟队列、优先级队列
元素不超过 1 万
1.2 容易被忽略的选型细节String 存对象 vs Hash 存对象很多人图省事直接把对象序列化成 JSON 塞进 String：
1SET user:1001 '{"n ...
用过 Spring Boot 的人都知道”引入依赖就能用”，但一旦要自己封装一个公共组件给团队复用，就必须搞懂自动装配。本文从源码层面拆开 @SpringBootApplication，然后带你手写一个能放进生产环境的 Starter。
一、自动装配到底做了什么1.1 从 @SpringBootApplication 拆起每个 Spring Boot 项目的启动类上都挂着这么一个注解：
123456@SpringBootApplicationpublic class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); }}
它其实是一个”三合一”的组合注解，扒开源码能看到：
12345678@Target(ElementType.TYPE)@Retention(RetentionPolicy.RUNTIME)@SpringBootConfiguration ...
经验分享
未读下载node.js点击此处下载结果如下图：
双击点击下载的pkg[根据下图步骤依次点击即可]
选择合适的存储位置安装完成之后检验是否成功
黑窗口输入node -v
