想到以前加过的一个 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 这个是配合监控，人工计算再配置吧。我说的自适应算法是把这个过程程序化自动化。

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

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

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

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

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

@zcbenz 我觉得更痛苦的是，别人乱改自己的设计。为抢功改一些他以为‘’没关系’的点，然后他还是领导，要你按他的设计实现。

@hyrepo 谢谢!英语不好，这个没用过。去看看。

@letitbesqzr 首先营养跟不上。政治的偏向太明显，看不进去。其他有推荐的吗？

@Foxkeh 我们也是 从 4 月份开始 第一次实行大小周。。。 感觉今年部门管理上越来越大胆，不怎么考虑员工的意愿了。
ps：周六有下午茶（弥补措施），这次 51 加班也有，刚刚参加。。一些水果、切块盒装，还有泡面、几样零食。pps 吃泡面的不少。。。

我的理解就是#7 说的：最终一致性就是没有一致性。
首先，最终一致性是基于一致性概念衍生的。本来一致是一个原子的概念，一致=没有分歧，没有说部分一致的。
在分布式场景下，一致代价太大。基于 cap，为了 a，只能放弃 c，但业务场景又不能完全放弃。然后就想办法把 c 分级了，就是一致性模型。然后把一致 改名为强一致了。其它的一致性模型都是部分一致的（就是不一致）甚至完全没有一致性保证。其中“如果经过一段时间后要求能访问到更新后的数据，则是最终一致性”（引用自 http://www.blogjava.net/hello-yun/archive/2012/04/16/376744.html ）。
一致性模型中，基于读写及它们的开始时间结束时间，及它们的进程关系这些要素来定义约束，命名一致性模型。非强一致性的模型都只能保证部分一致。无保证的场景就说是最终一致的（可以基于超时额外增加验证补偿机制）。
最终一致性只是部分一致性的一个美化的名字。把不一致说的好像是一致的。不知道是为了忽悠谁。

分布式事务的一致性还是事务的一致性，即业务层面定义的一致性。分布式事务相对与单机事务的难点是：因通信不稳定，参与事务的各个‘进程’如何对状态达成一致。这是个共识问题。
至于 CAP，通常网络 P 很可能发生，无法避免（看到有人说谷歌自建网络非常稳定，不会出现 P ）。所以只能在 CA 上做权衡，C 强一点，A 就弱一点。CA 好像是某个概念（延迟？）的一体两面。建议参考 jepsen.io/consistency，https://www.zhihu.com/people/zhangshuai89/posts

@hengyunabc
‘具备强烈的技术好奇心，专注微服务、服务网格、分布式消息队列、NewSQL 、大数据、流计算等领域至少 3 年’

楼主经历没有这个也可以吗？非 985 也没有这个经历的有机会吗？

@Aresxue 额（︶︿︶）=凸

我说的就是 hash tree 。刚刚搜了下，已经有这种数据结构了。

@Aresxue 是的，问题还很多。你问的问题，有一些不成熟的思路。我初始想法是把现有的 ConcurrentHashMap 中的红黑树（链表不需要）在某些情况下换成 ConcurrentHashMap （ hash 攻击不在情况内）。

我希望分层是基于密度分布的。也就是基于 hash 的分布而分布。关于分多少层和在哪里分层都应该是基于分布比例来。就像 28 法则里面的 2 可能还适用 28 法则也可能不适应了。基于单个 bin 中数量与整体容量的比例来估算。

hash 有 32 位，值范围 1<<32 。假设 table 的长度 32，容量 24.假设 24 个中有 8-12 个落在一个 bin.通过统计同一个 bin 中 27 个位的分布，取其中分布最均匀的 4 位 hash 到一个长度 16 的 table 。（分布均匀度计算方法：如指定位 1 的比例；如第 7 位 1 与 0 一样多，这个位分布就比较均匀。应该有好的数学算法）。

