80.8亿个微信红包技术难点在哪里？

摘要：今年除夕当日微信红包的参与人数达到4.2亿人，收发总量达80.8亿个，是羊年除夕10.1亿个的8倍。最高峰发生在00:06:09，每秒钟收发40.9万个红包。但是，红包大战受欢迎的程度和完美支撑红包大战的技术难度成正比。

面对如此海量的业务高并发性，其支撑系统面临着极大的挑战，腾讯云是如何在高可用保障和性能优化上苦练内功，为微信春节保驾护航的？

高可用保障，确保红包系统的正常运行

为了保障全国用户发红包时预订单系统可以快速响应，微信用户侧发起的相关请求会在腾讯云广州和上海的云机房做分流，部分访问到广州云机房，部分访问到上海云机房。

同时为了保证预订单系统的高可用性，分别部署了同城多可用区的应用容灾以及同城预订单系统多可用区数据双写等措施，即使广州和上海的某个可用区同时故障，预订单系统仍会在同城的另一可用区的灾备机房正常工作，不会影响用户的发红包业务。

作为微信红包系统中另一个重要的应用系统，列表系统用来处理用户抢、拆、发、查红包的数据处理。该系统又分为详情列表、收列表以及发列表，因为红包所有的业务场景都会牵涉到对详情列表的操作，所以详情列表的部分，腾讯云同时在上海和广州分别部署了两套系统，同时实现了同城和异地的应用容灾，即使其中三套宕机，仍旧不会影响用户查看自己的红包详情。

至于列表系统中的收列表和发列表系统，腾讯云目前在广州多可用区实现了同城应用容灾，如果用户从腾讯云上海云机房的接入侧发起的针对收发列表的操作请求会经过专线访问到腾讯云广州机房的收发列表系统。这部分就产生了穿越流量。

在数据库的持久化层，通过DBProxy实现了数据库的分库分表，同时持久化的存储系统CDB集群也实现了同城的应用灾备。

如果用一张图来表现的话是这样的▼

微信红包中核心的预订单系统和列表系统均是采用分层多地区，多机房部署、架构横向扩展、基础组件模块化，结合业务逻辑实现同城和异地的应用容灾。

上图中所有的模块全部是横向扩展架构，各个模块可以实现节点间的负载均衡和故障剔除，从而保障单个模块的高可用性，这是腾讯云为红包大战护航的一个重要保障。

性能优化，全面提升用户体验

预订单系统和列表系统的高可用性保证了微信红包系统的正常运行，而对云服务器、数据库等产品的性能优化则能带给用户更好的体验。要想顺利的克服红包大战中流量、数据、计算等方面的挑战，还需要不断提升产品的性能。

微信红包业务的接入，用到了上千台的接入云服务器和超高QPS配置的CMEM缓存持久化数据库CDB，该系统可支撑每分钟发出600w个红包，每分钟拆开4800w个红包。

云上微信红包的这套系统的请求处理能力和读写能力也都做到了业界领先的水平。在逻辑接入层，腾讯云可以提供高达700wQPS的请求处理能力；在CMEM缓存层，能够提供高达660WQPS的memcached读写能力，在数据库持久化层也可以提供高达100WQPS的MySql读写能力。

无论是云服务器、数据库的选择，还是对接入层、缓存层和数据库持久化层的精益求精，腾讯云在各个层面对于性能优化都是为了顺利护航红包大战在积累能量。

「微信」都使用了那些技术和工具？他又是怎样从0到1发展起来的？

https://www.sdk.cn/companies/624