su-pro/blog

blog's Issues

「one page ： 并发」

异步I/O

MySQL - 组织架构

server层

连接器

如果用户名密码认证通过，连接器会到权限表里面查出你拥有的权限。之后，这个连接里面的权限判断逻辑，都将依赖于此时读到的权限。

这就意味着，一个用户成功建立连接后，即使你用管理员账号对这个用户的权限做了修改，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。

连接管理

show processlist & wait_timeout

数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。

使用长链接会出现的问题：有些时候 MySQL 占用内存涨得特别快，这是因为 MySQL 在执行过程中临时使用的内存是管理在连接对象里面的。这些资源会在连接断开的时候才释放。所以如果长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是 MySQL 异常重启了。

解决思路：

1. 定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。（如何操作呢？）
2. 可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。

查询缓存

但是大多数情况下我会建议你不要使用查询缓存，为什么呢？因为查询缓存往往弊大于利。

查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。

MySQL 8.0 版本直接将查询缓存的整块功能删掉

分析器 (重要)

优化器

执行器

「onepage ： 系统设计」

Elasticsearch 基本原理

冗余数据的一致性

MySQL事务操作

「2021/11/4th-week + 2021/12/1th」11.22 ~ 12.05

用Redis 还是用MySQL？

MySQL - 日志系统

redo log - 物理日志

解决每次更新数据时都使用随机I/O慢的直接刷盘

WAL技术

而粉板和账本配合的整个过程，其实就是 MySQL 里经常说到的 WAL 技术，WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时候再写账本。
具体来说，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉板）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做，这就像打烊以后掌柜做的事。

carsh-safe

要理解 crash-safe 这个概念，可以想想我们前面赊账记录的例子。只要赊账记录记在了粉板上或写在了账本上，之后即使掌柜忘记了，比如突然停业几天，恢复生意后依然可以通过账本和粉板上的数据明确赊账账目。

bin log - 逻辑日志

区别 redo log

1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
2. redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
3. redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

2PC

「2021/12/2th-week」12.06 ~

上午gg : ）起床7:40… 学校事宜耽搁整个上午。（好在运动了）

12.06 周一

回顾

计算机基础

• 内存基本原理，直接映射

--- 🍅 ✖️1 ---

错误/想法

1. 没有即时复盘当日，延迟到周二晚上才写，此时印象已经不深了…
2. 是否可以把计算机基础知识整理成读书笔记？会不会增加额外时间成本？是否有会更有收益？

数据存储：幂等

基本策略（缓存 + CDN）

「2020/11/3th-week」11 ~ 22

回顾

大事件

1. 「家庭向」：闺女2周岁照，近期准备亲子照（护肤、身材管理）
2. 「个人向」：开启早起学习状态（7点前），并在下周开始进入半素饮食保证精气神
3. 「技术向」：最终确定半年技术规划（修正为：node&底层知识体系 + serverless&系统设计实现）

精力投入

无量化记录，大致如下：

「技术」

1. 计算机组成原理之存储体系
2. serverless 调研

「个人」

1. 重训
2. 吃鸡

进展

node 底层体系：异步I/O篇 之 I/O 基本梳理完毕

下周避免的错误

1. 每日的精力投入要有归档（大致时间消耗，以及状态） -> 子弹笔记
2. 保持良好状态，优化健身时间点 （分析当前状态，以及计划落地）
3. 控制自己，避免贪玩（游戏、思维发散）

下周规划（双周）

精力投入

70% to 技术方向

30% to 身材管理

预计进展

• 《node底层体系：异步I/O和单线程 》归档至团队知识图谱
• 《serverless in action》粗读完毕，过一遍项目源代码
• 实操：url shortener
• 规划系统设计准确目标

错误改正方案

「one page : 数据体系设计」

分布式事务