微信支付兴起,万亿级用户交易记录存储的挑战

作者:罗皓

背景

2013 年 8 月,微信红包上线。2014 年春节微信红包引爆社交支付。2015 年春晚红包摇一摇,推动微信红包在全国迅速普及。此后,每逢节假日或特殊日子,人们都会自主的兴起发红包,使微信红包成为热点。微信红包的火热带动微信支付的迅猛发展,按当时的发展速度预估,到 2015 年底,每天的微信支付交易记录会达到 20 亿。而原有的用户交易记录存储系统无法承受业务迅猛发展带来的冲击,一些瓶颈逐渐凸显出来。本文将就微信支付背后的交易记录系统的重构优化历程进行一次全面的呈现。

历年春节红包收发总量

老交易记录系统面临的问题:

由于老的交易记录存储系统是采用key/value的方式存储用户数据,每个用户的所有交易记录存储在一个value中,随着用户交易数据的不断增长,单个 value 数据会不断变大,最终单个 value 的 20M 上限会导致用户新增数据无法写入。

老系统将交易记录的写入流程放在了支付的关键路径上,然而,从整个支付业务场景来看,交易记录应该属于用户支付后的应用场景(如:查看交易详情、确认交易状态等)。所以将交易记录写入流程与支付关键路径解耦合能优化提升支付的效率和体验。

老系统中交易记录的种类不全:这里的主要原因是在业务发展过程中有些场景的交易记录并没有纳入进来(如:收红包记录和派奖收入等)。记录不全对用户会造成体验上的损害。

记录查询方式过于简单:老的系统里把所有的交易记录按时间顺序排到一起,用户只能通过不断下拉的方式来查看。当用户想查找某种类型交易,或某条历史的交易记录是,只能通过人肉遍历,非常不方便。

老交易记录系统交互界面

针对当时的业务背景和问题,我们需要开发一套能够支持海量数据存储、高性能、高可靠、查询灵活的交易数据存储系统。

技术方案

方案:采用关系型数据库存储需要分库分表,扩展不方便。采用简单的分布式 kv 存储,能够解决数据水平扩展的问题,但是对单个用户的数据存储和管理存在问题(老系统存在的问题,单个 value 过大)。因此我们采用基于分布式 kv 存储平台 tssd,对用户数据进行分档管理。(画图示意存储结构)

用户数据存储示意图

每个用户的数据由若干个 value 组成。其中一个 value 为根节点,存储用户分档数据的元信息。其余 value 为数据节点,存储用户实际数据。用户的数据按时间的顺序分档,根节点中保存每档数据的时间范围条数等信息,当用户按顺序翻页查询时,根据请求的数据的起始偏移和条数,能够快速查询到所需要的数据。如果要查询某一条交易记录,先通过记录的时间在根节点中查找到对应的数据节点,再从该节点快速查找到该条数据。

数据分档是为了解决数据增长后单个 value 大小成为瓶颈的问题。那么存储用户数据元信息的根节点随着数据的增加是否也会成为瓶颈?这里的答案是肯定的,按照业务实际的数据大小,一个根节点管理 20 万条用户数据时,其大小就会达到瓶颈,需要对根节点进行分档。如果我们再用一个元数据节点来管理分档的根节点,那么随着数据的增长,这个节点也需要再分,需要再增加一层节点来管理。这样数据就像一个不断增高的树一样,对读写访问的性能造成影响。

怎样来管理一个不断增长的数据,同时保证数据的访问维持在一个相对固定的深度?首先我们再来看看用户数据的特点,按时间数据写入。访问主要是近期的数据,越老的数据访问频率越低。因此,我们将根节点的分档数据按照一个链的方式串起来,最新的在链头,最老的在链尾。当用户访问新的数据时,平均只需要 2 次查询(根节点 数据节点),访问较老数据时需要遍历根节点的链,由于这个链是有序的,所以可以采用二分查找,时间复杂度为 O(logn)。

数据分档组织示意图

