背景
最近对 Redis 有兴趣，故使用 Redis 来保存临时信息。
我们把业务关系简单地理解为：邀请、扫码、领券、设置偏好，直到登录系统成功为止。
本文所指的二维码，就是URL的一种变换。以邀请扫码页为例，URL：http://example.com/onepage.html?bid=$bid&sn=$sn。
扫码领券设置偏好
| B（Broker经纪人） | C（客户） | S（服务端） | 备注 |
|---|---|---|---|
| - | - | - | - |
| 出示二维码（B生成：Bid+Sn） | 扫B码，跳转到领券页 | - | - |
| 轮询S端BidSn | BidSn存到S | 接受轮询&存BidSn | 接口7&8 |
| 设置C偏好，BidSnPref存到S | 输入手机号，BidSnPhone存到S | 存手机号&存C偏好 | 接口8&9 |
BidSn是一个线索，保存手机号、保存C偏好这两个动作，每个动作既不必然发生，也没有固定先后顺序。这些数据都是临时数据，只要扫码即可产生，因此选择存放到Redis中是合理的，在性能和数据上，可提供较好的体验。
Redis的数据变化过程
- Bid+Sn
- Bid+Sn+Phone
- Bid+Sn+bdcp（B-Defined-C-Pref）
- Bid+Sn+Phone+bdcp
注：完整的一个过程为1-2-4或者1-3-4。
Redis的数据结构
建议sorted sets，如下：
bid => [(sn => {phone, bdcp}), ...]
phone和bdcp，json格式存储，都不存在时，就是一个空的{}。
sn为score，{phone, bdcp} 为element。
- 一个sn一个element：B和C是一对一服务时的场景。
- 一个sn多个elements：B和C是一对多服务时的场景，比如在案场多人扫描易拉宝情况。
第二种情况下，数据就退化为：
bid => [(sn => [{phone1}, {phone2}, ...]), ...]
转换数据
需要有一个合适的动作，触发临时数据到MySQl的转换。比如：C的下载登录可能就是一个合适的时机。注：elements 没有 bdcp 数据对于繁忙案场情况是普遍的。
