前言：
　　春节快到了, 今年的互联网红包大战打得特别的火热.
　　阵容强大, 腾讯微信/手Q, 阿里支付宝, 新浪微博, 还有千呼万唤始出来, 犹抱琵琶半遮面的百度钱包.
　　类型多样, 有秒杀型的红包, 如微信的摇一摇, 支付宝的"打地鼠", 也有常规红包, 如支付宝新春红包.
　　与去年的一家独大相比, 今年是你方唱罢我登场, 各领风骚数十载.
　　对于我个人而言, 印象最深的不是戳破手机屏的"打地鼠", 而是接龙红包, 本文尝试去分析接龙红包背后的技术实现, 以及接龙红包本身所隐藏的强大社交性.

游戏模型：
　　让我们先来阐述下接龙游戏怎么玩？
　　1). 大财主发放某个特定数值的红包
　　2). 好友猜测该数字, 若猜中则平分红包，若失败则收敛并继续传递下去(接龙)

　　一图胜千言，大财主发放了66块的红包, 由3个好友分支尝试猜测该数值.
　　1). 小狗旺旺, 刚要猜的时候, 却发现慢了半拍, 接龙游戏已结束
　　2). 小红猜测失败, 但没有继续传递下去
　　3). "斗地主联盟"经过两轮收敛猜对了数值
　　因此该接龙游戏的优胜者是"斗地主联盟", 其接龙传递链上成员共享奖金, 如66元的红包, 每人各得33元

　　当然在一次接龙游戏中, 一个用户只能参与一次, 这样接龙游戏的图模型具备如下约束:
　　1). 不能构成环
　　2). 用户节点不能同时出现在2个及以上的子树分支中

　　结合简单示例, 我们可以最终得出接龙模型为树结构. 而且其树结构有如下特征:
　　1). 节点分支多, 好友社交关系决定
　　2). 树深度浅, 二分逼近收敛快, log(n)指数 (100块, 最多需要7次)
　　3). 向上回溯，树节点只需维护父节点， 不需要维护子节点

架构设计：
　　如何选用合适的存储来维护该树结构，并完美的支撑其业务需求. mysql，key/value系统, 还是自定义存储结构？
　　其实我们不用烦恼了，支付宝已经给了明确的答案.
　　
　　对, 你猜得没错,这就是key/value系统.
　　让我们来简单分析下, 为何key/value系统是最适合的存储技术.
　　1). 接龙游戏本身的树节点本身是松散自由的, 每个节点都是一个信息入口
　　2). key/value能快速访问各个树节点
　　3). key/value读写性能优异

　　对于所发的红包，我们还是采用mysql表来存储：

　　对于接龙的用户而言，采用分布式的key/value来存储，假设这边采用leveldb.
　　key为接龙的数字, 用整数表示
　　value采用protobuf格式

message tw_envelop {required int32 user_id = 1;            // 当前节点的用户required int32 type = 2;         // type表示用户性质, 0:主人, 1:接龙者required int32 envelop_id = 3;   // 红包idrequired int32 pioneer_key = 4; // 承接的上一个接龙keyrequired int32 lower_val = 5;    // 当前接龙红包数值的下限required int32 upper_val = 6;    // 当前接龙红包数值的上限
};

　　key/value系统维护的树结构, 可以用下图来描述:

　　对于每个接龙游戏只允许用户参与一次, 这种情景限定如何实现呢?
　　其实这类去重问题很普遍, 解决的技术手段也容易，这边采用最简单的key/value去重即可.
　　key的设计如下:

envelop_id:user_id

　　注: envelop_id为红包id, 而user_id则为实际的用户帐号

　　抛开树形结构如何去存储的问题后, 我们来看看, 什么是红包游戏最核心的技术呢?
　　口令ID生成器, 如何保证id生成是唯一的, 另一方面保证ID生成没有规律.
　　这边就不再具体展开, 但这个技术问题, 是有一定挑战性的.

挑战:
　　接龙游戏当前所遇到的问题, 我觉得是安全问题, 随意输入口令是否存在窃取他人红包的风险. 技术本身反而是简单的.

总结:
　　不管怎么说, 支付宝的红包(特别是接龙红包)无疑是成功的, 借助社交(微信)来做病毒式传播, 起到了很好的效果. 本篇文章, 是个人对接龙红包实现的理解, 有不足之处, 还请轻拍. 如有机会, 让我们谈谈秒杀型红包的实现。

写在最后：
　　如果你觉得这篇文章对你有帮助, 请小小打赏下. 其实我想试试, 看看写博客能否给自己带来一点小小的收益.