Weakyon Blog

对于编译器而言，符号的全部相关数据都在Elf32_Sym或Elf64_Sym，以Elf32_Sym为例了解一些编译器的知识，然后再分析C++的语法

1
2
3
4
5
6
7
8
9

typedef struct
{
  Elf32_Word    st_name;   /* Symbol name (string tbl index) */
  Elf32_Addr    st_value;  /* Symbol value */
  Elf32_Word    st_size;   /* Symbol size */
  unsigned char st_info;   /* Symbol type and binding */
  unsigned char st_other;  /* Symbol visibility under glibc>=2.2 */
  Elf32_Section st_shndx;  /* Section index */
} Elf32_Sym;

st_info这个结构是用于区分各种类型的，也是这一篇博文的重点，这个char结构8位

• 高 4 位用于表示 st_bind：

  值	静态链接行为
  STB_LOCAL	允许在不同的目标文件中，存在多个相同名字的符号，符号之间相互隔离（无关联）。
  STB_GLOBAL	只允许一个目标文件存在 GLOBAL 符号定义，其它目标文件允许相同名字的未定义的符号引用，即不允许多个定义。
  STB_WEAK	允许在不同的目标文件中存在多个相同名字的符号。具体来说，如果同时存在一个 GLOBAL 符号和其它同名 WEAK 符号的定义，那就挑选 GLOBAL 符号（ignores the weak ones）；如果存在多个同名 WEAK 符号的定义，事实标准是挑选 linker 解析过程中接触到的第一个符号。

​ 我这里特意强调了静态链接行为，因为静态链接和动态链接虽然对LOCAL的逻辑是一致的，但是动态链接器在符号重定位的时候，对GLOBAL和WEAK是一视同仁的

上一篇hexo源码分析主要分析了hexo.extend.generator的流程

本篇就是实际使用hexo.extend.generator来实现自定义分类页面的功能

预期是像这个C++大佬的博客https://www.fluentcpp.com/posts/一样，存在一个文章总览目录

可以很清晰的进行分类

但是我的需求还要稍微复杂一些，需要支持多级分类，可以实现出一个简单的思维导图分类，例如使用hexo的分类标注的两篇博文

最近业务反馈在我负责的Serverless平台上执行的python脚本，访问azure的speechsdk失败，报错日志如下

1
2
3
4
5
6
7
8

