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

硬件：

• 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)用于最大间隔误差

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

• 令牌桶算法

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

• 漏桶算法

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

维护的项目代码有很多编码不是utf-8的，导致保存会把中文注释变成乱码

不止我一个人遇到这个问题，项目中有很多已经是乱码文件是别人导致的

我研究了一下，把文件用utf-8或者gb2312打开，再转换成gbk繁体，如果转换失败，那基本就是乱码

代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

import os

def check_is_encode_error(string):
    try:
        string.encode('gbk')
    except UnicodeEncodeError:
        return True
    return False

def check_file(filepath):
    try:
        with open(filepath, "r", encoding="utf-8") as file:
            lines = file.readlines()
    except UnicodeDecodeError:
        with open(filepath, "r", encoding="gb2312") as file:
            lines = file.readlines()

    for num, line in enumerate(lines, 1):
        if check_is_encode_error(line):
            print("文件存在乱码 {}:{}".format(filepath, num))

def check_dir(dir):
    for root, dirs, files in os.walk(dir):
        for file in files:
            filepath = os.path.join(root, file)
            try:
                check_file(filepath)
            except:
                pass
                print("文件 {} 检查失败".format(filepath))

# 把"path_to_dir"替换成你要检查的文件夹
check_dir("path_to_dir")

最近的几个系统都用到了定时更新配置

获取到的配置是需要高频使用的，不能直接使用字符串

需要预处理为整数或浮点数，甚至是一个整数数组

因此整理了一下Config设计：

分为元数据Meta，配置的存储和注册Config两个模块

在维护网络库时，总能遇到一些没太大用处，但是很有意思的小知识，细细碎碎又不成体系，记录一下

异步的epoll使用

• 2015.5.22整理：

  epoll下LT和ET的处理都是大致相同的

  • LT模式

    读buff有数据 / 写buff有空间，就触发

  • ET模式

    读buff有数据，且数据减少或调用epoll_mod时 / 写 buff 空间增加或调用epoll_mod时，才触发

  LT模式例子:

  https://www.cnblogs.com/lojunren/p/3856290.html

  https://github.com/hurley25/ANet

  https://juejin.im/post/5ab3c5acf265da2380598efa

  https://www.zhihu.com/question/22840801

  https://blog.codingnow.com/2012/04/mread.html

  在ET模式中，需要主动把数据读完或者写满：

  • 读处理是一直read

    返回-1，检查errno，如果是EAGAIN那么不再读（缓冲区读完），如果是其他那么说明连接出错，进行报错然后也不再读。

    返回0，说明对端关闭

    返回大于0，成功读到数据

  • 写处理是一直write，直到数据写完

    返回-1，检查errno，如果是EAGAIN那么不再写（缓冲区写完），如果是其他那么说明连接出错，进行报错然后也不再写。

    返回大于0，成功写数据

在使用tcp时，内核的tcp上存在读写缓冲区，上层app通过这个缓冲区来和实际的网络进行通信

app <=> 内核tcp <=> network

本文主要讲述了Borg论文中引用的基于机会成本的E-PVM算法

这个算法的缺点（大型任务难以调度）是在我的场景下是可接受的

对Borg来说，任务实际是一个任务组，亲和需求的任务组需要特别多的资源

而在我的调度问题中，大型任务是很少的，因为我的调度器不提供任务组的概念，由业务来解耦任务组

我尝试理解该算法后做一些优化，然后通过模拟器模拟和分集群测试来查看是否可以提升资源利用率