22yune

我也复现了

感谢

想到以前加过的一个 QQ 群。里面都是奇葩。大家可以搜 simviso 。

@Jooooooooo
@thedrwu
@thevita
其实想要一个 高效的 有序列表的 变动 叠加算法。举例：初始列表 A=[1,2,3,4,5,6]，基于 A 把 2 删除了生成一个新列表 B=[1,3,4,5,6]，基于 B 又在第 5 位后新增了个 7 生成新列表 C=[1,3,4,5,6,7]。初始列表 A 又发生了变动，在第 5 位后新增了 8 ，A=[1,2,3,4,5,8,6].这个时候 B=[1,3,4,5,8,6]，C=[1,3,4,5,8,6,7].

因为 A 是非常大的列表，B ，和 C 相对 A 的变动很少，A 本身的变动也不多。我想要一个算法保存 ABC 相对于初始 A 的变动，ABC 的最终视图，可以通过变动+初始 A 经过少量计算得出。ABC 主要使用场景是分页查询。

@mawerss1 比如聚合接口最大响应时间 3 秒，正常响应时间 90%以上是 500ms 以下。假设最大线程数能到 1000 。那请求在队列中等待 2.5 秒是很可能会正常响应的。2.5 秒可以执行完成 5 个批次，队列可以缓存 5 * 1000 个请求，再大的队列就没用了。但初始核心线程可能是 100 。在队列满之后要等 25 才能消费完，这就是因线程增长太慢导致的。如果线程能随着队列排队增长而增长，则加入队列的都是可能正常响应的。在流量达到真正的负载上线时都不会失败。

@546L5LiK6ZOt 设置大了也会导致前面的线程应超时销毁，后面的请求又一直创建线程。这样的结果就是线程池基本没有用，线程一直在创建新的。
@nl101531 是的 大一点没有问题，但也只能稍微改善一点点，当流量大了后还是回到 要等待队列满还是小队列 快速拒绝的选择。
@lidlesseye11 是的，这可能是更简单健壮的算法：按队列增长比例增长核心数到最大数。
@mawerss1 直接拒绝执行就是设置小队列策略了。我现在就用这个设置。觉得还有点不够尽善尽美，没有用上队列的缓冲能力。一些小流量波动或网络波动或下游服务响应慢一点就会产生大量报警，这个时候并不需要加机器。

@guaguaguaxia1 这个是配合监控，人工计算再配置吧。我说的自适应算法是把这个过程程序化自动化。

感觉我跟楼主一类人。。。有类似的想法，但没有清晰完整的架构实现方案，所以没楼主自信。
但是从这个帖子来看，我并不看好楼主。
最后！加油！真弄出来了就牛掰了

首先，楼主文章写的蛮好的；

其次，下面喷的也有道理。

希望大家发言都能尽量友善点。

对于被评论的人，可以想一下，没有人针对谁，大家评论的是言论展示出的观点、态度或什么特质。不需要有被冒犯的感觉。