GO性能优化+底层管理+RDBMS | 青训营笔记

安静的秃头怪
83 阅读3分钟

性能优化

  1. benchmark基准性能测试工具：go test -bench=. -benchmem
  2. slice和map预分配内存（定义容量）
  3. 拷贝切片用copy替代re-slice
  4. 优先使用strings.Builder和bytes.Buffer，内置扩容策略
  5. 空结构体作为占位符（场景：实现set）
  6. 使用atomic包实现并发安全，代替Lock

自动内存管理

  1. GC分类：Serial GC（只有一个collector）、Parallel GC（支持多个collectors同时回收）、Concurrent GC（mutators和collectors可以同时执行）
  2. 追踪垃圾回收（Tracing garbage collection）
    1. 标记根对象
      • 静态变量、全局变量、常量、线程栈
    2. 标记：找到可达对象
      • 根据指向关系找到所有可达对象
    3. 清理：所有不可达对象
      • Copying GC：将存活对象复制到另外的内存空间 1684230519229.png
      • Mark-sweep GC：将死亡对象的空间串成free list 1684230585240.png
      • Mark-compact GC：原地整理对象，跟Copying GC相似 1684230622773.png
  3. 引用计数（Reference counting）
    • 每个对象都有一个引用数目，当且仅当引用数大于0时对象存活，否则回收
    • 缺点：开销大、无法回收环形数据结构 1684230664041.png
  4. 重点：根据对象的生命周期，使用不同的标记和清理策略
  5. Go内存管理：分块+缓存（缺点：分配路径过长、小对象居多）
    • 分配路径：g->m->p->mcache->mspan->memory block->return pointer 1684230712791.png

编译器

  1. Go编译器会尽可能将变量分配到栈上。但是，当编译器无法证明函数返回后，该变量没有被引用，那编译器就必须在堆上分配该变量，以此避免悬挂指针。另外，如果局部变量很大也会分配在堆上。
  2. 逃逸分析：检查变量的生命周期是否是完全可知的，如果通过检查，则在栈上分配；否则为逃逸，必须在堆上分配。
  3. go build -gcflags '-m -l' main.go 可以查看逃逸分析结果

RDBMS（Relational Database Management System）事务ACID特性

  1. Atomicity（原子性）：事务内的操作要么全做，要么不做
  2. Consistency（一致性）：事务执行前后，数据状态是一致的（合法）
  3. Isolation（隔离性）：可以隔离多个并发事务，避免影响
  4. Durability（持久性）：事务一旦提交成功，数据保证持久性

主流存储产品

  1. 单机存储
    • 本地文件系统：Linux（一切皆文件、Index Node ＆ Directory Entry）
    • key-value存储
  2. 分布式存储（单机存储+分布式协议）
    • 分布式文件系统：HDFS
    • 分布式对象存储：Ceph（万金油，一切皆对象）
  3. 单机数据库
    • 关系型数据库：Oracle、MySQL、PostgreSQL
    • 非关系型数据库：MongoDB、Redis、Elasticsearch

RDBMS三大引擎

  1. SQL引擎
    • Parser：词法分析、语法分析、语义分析
    • Optimizer：基于规则的优化（RBO Rule Base Optimizer）、基于代价的优化（CBO Cost Base Optimizer）
    • Executor：火山模型、向量化、编译执行
  2. 存储引擎
    • InnoDB
    • Buffer Pool
    • Page 1684317574943.png
    • B+ Tree 1684317604377.png
  3. 事务引擎
    • Atomicity：Undo Log（逻辑日志）实现事务回滚
    • Isolation：Lock、MVCC（多版本并发控制）
    • Durability：Redo Log（物理日志）保证事务持久化

抖音红包雨活动案例

  1. 大流量-Sharding
    • 问题背景：单节点写容易成为瓶颈、单机数据容量上限
    • 解决方案：业务数据进行水平拆分、代理层进行分片路由
  2. 流量突增-扩容
    • 问题背景：活动流量上涨、集群性能不满足要求
    • 解决方案：扩容DB物理节点数量、利用影子表进行压测
  3. 流量突增-代理连接池
    • 问题背景：突增流量导致大量建联；大量建联导致负载变大、延时上升
    • 解决方案：业务侧预热连接池、代理侧预热连接池、代理侧支持连接队列
  4. 稳定性＆可靠性-3AZ高可用
    • 三机房部署
    • proxy
    • 监控报警
    • HA管理
  5. 稳定性＆可靠性-HA管理
    • 问题背景：DB所在机器异常宕机、DB节点异常宕机
    • 解决方案：HA服务监管、切换宕机节点；代理支持配置热加载；代理自动屏蔽宕机读节点
avatar
文章
阅读
粉丝