/dev/fd/ran

嗯, 好, 在我看来, 意思就是利用 WebSocket 在 **客户端浏览器** 构造出 HTTP 请求格式的帧, 因为都是基于 TCP 之上的, 经过缓存服务器时, 这些服务器有可能就把这个帧作为 HTTP 请求来对待, 存在潜在的安全隐患. (mask 这里就是防止你构造出预想的数据格式(HTTP 报文), 以便缓存服务器能够 pass 这些伪造的 HTTP 报文). 原文在这里: https://tools.ietf.org/html/rfc6455#section-10.3 过了好久了, 如果我的解释不合理请一定告诉我,...

第一部分: https://github.com/abbshr/abbshr.github.io/issues/51

@fuhaibo 肯定要集群化调度器. 我测试时是在一台机器上, 调度器和工作进程都是拿共享内存交换数据的所以调度那边并没有什么压力. 但你所说几十个节点肯定是部署在不同主机上的进程. 通过网络搜集大量工作进程的信息, 如果只是一个调度器, load肯定会高(主要是连接量, 计算量是次要的), 但是每个节点本地部署一个调度器, 他们的压力都不大, 这样部署层级结构的调度集群, 本地调度器作为agent, 跟上级调度器交换信息, 降低每个调度器的连接数和计算量. 但这样做蛋疼之处一是要把配额分配算法并行化, 二是要考虑时延问题(同步变慢导致配额失效)...

@fuhaibo 我觉得其实都是一个道理, 理论上层级结构调度器也相当于共享cache的server, 也变相的维护一个共享cache, 至于实际效果如何看具体场景, 我也不好说~~

@fuhaibo 恩, 只知道threshold*factor, 不分配threshold. 调度器检查到~~有节点临界~~请求量临界threshold才开始分配总配额. 如果统计期间请求量超threshold*factor, 总配额直接清零, 直到下一个重置周期.

@fuhaibo 不是精确限制, 允许超量存在.

@fuhaibo 对于一个分布式系统来说, 性能(可用性)和一致性肯定二选一了, 绝对精准的限流要以牺牲整体性能为代价, 或者是允许一定范围内的误差, 这个范围怎么定, 要求是否严格, 要看限流算法怎么做. 当前讨论这种限流做法是有这个问题的, (因为是想讨论弹性配额这种架构,当然具体限流算法是架构无关的), 如果需要细粒度控制, 可以用滑动窗口算法精准限流(对单节点绝对严格控制请求量).

@zouzls 好! 我会继续学习

@cosmtrek 行不改名坐不改姓 ---> Keynote 是也

@zhuima oh, my fault.. 我把项目名字改了.. https://github.com/upyun-dev/deploy https://github.com/upyun-dev/rollback