Weakyon Blog

本周为了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两个模块

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

tcp read < 0问题

在muduo库中，< 0直接被无视，根据https://github.com/chenshuo/muduo/issues/314的回答

read() 如果由于对方 RST 而返回 -1，那么这个 fd 会保持 readable 状态，下一次 read() 会返回 0，然后就走正常关闭连接的流程了。

但是在其他库中 < 0并且排除掉EAGAIN会直接关闭描述符

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

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

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

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

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

Bistro

《Bistro: Scheduling Data-Parallel Jobs Against Live Production Systems》

facebook2015年论文，用于解决离在线混部时，约束离线任务运行在指定资源范围的问题

• 提出了一种基于树模型的资源调度问题

  例如叶子节点是数据库卷，上面的父节点是主机，机架等等

  在任务退出时，对影响到的叶子节点以及父节点（直到根节点）进行调度，来避免全部资源池的调度太过耗费性能

Bistro在架构上允许对树的独立资源的根节点，哈希或者按位置进行分区，从而进行并行调度和分布式调度

我在整理tars和taf的协程逻辑的时候，也实现了一个纯净版的协程框架以便于理解

网络框架

类图

sheep_cpp

看下把tcpconnection改成回调中智能指针是否合理

最近大概间隔1个月，我在使用定时任务类时遇到了两次析构过程中的 bug

这两个 bug 出现在我用别人写的定时任务类时，这两个bug的区别是一个是组合使用的，另一个是继承使用的

由于coredump的堆栈都不在正常的位置，因此这两个bug都花费了我平均一整天的大量时间去定位

另外有个基于协程的定时任务类，这个类不仅只是使用，甚至都是我实现的，尽管 bug 还未发生，我仔细看了下居然也存在类似的问题

因此，我觉得我有必要总结这个问题，避免再次在相同的问题上耗费太多时间，毕竟多线程（协程）问题的定位非常困难

本文续接锁实现分析：从glibc到futex（一）

上一篇对glibc和futex进行了源码分析，是我对具体实现的梳理，没有总结性的内容，可以略过不看直接看这一篇总结

本篇总结尝试深入一些，继续挖掘锁这个概念

分析内核在实现锁的过程中是如何解决无效唤醒问题的

为了解决无效唤醒问题，纯用户态的互斥锁性能不够好；纯内核态又在非竞争的条件时需要陷入内核，从而诞生了futex