项目开发中，我们会引入框架、工具类、SDK等依赖，这些依赖的包也会有依赖，层层嵌套。一个比较关键的问题是，如果不同依赖，都引用相同的一个底层依赖，但是是不同版本，就会出现引用冲突。
如下图，一个项目引入了Diamond 2.3.4、HSF 1.2.3、FastJson 1.2.0共3个组件。Diamond组件引入FastJson 1.1.0，HSF组件引入FastJson 1.0.0。当我们使用com.alibaba.fastjson.JSON.toJSONString(data)方法的时候，到底调用的是FastJson 1.0.0的方法、FastJson 1.1.0的方法，还是FastJson 1.2.0的方法呢？
之前分析了定时任务的数据结构演进，其中终极方案就是kafka的分层时间轮。现在实际编写一下kakfa的分层时间轮，并分析数据。
代码部分，直接按kafka 0.11.0版本进行编写，给关键语句都加了自己的注释。
| java | scala |
|---|---|
| Poller | kafka.utils.timer.TimerTest |
| SystemTimer | kafka.utils.timer.SystemTimer(Timer里) |
| Timer | kafka.utils.timer.Timer(trait Timer) |
| TimerTask | kafka.utils.timer.TimerTask(trait TimerTask) |
| TimerTaskEntry | kafka.utils.timer.TimerTaskEntry(TimerTaskList里) |
| TimerTaskList | kafka.utils.timer.TimerTaskList |
| TimingWheel | kafka.utils.timer.TimingWheel |
穿越平行宇宙
迈克思·泰格马克 / 汪婕舒译
ISBN: 9787213079801
《穿越平行宇宙》作者是MIT物理系终身教授，他从宇宙学角度回答了很多令人难以理解的问题，其中包括了一些量子相关的问题，但世界观更加宏大。提出了“数学宇宙”假说，用奇特的角度来描述量子现象，值得记录下来。
在很多业务场景下，都需要定时任务，比如”定时推送消息”、”定时计算报表”、”定时清理数据”等等。通常业务都是集群化的，定时任务通常不能每个机器单机执行，需要有个分布式协调器感知到集群，然后选中1台机器执行，所以出现了很多定时任务平台帮助处理定时任务。
定时任务有个核心的问题：如何知道时间到了？
JMQTT是cicizz在2019年开始开源的项目，当时我们公司刚好在做IoT的东西，需要一个Java语言的MQTT Broker，但是当时物联网刚刚兴起，别说Java写的了，就是其他语言写的，也就只有emqtt（现改名EMQX）算是能用的，其他的如古早的mosquitto都是玩具项目。所以JMQTT1.x是很厉害的，也是我参考了很多的项目。
我参与了JMQTT初期的一些开发，不过现在JMQTT已经发展到3.x版本了，被改了很多东西，如为了支持MQTT5增加了hivemq-client，为了优化集群增加了akka，然后增加了一些UI界面等，还有一些老代码的兼容。个人认为新版的代码已经很乱了，比如MQTT3是用Netty直接写的，MQTT5又用hivemq间接地用Netty，这种就很难管理。
MqttWk可以算作开源MQTT Broker中的教科书，代码简洁易懂，虽然并不适合生产，但对照着MQTT白皮书的每个功能，都能在里面找到基本的实现，能够对Broker有个非常全面的认知以及有了兜底方案的底气（实在写不出，按这个思路先上生产也行，能用就行）。
作者wizzer其实是为了推广他写的Nutz，把MqttWk当作Nutz的一个应用场景来写的。Nutz/NutzBoot就是国产版Spring/Springboot，作者除了实现IoC、AOP等基本功能，还做了一些国内公司喜欢的小优化。在MqttWk中大量出现Nutz的代码，不过不必担心，只要会Spring就能够瞬间理解，只是换了个参数名字而已。
本文将浅析论文原文，对论文中一笔带过的重要逻辑，或者难以理解的地方进行详述，有助于定性地理解论文描述的模型。
本文根据阿里开源的JetCache和大佬同事用kotlin写的MutilCacheManager两个框架，来分析二级缓存应该如何设计。
我们一般的缓存有2种用法：
二级缓存通常是指：为了获取查询耗时较长的数据，以本地缓存+远程统一存储缓存，构建的两个层级的缓存。
