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

需求分析

1、积分过期的两种场景

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

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

业务场景分析

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

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

整体思路分析

一、问题场景

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

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

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

一、社交游戏

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

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

摇一摇功能分2种：

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

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

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

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

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

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

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

一致性Hash是分布式架构最重要最基础的东西，这里以分布式图片缓存服务器为例进行讲述。

原始问题：假设我们需要对一堆图片做缓存，缓存的图片放在了2台服务器上，当到来一个请求，应该如何知道请求的图片在哪台上面呢？

暴力遍历就不要去想了，否则缓存就没有意义了。一个自然的想法就是根据图片的名字做一个映射（Hash），将图片名字映射到0，1两个数字上面，例如有这样的映射函数：

$$ f(图片名称) = md5(图片名称) \% 2 $$