2023 年 11 月 – manno的博客

1. 优化sql、索引

sql优化

避免多表联合查询，优化难度大
设置合理的查询字段，避免多次回表

索引

建立合适的索引
避免索引失效

2. 引入缓存

优点

解决读的性能瓶颈

缺点

缓存数据库一致性
缓存穿透
缓存雪崩
缓存击穿
架构复杂（高可用）

3.读写分离

架构方案

客户端直接连接客户端直连方案，因为少了一层 proxy 转发，所以查询性能稍微好一点儿，并且整体架构简单，排查问题更方便。但是这种方案，由于要了解后端部署细节，所以在出现主备切换、库迁移等操作的时候，客户端都会感知到，并且需要调整数据库连接信息。中间件：ShardingSphere
带proxy 带 proxy 的架构，对客户端比较友好。客户端不需要关注后端细节，连接维护、后端信息维护等工作，都是由 proxy 完成的。但这样的话，对后端维护团队的要求会更高。而且，proxy 也需要有高可用架构。因此，带 proxy 架构的整体就相对比较复杂。中间件：ShardingSphere 、Atlas 、mycat

优点

分担主库的压力

缺点

从延迟，导致往主库写入的数据跟从库读出来的数据不一致

解决方案

强制走主库方案；
sleep 方案；主库更新后，读从库之前先 sleep 一下。具体的方案就是，类似于执行一条 select sleep(1) 命令。
判断主备无延迟方案； seconds_behind_master 参数的值，可以用来衡量主备延迟时间的长短。 seconds_behind_master 是否已经等于 0。如果还不等于 0 ，那就必须等到这个参数变为 0 才能执行查询请求。
配合 semi-sync 方案；事务提交的时候，主库把 binlog 发给从库；从库收到 binlog 以后，发回给主库一个 ack，表示收到了；主库收到这个 ack 以后，才能给客户端返回“事务完成”的确认。
等主库位点方案；

Master_Log_File 和 Read_Master_Log_Pos，表示的是读到的主库的最新位点；
Relay_Master_Log_File 和 Exec_Master_Log_Pos，表示的是备库执行的最新位点。如果 Master_Log_File 和 Relay_Master_Log_File、Read_Master_Log_Pos 和 Exec_Master_Log_Pos 这两组值完全相同，就表示接收到的日志已经同步完成。

等 GTID 方案。

Auto_Position=1 ，表示这对主备关系使用了 GTID 协议。
Retrieved_Gtid_Set，是备库收到的所有日志的 GTID 集合；
Executed_Gtid_Set，是备库所有已经执行完成的 GTID 集合。如果这两个集合相同，也表示备库接收到的日志都已经同步完成。

4. 分区表

例子

CREATE TABLE `t` (
  `ftime` datetime NOT NULL,
  `c` int(11) DEFAULT NULL,
  KEY (`ftime`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
PARTITION BY RANGE (YEAR(ftime))
(PARTITION p_2017 VALUES LESS THAN (2017) ENGINE = InnoDB,
 PARTITION p_2018 VALUES LESS THAN (2018) ENGINE = InnoDB,
 PARTITION p_2019 VALUES LESS THAN (2019) ENGINE = InnoDB,
PARTITION p_others VALUES LESS THAN MAXVALUE ENGINE = InnoDB);
insert into t values('2017-4-1',1),('2018-4-1',1);

这个表包含了一个.frm 文件和 4 个.ibd 文件，每个分区对应一个.ibd 文件。对于引擎层来说，这是 4 个表；对于 Server 层来说，这是 1 个表。

5.竖直分表

优点

拆分后业务清晰，拆分规则明确。
系统之间整合或扩展容易。
数据维护简单。

缺点

部分业务表无法join，只能通过接口方式解决，提高了系统复杂度。
受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。
事务处理复杂。

6.水平分表

优点

优化单一表数据量过大而产生的性能问题
避免IO争抢并减少锁表的几率

缺点

主键避免重复（分布式Id）
跨节点分页、排序函数
数据多次扩展难度跟维护量极大

从Linux内核中获取真随机数

内核随机数产生器

Linux内核实现了一个随机数产生器，从理论上说这个随机数产生器产生的是真随机数。与标准C库中的rand(),srand()产生的伪随机数不同，尽管伪随机数带有一定的随机特征，但这些数字序列并非统计意义上的随机数。也就是说它们是可重现的–只要每次使用相同的seed值，就能得到相同的伪随机数列。通常通过使用time()的返回值来改变seed，以此得到不同的伪随机数序列，但time()返回值的结果并不是不确定的（可预测），也就是这里仍然缺少一个不确定的噪声源。对于需要真随机数的程序，都不能允许使用伪随机数。

为了获得真正意义上的随机数，需要一个外部的噪声源。Linux内核找到了一个完美的噪声源产生者–就是使用计算机的人。我们在使用计算机时敲击键盘的时间间隔，移动鼠标的距离与间隔，特定中断的时间间隔等等，这些对于计算机来讲都是属于非确定的和不可预测的。虽然计算机本身的行为完全由编程所控制，但人对外设硬件的操作具有很大的不确定性，而这些不确定性可以通过驱动程序中注册的中断处理例程(ISR)获取。内核根据这些非确定性的设备事件维护着一个熵池，池中的数据是完全随机的。当有新的设备事件到来，内核会估计新加入的数据的随机性，当我们从熵池中取出数据时，内核会减少熵的估计值。

dev/random与dev/urandom之争?

命令使用方法

在Golang中使用

type RandomGenerator struct{} func (r *RandomGenerator) GetNum() (random int64, err error) { //gen num 4 1bytes len uint cmd := exec.Command("od", "-vAn", "-N4", "-tu1", "/dev/random") outputStr := strings.Builder{} stdout, err := cmd.StdoutPipe() if err != nil { fmt.Println(err) } if err = cmd.Start(); err != nil { fmt.Println(err) return } go func() { scr := bufio.NewScanner(stdout) for { if scr.Scan() { fmt.Println(scr.Text()) outputStr.WriteString(scr.Text()) } if scr.Err() != nil { return } } }() if err = cmd.Wait(); err != nil { fmt.Println(err) return } randomStr := strings.ReplaceAll(outputStr.String(), " ", "") //fmt.Printf("randomStr:%v\n", randomStr) if len(randomStr) == 0 { return r.GetNum() } random, err = strconv.ParseInt(randomStr, 10, 64) if err != nil { fmt.Printf("strconv.ParseInt err:%v", err.Error()) return } return }

月度归档： 2023 年 11 月

解决数据大表的架构方案