业务场景分析

通常业务都有控制预算或疲劳度的需求：

• 预算：每天最多发放N张优惠券、每月最多发放价值1000元的金币，……
• 疲劳度：每小时最多曝光N次，每个用户每天最多展示N次，……
  本质抽象出来，就是属于“限流”中的“计数器模型”，在指定时间段内，请求数量累加，有数量的最大限制。

整体思路分析

一、问题场景

在产品开发，通常会有这样的场景：

• 投放这个特效，用户更愿意购物，还是不投放这个特效，用户更愿意购物？
• 这个按钮用红色，男生用户更愿意点击，还是用绿色，男生用户更愿意点击？
• 优惠券面额满300减30，新用户更愿意下单，还是满100-10，新用户更愿意下单？

问题可以归纳为：为了达成某个目标，有多种方案可以选择时，如何进行决策？
正确的做法是数据驱动，让用户来体验，看他们是用手点赞还是用脚投票，帮助进行决策。

一、社交游戏

简单来说，就是拼多多砍一刀，今日头条极速版签到领金币。
用户付出社交关系，收获一些优惠券、现金奖励；平台付出资金，收获APP渗透率、购物用户、活跃用户、新用户。
场景有很多，比如：

• 签到类：签到换积分，积分换钱券
• 冲关类：多个关卡，冲关完成游戏得奖励，游戏通常需要做一些分享、助力的操作
• 组队类：和好友组队一起玩
• 走路类：走路、按时吃饭、按时睡觉得权益 —— 其实是为了促进活跃用户，让你吃饭睡觉都去看一眼
• 老带新类：老人拉新人，双方都得奖
• 答题类：答题得积分，积分换钱券
• 抽奖类：拉人，互动，定时开奖 —— 比如支付宝扫福瓜分5亿，其实让你加了支付宝好友并互动了

摇一摇功能分2种：

• 单纯的触发机制：拼多多摇一摇更换推荐商品、今日头条摇一摇得红包
• 需要进行匹配：微信摇一摇匹配附近的人，陌陌摇一摇匹配附近的朋友

在接到摇一摇需求的时候需要仔细分析业务需求。如果是第1种，只是单纯的触发机制，要是前端的工作，无论是什么形式，最后都只是一个单纯的请求而已。如果是第2种，就较复杂，需要详细设计匹配算法。

和摇一摇匹配类似的场景还有：滴滴司机乘客匹配、饿了么顾客骑手匹配、王者荣耀游戏匹配。

项目开发中，我们会引入框架、工具类、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就能够瞬间理解，只是换了个参数名字而已。