Open edagarli opened 8 years ago
红包架构
1.预资源下载
这些页面需要用到图片,视频或H5页面等资源。在活动期间,参与用户多,对资源的请求量很大,如果都通过实时在线访问,服务器的网络带宽会面临巨大压力,基本无法支撑;另外,资源的尺寸比较大,下载到手机需要较长时间,用户体验也会很差。因此,我们采用预先下载的方式, 在活动开始前几天把资源推送给客户端,客户端在需要使用时直接从本地 加载。
2.摇/拆红包
除夕的摇一摇子系统是专门为活动定制的,按时间轴进行各项活动,这里边最重要、同时也是请求量最大的是摇红包。从需求上看,系统需要完成两个事:用户可以通过摇一摇抢到红包,红包金额可以入到用户的支付账户。在除夕,系统需要在很短时间内将几十亿个红包发放下去,对性能和可用性要求很高。考虑到涉及资金的业务逻辑比较复杂,还有很多数据库事务处理,耗时会比较长,于是我们将抢红包(信息流)和红包的账务逻辑(业务流和资金流)异步化。将前一部分处理流程尽可能设计得轻量,让用户可以很快抢到红包,然后再异步完成剩下的账务逻辑。
在微信后台系统中,一般情况下客户端发起的请求都是通过接入服务 转发给具体的业务服务处理的,会产生 RPC 调用。但对于摇一摇请求,我 们将摇一摇逻辑直接嵌入接入服务中,接入服务可以直接处理摇一摇请求, 派发红包。
按一般的系统实现,用户看到的红包在系统中是数据库中的数据记录, 抢红包就是找出可用的红包记录,将该记录标识为属于某个用户。在这种 实现里,数据库是系统的瓶颈和主要成本开销。我们在这一过程完全不使 用数据库,可以达到几个数量级的性能提升,同时可靠性有了更好的保障。
支付系统将所有需要下发的红包生成红包票据文件 ; 一).将红包票据文件拆分后放到每一个接入服务实例中; 二).接收到客户端发起摇一摇请求后,接入服务里的摇一摇逻辑拿出一个红包票据,在本地生成一个跟用户绑定的加密票据,下发给客户端; 三).客户端拿加密票据到后台拆红包,后台的红包简化服务通过本地计算即可验证红包,完成抢红包过程。
3.异步化 用户抢到红包后不会同步进行后续的账务处理,请求会被放入红包异步队列,再通过异步队列转给微信支付后台,由微信支付后台完成后续业务逻辑。
二 . 大规模集群中保证数据一致性
1 . 服务性能
为提升各个服务模块的处理性能,我们通过压测和 Profiler 分析, 发现了不少性能瓶颈点,做了大量优化。
2 . 业务支撑能力
支持更加复杂的业务场景,并在客户端和服务器都加入了很多可以后 期灵活调整的预埋能力,以更好地服务产品运营。
不断提升系统可用性是我们一直努力的目标,以下 5 点很好地提高了 系统的可用性。
红包架构
1.预资源下载
这些页面需要用到图片,视频或H5页面等资源。在活动期间,参与用户多,对资源的请求量很大,如果都通过实时在线访问,服务器的网络带宽会面临巨大压力,基本无法支撑;另外,资源的尺寸比较大,下载到手机需要较长时间,用户体验也会很差。因此,我们采用预先下载的方式, 在活动开始前几天把资源推送给客户端,客户端在需要使用时直接从本地 加载。
2.摇/拆红包
除夕的摇一摇子系统是专门为活动定制的,按时间轴进行各项活动,这里边最重要、同时也是请求量最大的是摇红包。从需求上看,系统需要完成两个事:用户可以通过摇一摇抢到红包,红包金额可以入到用户的支付账户。在除夕,系统需要在很短时间内将几十亿个红包发放下去,对性能和可用性要求很高。考虑到涉及资金的业务逻辑比较复杂,还有很多数据库事务处理,耗时会比较长,于是我们将抢红包(信息流)和红包的账务逻辑(业务流和资金流)异步化。将前一部分处理流程尽可能设计得轻量,让用户可以很快抢到红包,然后再异步完成剩下的账务逻辑。
在微信后台系统中,一般情况下客户端发起的请求都是通过接入服务 转发给具体的业务服务处理的,会产生 RPC 调用。但对于摇一摇请求,我 们将摇一摇逻辑直接嵌入接入服务中,接入服务可以直接处理摇一摇请求, 派发红包。
按一般的系统实现,用户看到的红包在系统中是数据库中的数据记录, 抢红包就是找出可用的红包记录,将该记录标识为属于某个用户。在这种 实现里,数据库是系统的瓶颈和主要成本开销。我们在这一过程完全不使 用数据库,可以达到几个数量级的性能提升,同时可靠性有了更好的保障。
支付系统将所有需要下发的红包生成红包票据文件 ; 一).将红包票据文件拆分后放到每一个接入服务实例中; 二).接收到客户端发起摇一摇请求后,接入服务里的摇一摇逻辑拿出一个红包票据,在本地生成一个跟用户绑定的加密票据,下发给客户端; 三).客户端拿加密票据到后台拆红包,后台的红包简化服务通过本地计算即可验证红包,完成抢红包过程。
3.异步化 用户抢到红包后不会同步进行后续的账务处理,请求会被放入红包异步队列,再通过异步队列转给微信支付后台,由微信支付后台完成后续业务逻辑。
二 . 大规模集群中保证数据一致性
1 . 服务性能
为提升各个服务模块的处理性能,我们通过压测和 Profiler 分析, 发现了不少性能瓶颈点,做了大量优化。
2 . 业务支撑能力
支持更加复杂的业务场景,并在客户端和服务器都加入了很多可以后 期灵活调整的预埋能力,以更好地服务产品运营。
不断提升系统可用性是我们一直努力的目标,以下 5 点很好地提高了 系统的可用性。