2024-09-02 18:47:16.455 Azure OpenAI is listening. Say 'Stop' or press Ctrl-Z to end the conversation.
2024-09-02 18:47:16.457 SESSION STARTED: SessionEventArgs(session_id=1f5fbe81d5e44fd999adec19ec4d8ffb)
2024-09-02 18:47:18.345 CANCELED: SpeechRecognitionCanceledEventArgs(session_id=1f5fbe81d5e44fd999adec19ec4d8ffb, result=SpeechRecognitionResult(result_id=40be7cc2eb02493095a25bc74c729cb1, text="", reason=ResultReason.Canceled))
2024-09-02 18:47:18.345 CANCELED DETAIL:CancellationDetails(reason=CancellationReason.Error, error_details="Connection failed (no connection to the remote host). Internal error: 1. Error details: Failed with error: WS_OPEN_ERROR_UNDERLYING_IO_OPEN_FAILED
wss://southeastasia.stt.speech.microsoft.com/speech/universal/v2
X-ConnectionId: 1f5fbe81d5e44fd999adec19ec4d8ffb SessionId: 1f5fbe81d5e44fd999adec19ec4d8ffb")
2024-09-02 18:47:18.346 SESSION STOPPED SessionEventArgs(session_id=1f5fbe81d5e44fd999adec19ec4d8ffb)
2024-09-02 18:47:18.346 CLOSING on SessionEventArgs(session_id=1f5fbe81d5e44fd999adec19ec4d8ffb)

业务把wss协议改成ws协议以后，就可以正常访问服务了

同时在Serverless平台以外，直接在该镜像下也是可以正常访问服务的

因此合理怀疑是Serverless平台的python脚本，使用SSL会存在问题

hexo默认的分类页面，每个分类都需要跳转才能到子页面，这样不够一目了然，考虑到当前只有百来篇博文，没必要每个分类单独跳转页面，因此打算自己实现这个功能

从Hexo添加自定义分类菜单项并定制页面布局(简洁版)大致可以知道实现一个模板文件

然后注入js代码例如

1
2
3
4
5
6

hexo.extend.generator.register("test", function (locals) {
  return {
    path: "test/index.html",
    data: "foo",
    layout: ["test"],
  };

就可以达到目的

先后尝试了几种办法，折腾了两天才最终搞定

硬件：

• Switch oled
• 旧卡：128G 闪迪extreme pro（俗称红黑） A2 V30 200MB/S的读取速度，140MB/S的写入速度
• 新卡：512G 闪迪extreme （俗称红金） A2 V30 190MB/S的读取速度，130MB/S的写入速度
• 读卡器：Lexar RW310，支持USB 3.2 Gen1，最高170MB/S的传输速度

软件：

• 引导系统：Switch专用开源引导加载程序Hekate

• 虚拟系统：大气层（Atmosphere）18.1.0

在上一篇实现 HTTP 长连接中，研究了整体实现的方案

初步实现并上线后，相对于原先的短链接用法，整个链路的耗时下降了50%，还是挺有成就感的

在这一篇中着重讨论其中选择连接算法，单独写这一篇是因为在揣摩golang的连接池实现中发现了不符合预期的问题

golang版本如下：

1
2

~ go version
go version go1.21.0 linux/amd64

业务有个需求是为taf的HTTP客户端实现长连接

我5年前在前公司就写过cpp的HTTP连接池版本sheep/HTTP_client实现广告项目的RTB

当初的那个实现很粗糙，凑活用就行，但是现在的这个实现是给全公司人用的，首先摆在面前的问题就是实现HTTP长连接的哪个版本？

个人倾向于1.1版本，对服务端要求低比较通用，最后确实选择了1.1版本，选定了版本随之而来又有这些问题：

• 是否需要实现Pipelining

• 是否需要解析协议上的任何控制字段

• 需要哪些配置字段？默认值是什么？

  例如连接池的默认的空闲连接数量，这种默认设置最怕大佬问到底，为什么设为5？为什么设为10？

  有现有方案就可以直接转移仇恨：为什么golang设为x？为什么nginx设为x？

• 以域名为粒度实现每个域名一个连接池，还是以ip为粒度

  当初是实现了一个基于ip的Client用来实现rpc框架（每个ip单连接多路复用），基于Client又封装了ClientPool给redis, HTTP, mysql用（每个ip连接池）

  现在看着不太对劲，HTTP的长连接应该以域名为粒度吧？

• 稀疏链接问题梳理

  这个放到taf框架的博文里面去了，因为初版不打算为HTTP客户端实现太多功能

现象

某后端服务作为入口网关，同时支持taf协议和http协议访问

taf协议访问量每日定时会变大，因此会进行定时扩容

最近一次定时扩容后，出现了大量ai告警，提示所有的http协议访问耗时都上涨了

最近实在太忙啦，好几个月没写博客了，趁着五一放假补一篇

最近运维同学调整了告警策略，将连续coredump才告警，改成了每次coredump必告警

业务部门顿时向我报障了taf框架的coredump

一开始core在了tcmalloc，因为tcmalloc不会第一时间coredump，所以内存问题会跑一段时间才出现

本周为了Taf框架引入了限流器算法，用于Trace上报时进行限流

早在写go的时候就使用过著名的golang.org/x/time/rate限流器，这是一个令牌桶算法，它允许在保证平均rate的情况下，有一些突发流量

还用过uber开源的github.com/uber-go/ratelimit限流器，这是一个漏桶算法，它能严格的控制每个请求的最小访问间隔，并允许配置一个最大松弛量(maxSlack)用于最大间隔误差

简单介绍下两种算法的大概实现和区别，随后分别深入两种算法的实现

• 令牌桶算法

  由一个令牌桶和生成令牌的间隔时间组成。一开始，令牌桶被填满，然后以固定的速率生成新的令牌，直到桶满为止。当请求进入系统时，需要从桶中删除一个令牌。如果桶是空的（没有令牌可以删除），请求则会被拒绝或等待。

• 漏桶算法

  模拟了一个漏水的桶。进入系统的数据被放入桶中，然后以固定的速率流出。如果桶已满，新到的数据则被丢弃或等待。由于输出的数据流是恒定的，因此可以用于控制数据的整体速率。