讨论中总结的一针见血的话

1. 因为消耗桶内令牌的速度是不受限制的，可以快速消耗完，这也是为什么高并发的请求可以得到及时的处理。

而漏桶如果1秒消费10个，在100ms来了10个的时候，只能处理1个，其他9个只能丢弃或者等待。

2. 二者的共同点就是单位时间1s内处理包的数量都是一样。

--zk缺点

事件广播风暴， docker的 cpu特别高， dump下来有很多heavy的线程

一万台机器有一点网络抖动，通知风暴特别多，

ZK有个隐式的版本，否则不知道数据新旧，直接把有效值覆盖了~ 

--

赋值的时候无脑赋值，会造成覆盖已存在的值。

Lua可以解决赋空的时候判断一下是否存在值。

就像SQL代码，更新时候where条件加非空判断。

--

Q1：浩哥说乐观锁幂等。 number+1

         where条件得明确

Q2：要幂等   防重

Q3：内嵌变量  + 号分割变量

---

Q1:HashMap不允许Key值重复 {}

                     允许为空。  {ThreadLocal的内存泄漏}

                      线程不安全。

   > 一般常用的使用properties中的配置的值的方式有两大类 : 1. 在XML中使用${"mykey"} ; 2. 在代码中使用@Value 注解 : @Value("${myKey}")

Q2:Spring aop

  动态代理。可指定cglib

Q3:jdbc 适配器模式

Q4：nginx  限制ip的命令

    limit_req   limit_conn

Q5: 集中限流策略

    ip防刷、pin限流、增量限流、百分比限流、LimitRate（guava）

Q6：闭锁 屏障

   前者等时机。后者等其他线程

--

Q1：为什么redis单线程

单线程天生数据安全的。 -欢亮

单个线程-单核cpu绑定一块内存，效率最高。

多线程上下文切换耗时。 

方案：1个docker 起多个redis进程。

Q2：redis底层编码

LIST列表对象： 压缩列表和双端链表。 阈值是64字节长度，512个元素数量。

SET集合对象： 压缩列表 和 跳跃表。

字典结构：hash。 

双向链表 list，压缩列表ziplist，skiplist

跳跃表：结合链表的插入优点和二叉树的遍历优点，不断加一个柱子。。多层柱子，好几层。

Q2：redis rehash

当发现超过80%了，就重新开辟一块2倍空间，查询时先查新的，在查老的。反写回新的。完成重hash

Q2：信号量 和  闭锁 区别

信号量是资源保护

闭锁做线程间同步

场景不同

Q3：连环炮

zk                 

redis setNX （性能不好）

lua+redis      （组合操作原子化）

Q4: redis 的 scan命令，如同分页一样。

      一致性hash算法使用场景重要，不能乱用。

      分裂。

---算法

Q1：堆排序，5次登顶。找前5

         判断链表有环。1个1倍数1个两倍数跑，相交折有环。

         链表逆序。     3个指针法。

Q2：一个字符串最长重复子串。 

    双指针法。i和j之间的数保持相同。 j继续后移。

                     i和j之间的位置推入结果数组。追上。 i j 只前进不后退

--同时更新丢失问题

1、一锁二判三更新  口诀 解决多线程多事务下更新丢失问题

2、先find （version）

     若null，则insert，出现异常待会儿重试【出了异常，做反查，查的数据是脏的，还是事务开始的初期快照，不能用来做update】

    若nonnull，则update，出现异常待会儿重试（version=oldversion）

   

-----

Q1 有限状态机判断。

只有一个主循环。

Game -》 地图 =》砖块 

归并

----

先全局一遍

---

头插法:就是说新来的值会取代原有的值,原有的值就顺推到链表中去,

HashMap的线程不安全主要是发生在扩容函数中，即根源是在transfer数据迁移函数中