go-kratos/aegis

Service Reliability Algorithm

aegis's Issues

pointer arithmetic result points to invalid allocation in the murmur

fatal error: checkptr: pointer arithmetic result points to invalid allocation

goroutine 27808 [running]:
runtime.throw({0x6a7beb7?, 0x18cd719?})
	GOROOT/src/runtime/panic.go:1047 +0x5d fp=0xc0037a2e28 sp=0xc0037a2df8 pc=0x1893bfd
runtime.checkptrArithmetic(0xc007c31980?, {0x0, 0x0, 0xc0037a2eb0?})
	GOROOT/src/runtime/checkptr.go:69 +0xaa fp=0xc0037a2e58 sp=0xc0037a2e28 pc=0x185e52a
github.com/spaolacci/murmur3.Sum32WithSeed({0xc007c31980, 0x40, 0x40}, 0x0)
	external/com_github_spaolacci_murmur3/murmur32.go:129 +0x90 fp=0xc0037a2ec0 sp=0xc0037a2e58 pc=0x53f2290
github.com/spaolacci/murmur3.Sum32(...)
	external/com_github_spaolacci_murmur3/murmur32.go:111
github.com/pingcap/tidb/util/topk.(*HeavyKeeper).Add(0xc00070b320, {0xc007c318c0, 0x40}, 0x1)

lastAppendTime设置可能会延迟

func (r *RollingPolicy) apply(f func(offset int, val float64), val float64)
这里如果timespan超过了r.size，会导致r.lastAppendTime设置的时间不对。 下面是修改过的代码

func (r *RollingPolicy) apply(f func(offset int, val float64), val float64) {
	r.mu.Lock()
	defer r.mu.Unlock()

	// calculate current offset
	rawtimespan := r.timespan()
	if rawtimespan > 0 {
		start := (r.offset + 1) % r.size
		end := (r.offset + timespan) % r.size
                timespan := rawtimespan
		if rawtimespan > r.size {
			timespan = r.size
		}
		// reset the expired buckets
		r.window.ResetBuckets(start, timespan)
		r.offset = end
		r.lastAppendTime = r.lastAppendTime.Add(time.Duration(rawtimespan * int(r.bucketDuration)))
	}
	f(r.offset, val)
}

Limiter 接口 Allow() 方法是否考虑传入 ctx 和 req

package ratelimit

// Limiter is a rate limiter.
type Limiter interface {
	Allow() (DoneFunc, error)
}

如果不使用默认的 bbr 实现，想要额外拓展一些更细粒度的限流，不传请求信息进去什么都搞不了，这个接口基本没有拓展性。

类似这样：

// Limiter is a rate limiter.
type Limiter interface {
	Allow(ctx context.Context, req interface{}) (DoneFunc, error)
}

window.Bucket为什么不直接使用数值类型统计

type Bucket struct {
Points []float64 // 这里为什么要用切片类型呢？
Count int64
next *Bucket
}

Points 如果定义为数值类型会有什么坏处吗？看源码里也只使用Points[0]，这样的话为什么不直接用数值类型呢？

[BUG] Invalid number of arguments?

aegis/pkg/window/policy.go

Lines 72 to 75 in 9c51406

	// Append appends the given points to the window.
	func (r *RollingPolicy) Append(val float64) {
	r.apply(r.window.Append, val)
	}

aegis/pkg/window/window.go

Lines 77 to 80 in 9c51406

	// Append appends the given value to the bucket where index equals the given offset.
	func (w *Window) Append(offset int, val float64) {
	w.buckets[offset%w.size].Append(val)
	}

Is offset ignored by mistake?

minRT in bbr may be wrong

aegis/ratelimit/bbr/bbr.go

Line 219 in 56c0fb5

avg := total / float64(bucket.Count)

If you want to count the avg of single window with all points, you should use this:

avg := total / float64(len(bucket.Points))

bbr 限流算法部分为什么没有排空逻辑？

请教一下作者，基于各种 BBR 算法的解读，例如：

https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653559260&idx=1&sn=e85e278bb9087bcc916bfeab3067722c&chksm=81398844b64e0152d9203fa2b07554103f10ad7ae06294d33690e24ae1a3a549b0a563b4fe0c&mpshare=1&scene=1&srcid=0418epQjBTzDuvNWvlcMp0ut&sharer_sharetime=1650250406712&sharer_shareid=34f63cba45f97d50bbe8eef748292b0f&exportkey=AYKbFrlRY8d18O499Po0yAM%3D&acctmode=0&pass_ticket=%2FUnoSPXpIinbq1XhvooqpCHuupnPE2%2B%2FKYq%2FAX%2B6gqNn9stumLxdyXtYrkTpCv03&wx_header=0#rd

想要探测 minRt 就要有排空阶段，排空就是要限制并发数，但在这里的 bbr 实现 里并没有看到相关逻辑。

breaker&limiter api definition

type Warden interface {
    // 开始保护一段代码逻辑或者一次RPC Invoke
    Ward(ctx context.Context, opts ...Options) (Done, error)
}

// 结束的时候传入error、bytes send、bytes recevied等信息
type Done func(err error, opts ...DoneOptions)



type Option func(*options)


type DoneOption  func(*doneOptions)

直接用CPU的值做判断

Kata 容器中获取的CPU Limit 值错误

环境：阿X云Serverless Kubernetes（ASK）集群，底层使用基于Kata的安全沙箱容器。

问题：测试发现默认会使用 cgroup 方式来采集 CPU Limit，Kata 好像是类似于虚拟机的，没用 cgroup，无法采集。
然后调整代码直接用 psutil 来采集信息也对不上，比如限制 cpu 0.5核，实际会给两核，每核只能用0.25。psutil 采集的也是两核，导致限流失效。

猜测：不确定是 Kata 无法采集还是阿X云底层实现不同导致的，对这些不怎么了解。

临时方案：限制是通过 k8s downwardapi 把具体资源限制注入到容器中，然后修改了相关代码，把 CPU Limit 直接设置给 limiter，而不是自动获取

有必要添加这么一个 options 来手动设置 cpu limit 嘛？

bbr限流实现 maxInFlight 方法可能有误

aegis/ratelimit/bbr/bbr.go

Line 235 in 56c0fb5

return int64(math.Floor(float64(l.maxPASS()*l.minRT()*l.bucketPerSecond)/1000.0) + 0.5)

最后加的那个0.5是不是放错位置了。Floor函数返回的已经是一个整数值，在加 0.5 后，会被最外层的 int64() 截断吧

[feature] Support defining startup threshold through inteface

Background:
I plan to use the API average RT (response time) or P95 RT as the adaptive current limiting startup threshold. But the current code design makes it difficult for me to implement this function.

My thoughts:
By defining the startup threshold interface, and supporting passing in limiter during initialization.

e.x.

type StartupThreshold interface {
	Reach()
}


func (l *BBR) shouldDrop() bool {
	now := time.Duration(time.Now().UnixNano())
        // 
	if ! l.StartupThreshold.Reach() {
		// do sth when not reach threshold 
	}
	// do sth when reach threshold 
        // drop ...

}