0%

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

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

json-schema-validator jsoncons
规范支持 Draft 7 Draft 7,Draft 2019-09,Draft 2020-12
字符串格式检查器 没有预设,都要自己实现 支持date,email,tcp等常见的数十种
外部依赖 C++11起,依赖github.com/nlohmann/json C++20起
更新频率 253 commits,7 months ago 12335 commits,yesterday

总体而言,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服务的

img

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平台的设计原理属于机密,略过不提

阅读全文 »

首先分析一下我所见过的权重负载均衡算法的平滑性缺点,最后着重分析来自Nginx的默认算法:平滑加权轮询算法(Smooth Weighted Round-Robin )

平滑性

首先负载均衡算法的平滑性,我认为包含两个重要特征:

  • 在较大的某个时间窗口内一定会访问某些节点:

    违反这个特征,会导致部分节点的使用率过低

    这可以认为是一种稳定性,稳定的访问有权重的节点

  • 不能太过连续访问某些节点

    违反这个特征,会导致部分节点使用率过高,导致过载

随机负载均衡

阅读全文 »