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

2017 年 12 月 22 日 架构文摘 how

背景：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年春节请求量与平时请求量对比

数据安全：用户的交易数据是非常敏感的数据，一旦数据泄露，会对用户造成极大的损害，同时对微信支付也会是致命的打击。因此用户的数据安全问题是头等重要的问题。如何保证用户的数据安全？目前我们从三个方面来做：

1. 访问控制：所有请求必须带票据访问，票据是用户身份的认证，保证只有该用户发起的请求才能访问该用户的数据。对于非用户发起的访问（客服查询、退款请求等）需要公共票据。此外，系统内部服务器访问有白名单控制，非白名单内的服务器无权进行访问。

2. 数据脱敏和加密：用户数据内的敏感字段要进行脱敏或加密，比如：用户的微信号、微信uin、商户号等信息，都要进行加密处理。同时，对用户的身份id进行虚化，即使用户数据泄露，也无法跟具体的个人对应起来。

3. 人员制度规范：在数据安全方面，出现问题往往是在人这个环节。开发人员和运维人员往往具有较高的数据操作权限，因此，对开发人员和运维人员的安全意识培养，和完备的管理制度是非常必要的。收敛数据操作权限，权限最小化。对于线上所有的运维操作和开发测试工具权限我们都接入到公司敏感权限管理系统，使得数据操作权限集中掌握在少数人手中，如果出现数据泄露问题首先从这些掌握操作权限的人问责。同时，所有的数据操作都会记录操作流水，可以用于对数据操作异常的审计，以及出现问题后的追查。

效果

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

新交易记录系统交互界面

总结

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