昨晚又整ssh配置整了半天，记不清楚是第几次踩坑了，还是需要整理一下问题的处理思路

docker配置

我是在docker上操作的，首先在https://hub.docker.com/search?q=gcc5&type=image找到想要的镜像，然后拉镜像运行（https://github.com/dongyubin/DockerHub看下可用的代理）

1
2

~ docker pull proxy.vvvv.ee/conanio/gcc5
~ docker run -it -p2222:22 proxy.vvvv.ee/conanio/gcc5 /bin/bash

随后登陆安装ssh基础依赖

最近框架接json schema的需求，因此对其进行了调研

star最多的两个库https://github.com/pboettch/json-schema-validator和https://github.com/danielaparker/jsoncons（已完成）

总体而言，jsoncons会更好（规范支持全面，功能多，更新频率高），但是接入难度更高（依赖C++20，框架要兼容C++11的钉子户用户）

json-schema-validator基本功能都有，凑活够用，所以还是先接入json-schema-validator，对其进行源码分析

当前的一致性哈希存在四个bug，分别进行分析

以这个版本https://git.huya.com/server_arch/taf/-/blob/924950284557f183bd025ed758dc2e878ae36938/src/libservant/EndpointManager.cpp#L2448为例

我新增了部分日志，总体流程的关键代码在getConHashProxyForNormal

他的输入是hashCode（也就是prx->taf_consistent_hash(hashCode)传入的），输出是本次负载均衡选出的节点指针

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

AdapterProxyPtr EndpointManager::getConHashProxyForNormal(int64_t hashCode)
{
    //_vLastConHashProxys是上一次更新一致性哈希时记下的节点
    //checkConHashChange中如果当前节点和上一次的有变化，那么返回true
    if(checkConHashChange(false, _vLastConHashProxys)) {

        //根据当前节点，把数据写入到_consistentHash
        updateConHashProxyWeighted(true, _vLastConHashProxys, _consistentHash);
    }
    LOG_INFO << "[TAF][EndpointManager::getConHashProxyForNormal _sObjName:"
             << _sObjName
             << "|_consistentHash.size():" << _consistentHash.size() << endl;

    if(_consistentHash.size() > 0) {
        //根据_consistentHash数据一致性哈希选节点
        ...

        //没选出来，返回空
        return nullptr;
    }
    //_consistentHash是空的，降级到普通hash

    return getHashProxyForNormal(hashCode);
}

在Serverless平台的研发过程中，意外在python的import问题上踩坑了

大概还是对python的包管理基本原理不够了解，首先对python的包管理机制做一个总结，然后分析这一次踩坑的问题

python的包管理

Import基本语法

Python 中 import 有四种常见语法形式：

前文分析了一波锁的原理：

并实现了协程下的锁：

距离上一篇记录过载保护的文章再看过载保护，已经过去有6年多了，回看那一篇文章，未免显得青涩，大部分都是错误的

文章核心理论集中在“控制任务队列长度”来规避过载，根据压测得出过载根因：并发上升 → 任务队列长度剧增 → 资源占用加剧 → 响应时间线性增加

看似没啥问题，但是压测是基于grpc服务和net/http服务的

net/http服务显然没有队列概念。grpc也没有内置队列，它主要依赖 HTTP/2 多路复用，在收到请求后就会启动相应的 Goroutine 进行处理

继上一篇实现HTTP长连接的HTTP/1.1连接池实现已经过去半年

这一段时间发现了HTTP/1.1连接池无法解决的致命缺点：

在突发高并发场景下，客户端由于需要额外建连很容易退化成短连接

• 在超高突增并发下和短链接几乎无异，我司由于业务特性就是这种情况

• 即使突增并发不高，只要并发持续增长超过一定比例后，由于新建连接的tcp握手+ssl握手需要耗费大量的cpu，造成客户端和服务端的cpu不稳定，叠加新建连接的tcp慢启动因素带来了更多的超时。

  而HTTP/1.1一旦超时就需要断开连接重新建连，更多的建连带来了更多的超时，又带来了更多的建连，就造成了雪崩效应

HTTP/1.1压测

本文整理一下遇到的编译问题，最常见的就是编译时缺符号，重定义

但是一般来说cmake生成的make语句会隐藏实际的gcc语句，如果手写的makefile，也有可能是目标规则没配置正确

make的debug

• 查看实际的gcc语句

  • 特殊命令

    VERBOSE = 1或者V=1，主要看makefile怎么写的，一般都能用

  • 通用的

    make -n

    实际上是只输出make试图运行的指令

• 查看目标规则情况

  make -d

  将打印 Make 为每个目标尝试的所有规则（包括内置规则）

单步编译链接语句debug

最近业务报障，使用taf框架编译成动态库，从3.4.5.8-notrace版本换成3.4.6.0-notcmalloc版本后

dlopen打开动态库报错cannot allocate memory in static TLS block，业务认为是不带tcmalloc导致的

我的最终结论是taf框架的动态库编译强制开启了静态TLS，这个线程私有变量区是存在上限的，trace代码有超大的线程私有变量，导致dlopen失败

总结了一下何时会开启静态TLS，并且如何解决

初步定位并解决问题

截止25年1月12日，打算使用dlmopen来装载serverless平台第三方动态库的计划，在挣扎了2周后正式宣布破产

总的来说dlmopen虽然已经有几十年历史了，但是在当前还是非常不成熟的，有很多细节问题没有解决

想用上dlmopen，需要深入理解glibc的实现原理，和patches的可能bug斗智斗勇，这个投入产出比很低

背景

serverless平台的设计原理属于机密，略过不提