微信红包体系设计分析

那这四个页面分别会在什么时候出现呢?在5.2中会做详细的介绍。

3.4红包结果页面

红包结果页面会显示抢到红包的人的列表，其中金额最大的为手气最佳。当有两个或者以上金额相同的时候，以时间最早的一个为最佳手气。页面还会显示发红包的人极其昵称、你自己领到的金额(如果没领到就不会显示)，零钱入口和转发该红包的入口、我的红包记录入口。红包结果页面也有很多种，详见本文的5.3部分.

3.5摇一摇红包

摇一摇红包和企业红包的随机方法和群手气红包大同小异，由于没有接触过企业红包的发放流程，这里不多说。

为什么要有剩余红包个数呢?

引用鹏飞在人人都是产品经理举办的产品经理大会广州站上说的一句话”给用户一个预期，现在还有没有红包，还有多少，而且这个数字必须准确，不能忽悠用户。有些朋友和我说，他们就是在最后几秒摇到的。所以，要让用户为希望而摇，为了希望，把手摇断，又算什么!”。没错，这个数字是”准确”的，但是他并不是实时的。因为过于频繁刷新的数字少量减少，不仅用户没有感知，不停的访问数据库剩余红包数对于服务器也是极大压力，所以推测微信是采用这种策略：每减少1个单位(比如说50W)的红包数量，自动将这个值写入缓存服务器，用户摇红包的时候都直接访问缓存，而且不是每次摇都访问剩余数，而是摇n次之后(比如摇了5次)才去请求一次剩余红包数，这样就把传递到服务器的压力减少n倍。

上图最后那个页面你没见过?

微信官方说，当服务器压力过大的时候，唤起让用户休息一下这个页面。这里我提出另外一种策略，也许微信也采用了这种策略：当用户摇一摇请求红包时，服务器压力过大，网络阻塞或者队列已满等异常情况下，会直接通知客户端”你没有抢到”，也就是直接返回那个摇红包的页面进行下一次的摇一摇动作，这样子永远也不会显示那个”休息一下”的页面。

4后台

4.1数据库

以下关系型数据库设计的字段是基于少量请求下，我们模拟红包系统的可行方案，并没有考虑高并发、分库分表以及缓存的情况，关于这部分内容可以查看本文4.4部分整理一些大神的回答作为了解。