假如容量 24 已经满了后，又插入一个，这个时候应该扩容了。该扩容 32 的表还是 16 的表？

如果新插入的落入了 16 的表，而 16 的表容量 12 还没满的话，应该不用扩容。如果 16 的表容量 12 已满的话，应该扩容 16 的表。

如果新插入没有落入 16 的表。应该技术除了 16 的表的负载，方便起见可以把 16 的表的负载排除在 32 的表之外。如 16 的表中有 12 个，32 的表中有 12 个，则 32 的表的负载为 12/32 或 13/32.

也就是说对于在哪里扩容的问题，把 bin 是 map 的负载排除计算容量，来决定 table 是否要扩容。有个问题，主 table 扩容后子 table 怎么办？

对于分层，是根据单个 bin 占重容量的比例或者 8 个以上就用子 table （与前面按密度分配矛盾）？（衡量标准是计算用子 table 的优缺点）；

上面只是记录些我的思路，写的不清不楚（本来也没想清楚）。打扰见谅，可以不用回复。

@Aresxue 是的

我是希望能通过分层 Hash 来解决这个问题。并不是依赖实现 hash 碰撞率极低的算法。

如在现有实现下，假设是 len=32 的 table 。当 hash 碰撞时，说明 hash 后面 5 位是相同的。如果 bin 再通过 hash 另外的 27 位，均匀分布的概率相比 32 位时应该会更大。

而且（我感觉很矛盾） 32 位时用 HashMap 平衡时间与空间，为何里面的 bin 不能用 HashMap，而用链表或红黑树？

@yeqizhang 我没有装 jdk7，看了下网上的文章及文中贴出的关键代码 transfer 方法。下面是我根据文章的理解。

关键代码 e.next = newTable[i]; newTable[i] = e;

transfer 中 table 是共享的，transfer 中只修改了 table 中 node 的 next 。next 会指向 newTable，newTable 也 可能 会通过 next 传播到线程外。

说可能是因为 线程 A 对 next 的修改不知道什么时候传播到线程 B 。线程 B 读到的 next 指向原来的 node，也可能指向线程 A 中 newTable 的 node 。

假设 table 中有一个 bin 是 a->b->c->null 。正常情况下，单线程 A 会把这个 bin 移到 newTable，变成 c->b->a->null 。

多线程情况下。线程 A 遍历到 b 了，产生的新链是 b->a->null 。

线程 B 开始遍历，这个时候线程 A 的修改还没传播到线程 B，所以线程 B 还是按 a->b->c->null 遍历。

当线程 B 移完了 a，新链是 a->null 。开始移 b 的时候，线程 A 的修改传播到线程 B 了，这时线程 B 就会按 b->a->null 遍历。

线程 B 按 b->a->null 遍历到 a 后，产生的新链就是 a->b->a 。这个就是环了。

即，正常按 a->b->c->null 遍历，翻转成 c->b->a->null ；多线程情况下，遍历到 b 时，变成按 a->b->a->null 遍历了。翻转的结果就是 a->b->a 了。

总结

单线程情况下 链表翻转了。多线程情况下，前面的线程正常翻转，后面的线程翻转到半途中链表已经变成了翻转后的，这时再翻转就是回头路了。

@Hurriance 链表也可以不加锁，如链表本身就是线程安全的。但这样得不偿失。

我说不需要加锁是从 ConcurrentHashMap 提供的接口语义看，key 之间没有关系，更新锁定 key 就可以了。

@iEverX
但实际用的链表导致 key 之间有关系，维护起来需要锁。如果某些情况（ hash 碰撞但不完全相同）改用 ConcurrentHashMap 代替链表保存数据是不是有#4 说的更好的效果。

与数组是不同的，这个按 hash 分布的密度分布分配空间，不均匀分布。数组按 hash 范围分配空间，均匀分布。我假设是说明一个可以优化的场景，就像链表长度到 8 转红黑树，我的意思是说 hash 不完全相同转 map 。