假设应用1给应用2提供了一个接口，需要更新参数，将Map变为List<Map>，很容易写出这样的兼容代码：

1
2
3
4
5
6
7
8
9
10
11

@Data
public static class OldClass {
    private Map<String, String> bbbb;
}

@Data
public static class NewClass {
    private List<Map<String,String>> aaaa;
    @Deprecated
    private Map<String, String> bbbb;
}

然而在部署后发现，应用2拿到的数据对象中的bbbb，没有任何数据。

很多产品都会有积分系统：用户通过一定的行为累积积分，积分可以兑换各种权益，积分可能
会有增加（获取）、扣减（消耗）、查询余额、查看历史、过期、冻结等行为。

需求分析

1、积分过期的两种场景

积分过期是一种很常见的产品功能，因为一般都不希望用户累计大量积分，造成预算不可控。
过期有2种方式：

• 统一时间过期：比如今年所有获得的积分，都在今年年末过期
• 单笔时间过期：比如“A渠道获取的积分，3个月后过期”、“B渠道获取的积分，7天后过期”。

业务场景分析

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

• 预算：每天最多发放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版本进行编写，给关键语句都加了自己的注释。

在很多业务场景下，都需要定时任务，比如”定时推送消息”、”定时计算报表”、”定时清理数据”等等。通常业务都是集群化的，定时任务通常不能每个机器单机执行，需要有个分布式协调器感知到集群，然后选中1台机器执行，所以出现了很多定时任务平台帮助处理定时任务。

定时任务有个核心的问题：如何知道时间到了？

本文根据阿里开源的JetCache和大佬同事用kotlin写的MutilCacheManager两个框架，来分析二级缓存应该如何设计。

我们一般的缓存有2种用法：

1. 纯缓存。例如预算加减、分布式锁、配置信息。
2. 多级缓存+数据库/外部接口调用。一般一级或者二级就够用了。

二级缓存通常是指：为了获取查询耗时较长的数据，以本地缓存+远程统一存储缓存，构建的两个层级的缓存。