[笔记]微信红包订单存储架构变迁的最佳实践

前言

微信红包在2017年又是一波大火，官方数据：除夕夜当天共142亿个红包，峰值76w/s个红包，作为技术菜鸟，更关注其背后强大的支持体系，与高可用之道，正好看到“微信红包订单存储架构变迁的最佳实践”这篇文章，从前端开始到存储层做了一系列讲解，故做下笔记。

我的笔记

前端流量控制

主要思路是缩短关键业务流程，分离可以通过异步、缓存等方式解决的问题，减轻系统压力，加快响应速度，在存储层前面建上一座大坝。

CGI无状态

接入层无状态，逻辑层也无状态，可以方便地水平扩展，但依赖MySQL事务保证交易完整，保证红包系统的精简，减少瓶颈的存在。

资源静态化

尽量将动态资源转为静态资源。静态资源和CGI分离，静态资源通过CDN就近接入，减少用户和CGI的交互，减少内网、访问延迟和数据请求。

业务流程异步化

红包的发、抢、拆背后的多个内部环境，关键流程精简，非关键流程和后续业务进入异步队列进行处理。

过载保护

前端保护后端，能在前端处理的就不传到后端。前端按照后端的能力做削峰限流；客户端、接入层、逻辑层每一次都做流量控制；微信客户端预埋的策略：在连接失败或者超时情况下会有相应的提示，减少重复请求的次数。接入层：针对频繁发出请求的客户端限制响应速度，并对系统负载划出若干个等级，达到不同阀值时引导客户端使用不同的限速速率；在异常情况出现时，异步限流降速减轻服务器压力防止过载

多级读缓存

抢的请求量远大于发。故逻辑层增加缓存，若已经抢过了则缓存起来直接返回。

订单写缓存

系统会有很多请求不会真正的完成全流量，创建这些废单不但浪费存储资源，还会占用逻辑层和存储层的处理能力，影响其他的交易。订单在完成支付前先放在缓存，付款后再进行持久化。

存储层的高可用设计

读写分离

水平切分

分库分表

垂直切分

行内数据按照属性进一步分开。核心表只保留最关键的字段，保证数据文件短小紧凑。以红包为例，昵称和祝福语这类较长的信息不属于核心数据，完全可以切分到别的机器上进一步提升核心数据库的容量。不同数据适合存储类型也不一样，这类重复率高的长字符串更适合nosql存储，对存储空间和性能都是节约极大

空间换时间

按不同维度组织表，比如订单属性和用户属性维度；适合不同的请求场景，不同维度的表可以通过对账对齐，非核心表可以适当冗余数据，减少请求次数。

锁的优化

多人抢红包的时候必然数据库会发生行锁，核心事务必须尽量精简防止死锁。同一个订单的所有请求，尽量在逻辑层进程预排序之后再通过一个连接发送请求到数据库。

冷热分离

核心数据库存放高频数据，其他数据可以定时移到成本低的冷数据库中。这样可以为核心数据库使用最好的SSD设备，快速设备容量较小较贵，不可能在全量数据上使用。同时可以保证数据库表容量不会一直积累，大表也会导致性能下降。

异地多活

当系统足够大的时候必须考虑异地部署的问题，让数据尽可能离用户近。而且进一步的高可用不能局限在同一地域，必须跨数据中心跨城多活才能抵御系统性风险。跨城会有几十毫秒延迟，微信红包的异地活动设计多为数据中心相互独立。非灾难灰度不会将其他数据中心的数据导入线上。

就近接入

就近接入，减少跨城穿越流量。

数据分离

网络技术限制，光纤也无法保证跨城数据的同步延迟问题。所以跨城数据中心不进行相互实时同步。不同区域各自承担业务流量，地域上实现平衡，各地的订单数据各自独立。

异地容灾

当出现地域性故障，则将请求根据容量承担情况直接分散请求到临近的数据中心，跨地域分流。

有损服务和柔性降级

根据CAP原理无法同时保证一致性和高可用，必须有取舍。故选择首先保证高可用，同时实现最终一致性。

有损服务

要追求高可用，可以牺牲一些一致性和完整性从而保证核心功能。在请求超过设定阀值，必须立即降级防止雪崩。但是要保证数据能最终一致。

柔性可用

柔性可用是在有损服务价值观支持下的方法，结合具体场景提供不同级别的用户体验，保证尽可能成功返回关键数据。系统首先要实现容灾和自动切换；其次逻辑资源应该隔离；服务过载时必须自动快速隔离。

微信红包订单存储架构变迁的最佳实践，原文，请点击这里