fudali
fudali
我使用 公测版本可以使用，修改了商用版本的之后就会报这样子的错误 ``` 172.20.1.142:45936->172.17.102.2:9092: read: connection reset by peer 2018-07-17T04:09:37.366Z INFO kafka/log.go:36 kafka message: client/metadata got error from broker while fetching metadata:%!(EXTRA *net.OpError=read tcp 172.20.1.142:45936->172.17.102.2:9092: read: connection reset by peer)...
## 类 TCP 拥塞控制的普适性自适应限流方案可行性讨论？ 正如 https://github.com/alibaba/Sentinel/issues/1641 中那位兄弟说的一样，在微服务场景，服务多，拓扑复杂，且处理能力不总是稳定；这时候如果使用固定的限流规则会有以下难题： 1. 确定接口和服务的固定配置需要压测工作量(如果你服务接口多，那工作量不可小觑)，同时需要将压测融入到你的开发流程中; 2. 服务处理能力不总是稳定的，不同的服务可能对于同一个资源(比如数据库)有依赖且两者都是使用资源，此时这两个服务实际的处理能力可能是跟我们测试得到的固定值都是有差异的； 所以我也希望找到一种自适应的方式来实现限流，不过我思考的灵感是来自于 TCP 拥塞控制； 基于自适应限流的场景，我认为其实跟 TCP 拥塞控制是非常相似的，同样的对于处理能力未知，同样需要从未知的处理能力中尽可能的提高资源利用率，也同样处理能力不总是稳定(对于某一端)；既然他们有这么多的相似之处，且 TCP 能够利用堵塞控制算法很好的进行工作，那么我相信微服务自适应限流场景下也是可以的。 ### 类 tcp reno 的自适应限流方案 假设我们使用 qps 来作为我们限流的标准； #### 慢启动 类似于目前...
Multiple nodes are supported on the client side, allowing other nodes to be requested when a node is in error.
Expect to be able to get more content when streaming reads the data: such as: - [ ] get cols info - [ ] get row cells attrs - [...
https://github.com/uber-go/zap/blob/845ca51d5b8d9fed9fe14f35ab13b6b160d5762d/zapcore/json_encoder.go#L488 panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x6e42f8] goroutine 25244385 [running]: go.uber.org/zap/zapcore.(*jsonEncoder).safeAddString(0xc0012e5bf0, {0x0, 0x4}) /build/vendor/go.uber.org/zap/zapcore/json_encoder.go:466 +0x58 go.uber.org/zap/zapcore.(*jsonEncoder).AppendString(0xc0012e5bf0, {0x0, 0x4}) /build/vendor/go.uber.org/zap/zapcore/json_encoder.go:267...