1. 本月开始周练了，哎，继续上路吧。
2. RocksDB 解决了什么问题?
海量随机写入时，传统磁盘存储性能急剧下降的问题。
针对 SSD（尤其是 NAND Flash SSD） 做了大量优化。SSD 支持随机读写，不代表随机写“没有代价”。
SSD 的随机读取性能很好，但随机写入仍然昂贵；RocksDB 的目标就是尽量把大量随机更新转换成顺序追加写，从而降低写放大并提升吞吐。
传统数据库（如 InnoDB）使用 B+Tree，在超高写入场景下的问题
特点：
-
数据按页组织（通常 16KB）
-
插入时需要修改页
-
页满时发生 split
-
每次修改都涉及随机磁盘写
当写入量很大时，会出现：
-
随机 I/O 非常多
-
SSD 写放大严重，
-
吞吐下降
-
延迟抖动
RocksDB 基于 Log-Structured Merge-Tree（LSM Tree）
核心思想：先顺序写入，再后台整理。
这带来：
-
更高写入吞吐
-
更低写入延迟
-
更好的 SSD 寿命
-
更低成本
工程思想
把“每次都整理”变成“先堆积，再批量整理”。
哪些成熟产品在用？
Kafka、Flink等。
3. MySQL Explain Analyze
早期 MySQL 只有EXPLAIN（优化器预测）、后来 MySQL 增加：EXPLAIN FORMAT=JSON，信息更多但依旧是估算。
MySQL 8.0.18 引入。EXPLAIN ANALYZE，真执行一次 SQL，然后输出执行过程。是实际执行结果！！
4. 乱序到达
上游能做的顶多是“尽量有序”，但是无法承诺严格有序。下游依赖上游保证有序，是不合理的。下游自己处理才是正确的姿势。
但是不能依赖时间戳处理，不靠谱：时钟可能不同步、同一个毫秒可能会有多个事件、时钟回拨等等，总之，分布式系统的物理时钟是不可信的。
应该有状态机，控制状态流转。状态分两类：
中间态：有前置条件，有后续流转。状态机可以管理
终态：没有后续流转，只有“能不能进入”，状态机管不了顺序。只能靠语义定义，一旦进入，不可覆盖。
设计系统的时候，一定要定义好终态，终态怎么触发，触发了能不能撤销、和其他终态冲突了怎么办。