分类和统计功能是用户查询交易记录的一个基本需求。分类能够让用户快速定位到想要查看的交易记录;统计功能能够一目了然某月的收入和支出情况。但是采用 key/value 的存储平台不能像关系型数据库那样方便的按条件查询。根据业务的访问场景,所有的分类和统计查询都是在一定时间范围内的,而我们的数据是按时间来组织的,因此,对于分类请求,我们可以取指定时间段内的数据进行遍历。由于用户平均的数据在 800 条左右,一般查询时间范围在一个月左右,这样实际遍历的数据条数在几十条,因此时间延时可以满足需求。对于统计请求,是按自然月,这样我们可以将历史月的统计计算出缓存起来,而对当前月的统计实时计算。

线上运营

历史数据问题:历史数据问题是一个很繁琐很耗人力的问题。前面提到过,老的交易记录系统中用户的数据并不全,为了保证新系统中历史数据完整,需要从不同的数据源导出数据,而且每份数据都不是完整的,只有他们合在一起才是完整的。对于一条交易记录,其中部分字段要以微信支付数据源为准,部分字段要以财付通数据源为准,因此对历史数据的整合、清洗和校验需要微信支付、财付通等各团队同事的配合。最终我们用了 6 个月左右的时间完成了 723 亿条历史数据整理、校验和导入。

数据异常问题:数据的完整性和可靠性是存储系统要提供的最基本保证,因此系统在对数据的所有写和修改操作都记录了详细的流水。在最初灰度数据阶段,我们发现当底层存储平台出现大量超时的异常情况下,总会存在少量用户的数据丢失的现象。通过分析流水日志,发现超时个别用户的少量数据发生了回退的现象。进一步分析发现是因为存储层超时时间远远大于我们请求的超时时间,当业务的写请求超时后,会发起新的写请求,而这时老的写请求后到达覆盖了新请求的数据。针对这种场景,由于底层暂不支持 CAS 机制,因此我们采用全链路的排队机制,让单个用户的请求在每一层都落在指定的服务器和进程上,排队执行,避免数据覆盖。

数据覆盖示意

节假日效应:微信支付中红包占了很大的比例。而红包的节假日效应非常明显,在春节除夕这样的节假日,请求量能达到平时的 10 倍。还有一些提前难以预计到的特殊日子(如:5.20,11.11 等),请求量也会突然翻倍。针对这种场景,如果用大量机器资源去扛节假日峰值,一会造成资源的浪费,此外还会加重运维扩容、缩容机器的工作。因此,我们在节假日高峰采用一些柔性策略,削弱峰值请求的影响。当请求峰值大于我们预设的阈值,就把大于这个阈值的请求先缓存到接入机的本地磁盘,当峰值过后再将这些请求按一定速度落到底层存储。在未落底层存储前,这些记录无法查询,因此那些记录能够做消峰的柔性处理,需要结合业务场景,在实际应用中,我们只会将红包的请求做消峰处理,而对其他支付请求不会做这样的处理。

2017 年春节请求量与平时请求量对比

  • 数据安全:用户的交易数据是非常敏感的数据,一旦数据泄露,会对用户造成极大的损害,同时对微信支付也会是致命的打击。因此用户的数据安全问题是头等重要的问题。如何保证用户的数据安全?目前我们从三个方面来做:
  • 访问控制:所有请求必须带票据访问,票据是用户身份的认证,保证只有该用户发起的请求才能访问该用户的数据。对于非用户发起的访问(客服查询、退款请求等)需要公共票据。此外,系统内部服务器访问有白名单控制,非白名单内的服务器无权进行访问
  • 数据脱敏和加密:用户数据内的敏感字段要进行脱敏或加密,比如:用户的微信号、微信 uin、商户号等信息,都要进行加密处理。同时,对用户的身份 id 进行虚化,即使用户数据泄露,也无法跟具体的个人对应起来。
  • 人员制度规范:在数据安全方面,出现问题往往是在人这个环节。开发人员和运维人员往往具有较高的数据操作权限,因此,对开发人员和运维人员的安全意识培养,和完备的管理制度是非常必要的。收敛数据操作权限,权限最小化。对于线上所有的运维操作和开发测试工具权限我们都接入到公司敏感权限管理系统,使得数据操作权限集中掌握在少数人手中,如果出现数据泄露问题首先从这些掌握操作权限的人问责。同时,所有的数据操作都会记录操作流水,可以用于对数据操作异常的审计,以及出现问题后的追查。

