这段时间一直在忙着社招跳槽的事，所以本该在过年的时候写下的这篇博客推迟到了现在，不过在经历了横跨了牛年和虎年长达两个月的等待之后，最终如愿拿到了字节的 offer，也算是不辜负这段时间的准备了。
好了，废话少说：
一年过去了，更新一篇作为年终总结。
结合一些实际面试遇到的问题和网上看的八股文，总结一下面试里常问到的 Go 相关的问题。
这个问题的根源是某个 es 集群的分片数过多，集群负载太高，连带着导致 kibana 这边建立不了 index pattern。虽然最终解决还是选择了给集群升配，但这中间给索引做 redindex、shrink 等操作还是积攒了不少经验。
这片文章会讲讲 OSS & CDN 在扇贝的应用，并介绍一下业内常用的 OSS & CDN 架构，所有内容均已脱敏处理。 照例放一下大纲:
- OSS/CDN 是什么？
- 为什么需要它们？
- 扇贝 OSS 梳理
- 扇贝 CDN 梳理
kingshard 是一个用 Go 编写的高性能 Mysql 代理，使用它可以做到业务层面无感知的分库分表，它会自动在业务与数据库之间做好数据的分发与聚合。 显然，从官方文档来看，kingshard 是支持跨节点的批量 insert 操作的，原文如下:
支持非事务方式更新（insert, delete, update, replace）多个 node 上的子表
而 peewee 是 python 中一个微型 orm，不过因为小众，所以连接 kingshard 时发生一些奇怪的问题也很难找到前人踩的坑，所以本文就从搭建一套 kingshard 环境讲起，就验证 peewee 是否能成功在 kingshard 中跨节点批量 insert 做个记录。
按照经验估计，每年年后过来四六级查分的时候都是扇贝各个业务的高峰期，也是扇贝新用户注册的高峰，19 年账号服务刚上线的时候因为这波高峰挂掉过，于是每年春节放假前对账号系统做压测就成了传统，这一次也是我接手账号服务之后做的第一次压测，做个简单的记录。