效果

通过对微信交易记录系统的重构,用户数据的完整性、准确性得到极大的提高。其中零钱明细之前因为数据不全的投诉已经没有,整体投诉率下降 67%。用户的活跃度得到极大的提升。当前的日交易记录数接近 30 亿(含红包收),总数据量已破万亿。在交易记录的查询体验上也更加方便。在数据的存储和管理方面,我们遵循行业内的安全标准来要求,以保证用户的个人信息和数据安全。

新交易记录系统交互界面

总结

"滴"一下就可以支付的时代已经来临,"微信支付,一定会是一个全球性的支付"。伴随"无现金生活"在全球范围内的普及,我们的舞台也将越来越大。目前新的交易记录系统是基于当前支付业务的特点和需求,后续随着支付业务的发展,支付场景会更加丰富,支付的形式会更加多样化,对于交易记录的需求和挑战也会不断变化。未来我们对系统的优化方向,是提供更加方面、实时、准确、安全的用户交易记录存储和查询平台。而我们追求的是"尽可能把交易系统做好,给用户带来最好的体验"!

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT大咖说

经历了研发困局、运维之痛,同程微服务从1到1w的旅程

内容来源:2017 年 9 月 9 日,前同程艺龙架构师谢康在“ArchData技术大会上海站”进行《同程微服务从1到1w的旅程》演讲分享。IT 大咖说(微信i...

843
来自专栏喔家ArchiSelf

面向IoT的协议选择思考

对于使用传感器和保持连接性的IoT系统而言,如何使用这些元素和多种互联网技术相结合呢?

996
来自专栏智能计算时代

物联网设备和应用程序涉及协议的概述

物联网设备和应用程序涉及协议的概述。 帮助澄清IoT层技术栈和头对头比较。 物联网涵盖了广泛的行业和用例,从单一受限制的设备扩展到大量跨平台部署嵌入式技术和实时...

3585
来自专栏Java技术

中国式微服务技术栈2.0!

近年,Spring Cloud俨然已经成为微服务开发的主流技术栈,在国内开发者社区非常火爆。我近年一直在一线互联网公司(携程,拍拍贷等)开展微服务架构实践,根据...

602
来自专栏Linyb极客之路

运维管理之怎么做容量规划

一般每个服务都有对外承诺的服务质量,那么我们就需要根据这个目标来做容量规划及硬件方面的投入。

763
来自专栏腾讯技术工程官方号的专栏

春节微信访问突发,存储业务如何平稳度过?

存储业务里面有很多访问突发的业务,其中微信就是一个典型的业务。微信承担了亿万用户的图片、视频和文件的收发,遇到特殊热点事件或者重大节假日,访问次数会突发10倍以...

3653
来自专栏YouMeek

微服务系统:解惑、技术选型

在商言商 一家公司在发现新的市场需求的时候,先发制人所产生的优势是非常重要的。所以美国利宝相互保险公司执行副总裁兼首席信息官 James McGlennon 说...

61712
来自专栏即时通讯技术

微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

对于IM系统来说,如何做到IM聊天消息离线差异拉取(差异拉取是为了节省流量)、消息多端同步、消息顺序保证等,是典型的IM技术难点。

662
来自专栏CSDN技术头条

【BDTC 2015】数据库分论坛:GBase 8t、PosgreSQL-X2核心技术解析

2015年12月10-12日,由中国计算机学会(CCF)主办,CCF大数据专家委员会承办,中国科学院计算技术研究所、北京中科天玑科技有限公司与CSDN共同协办,...

2046
来自专栏java一日一条

Java 消亡了?不!原因在这…

年复一年,关于”Java消亡了?”的疑问频繁涌现,然而,通过所有外部表现来看,Java仍活着,并且在发展。尽管许多新语言各领风骚,开发语言排行榜(TIOBE)上...

322

扫码关注云+社区