《6个月清洗近千亿条微信支付交易记录他们要搞什么大事情？.docx》由会员分享，可在线阅读，更多相关《6个月清洗近千亿条微信支付交易记录他们要搞什么大事情？.docx（16页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、6个月清洗近千亿条微信支付交易记录，他们要搞什么大事情？ 背景 2021年度8月 微信红包上线。2021年度春节微信红包引爆社交支付。2021年度春晚红包摇一摇 推动微信红包在全国迅速普及。此后 每逢节假日或者特殊日子 人们都会自主的兴起发红包 使微信红包成为热点。微信红包的炽热带动微信支付的迅猛开展 按当时的开展速度预估 到2021年度底 每天的微信支付交易记录会到达20亿。而原有的用户交易记录存储系统无法承受业务迅猛开展带来的冲击 一些瓶颈逐渐凸显出来。本文将就 微信支付背后的交易记录系统的重构优化历程进展一次全面的呈现。 历年度春节红包收发总量 老交易系统面临的问题 由于老的交易记录存储
2、系统是采用key/value的方式存储用户数据 每个用户的所有交易记录存储在一个value中 随着用户交易数据的不断增长 单个value数据会不断变大 最终单个value的20M上限会导致用户新增数据无法写入。 老系统将交易记录的写入流程放在了支付的关键途径上 然而 从整个支付业务场景来看 交易记录应该属于用户支付后的应用场景 如 查看交易详情、确认交易状态等 。所以将交易记录写入流程与支付关键途径解耦合能优化提升支付的效率以及体验。 老系统中交易记录的种类不全 这里的主要原因是在业务开展经过中有些场景的交易记录并没有纳入进来 如 收红包记录以及派奖收入等 。记录不全对用户会造成体验上的损害。
3、 记录查询方式过于简单 老的系统里把所有的交易记录按时间顺序排到一起 用户只能通过不断下拉的方式来查看。当用户想查找某种类型交易 或者某条历史的交易记录是 只能通过人肉遍历 非常不方便。 老交易记录系统交互界面 针对当时的业务背景以及问题 我们需要开发一套可以支持海量数据存储、高性能、高可靠、查询灵敏的交易数据存储系统。 技术方案 方案 采用关系型数据库存储需要分库分表 扩展不方便。采用简单的分布式kv存储 可以解决数据程度扩展的问题 但是对单个用户的数据存储以及管理存在问题 老系统存在的问题 单个value过大 。因此我们采用基于分布式kv存储平台tssd 对用户数据进展分档管理。 画图示意
4、存储构造 用户数据存储示意图 每个用户的数据由假设干个value组成。其中一个value为根节点 存储用户分档数据的元信息。其余value为数据节点 存储用户实际数据。用户的数据按时间的顺序分档 根节点中保存每档数据的时间范围条数等信息 当用户按顺序翻页查询时 根据恳求的数据的起始偏移以及条数 可以快速查询到所需要的数据。假如要查询某一条交易记录 先通过记录的时间在根节点中查找到对应的数据节点 再从该节点快速查找到该条数据。 数据分档是为解析决数据增长后单个value大小成为瓶颈的问题。那么存储用户数据元信息的根节点随着数据的增加是否也会成为瓶颈 这里的答案是肯定的 按照业务实际的数据大小 一
5、个根节点管理20万条用户数据时 其大小就会到达瓶颈 需要对根节点进展分档。假如我们再用一个元数据节点来管理分档的根节点 那么随着数据的增长 这个节点也需要再分 需要再增加一层节点来管理。这样数据就像一个不断增高的树一样 对读写访问的性能造成影响。 如何来管理一个不断增长的数据 同时保证数据的访问维持在一个相对固定的深度 首先我们再来看看用户数据的特点 按时间数据写入。访问主要是近期的数据 越老的数据访问频率越低。因此 我们将根节点的分档数据按照一个链的方式串起来 最新的在链头 最老的在链尾。当用户访问新的数据时 平均只需要2次查询 根节点 数据节点 访问较老数据时需要遍历根节点的链 由于这个链
6、是有序的 所以可以采用二分查找 时间复杂度为O logn 。 数据分档组织示意图 分类以及统计功能是用户查询交易记录的一个根本需求。分类可以让用户快速定位到想要查看的交易记录 统计功能可以一目了然某月的收入以及支出情况。但是采用key/value的存储平台不能像关系型数据库那样方便的按条件查询。根据业务的访问场景 所有的分类以及统计查询都是在一定时间范围内的 而我们的数据是按时间来组织的 因此 对于分类恳求 我们可以取指定时间段内的数据进展遍历。由于用户平均的数据在800条左右 一般查询时间范围在一个月左右 这样实际遍历的数据条数在几十条 因此时间延时可以知足需求。对于统计恳求 是按自然月 这
7、样我们可以将历史月的统计计算出缓存起来 而对当前月的统计实时计算。 线上运营 历史数据问题 历史数据问题是一个很繁琐很耗人力的问题。前面提到过 老的交易记录系统中用户的数据并不全 为了保证新系统中历史数据完好 需要从不同的数据源导出数据 而且每份数据都不是完好的 只有他们合在一起才是完好的。对于一条交易记录 其中局部字段要以微信支付数据源为准 局部字段要以财付通数据源为准 因此对历史数据的整合、清洗以及校验需要微信支付、财付通等各团队同事的配合。最终我们用了6个月左右的时间完成了723亿条历史数据整理、校验以及导入。 数据异常问题 数据的完好性以及可靠性是存储系统要提供的最根本保证 因此系统在
8、对数据的所有写以及修改操作都记录了详细的流水。在最初灰度数据阶段 我们发现当底层存储平台出现大量超时的异常情况下 总会存在少量用户的数据丧失的现象。通过分析流水日志 发现超时个别用户的少量数据发生了回退的现象。进一步分析发现是因为存储层超时时间远远大于我们恳求的超时时间 当业务的写恳求超时后 会提议新的写恳求 而这时老的写恳求后到达覆盖了新恳求的数据。针对这种场景 由于底层暂不支持CAS机制 因此我们采用全链路的排队机制 让单个用户的恳求在每一层都落在指定的效劳器以及进程上 排队执行 防止数据覆盖。 数据覆盖示意 节假日效应 微信支付中红包占了很大的比例。而红包的节假日效应非常明显 在春节除夕
9、这样的节假日 恳求量能到达平时的10倍。还有一些提早难以预计到的特殊日子 如 5.20 11.11等 恳求量也会突然翻倍。针对这种场景 假如用大量机器资源去扛节假日峰值 一会造成资源的浪费 此外还会加重运维扩容、缩容机器的工作。因此 我们在节假日顶峰采用一些柔性策略 削弱峰值恳求的影响。当恳求峰值大于我们预设的阈值 就把大于这个阈值的恳求先缓存到接入机的本地磁盘 当峰值过后再将这些恳求按一定速度落到底层存储。在未落底层存储前 这些记录无法查询 因此那些记录可以做消峰的柔性处理 需要结合业务场景 在实际应用中 我们只会将红包的恳求做消峰处理 而对其他支付恳求不会做这样的处理。 2017年度春节恳
10、求量与平时恳求量比照 数据平安 用户的交易数据是非常敏感的数据 一旦数据泄露 会对用户造成极大的损害 同时对微信支付也会是致命的打击。因此用户的数据平安问题是头等重要的问题。怎样保证用户的数据平安 目前我们从三个方面来做 1.访问控制 所有恳求必须带票据访问 票据是用户身份的认证 保证只有该用户提议的恳求才能访问该用户的数据。对于非用户提议的访问 客服查询、退款恳求等 需要公共票据。此外 系统内部效劳器访问有白名单控制 非白名单内的效劳器无权进展访问。 2.数据脱敏以及加密 用户数据内的敏感字段要进展脱敏或者加密 比方 用户的微信号、微信uin、商户号等信息 都要进展加密处理。同时 对用户的身
11、份id进展虚化 即使用户数据泄露 也无法跟详细的个人对应起来。 3.人员制度标准 在数据平安方面 出现问题往往是在人这个环节。开发人员以及运维人员往往具有较高的数据操作权限 因此 对开发人员以及运维人员的平安意识培养 以及完备的管理制度是非常必要的。收敛数据操作权限 权限最小化。对于线上所有的运维操作以及开发测试工具权限我们都接入到公司敏感权限管理系统 使得数据操作权限集中掌握在少数人手中 假如出现数据泄露问题首先从这些掌握操作权限的人问责。同时 所有的数据操作都会记录操作流水 可以用于对数据操作异常的审计 和出现问题后的追查。 效果 通过对微信交易记录系统的重构 用户数据的完好性、准确性得到
12、极大的进步。其中零钱明细之前因为数据不全的投诉已经没有 整体投诉率下降67%。用户的活泼度得到极大的提升。当前的日交易记录数接近几十亿 含红包收 总数据量已破万亿。在交易记录的查询体验上也更加方便。在数据的存储以及管理方面 我们遵循行业内的平安标准来要求 以保证用户的个人信息以及数据平安。 新交易记录系统交互界面 总结 “滴“一下就可以支付的时代已经降临 “微信支付 一定会是一个全球性的支付。伴随“无现金生活在全球范围内的普及 我们的舞台也将越来越大。目前新的交易记录系统是基于当前支付业务的特点以及需求 后续随着支付业务的开展 支付场景会更加丰富 支付的形式会更加多样化 对于交易记录的需求以及
13、挑战也会不断变化。将来我们对系统的优化方向 是提供更加全面、实时、准确、平安的用户交易记录存储以及查询平台。而我们追求的是“尽可能把交易系统做好 给用户带来最好的体验 背景 2021年度8月 微信红包上线。2021年度春节微信红包引爆社交支付。2021年度春晚红包摇一摇 推动微信红包在全国迅速普及。此后 每逢节假日或者特殊日子 人们都会自主的兴起发红包 使微信红包成为热点。微信红包的炽热带动微信支付的迅猛开展 按当时的开展速度预估 到2021年度底 每天的微信支付交易记录会到达20亿。而原有的用户交易记录存储系统无法承受业务迅猛开展带来的冲击 一些瓶颈逐渐凸显出来。本文将就 微信支付背后的交易
14、记录系统的重构优化历程进展一次全面的呈现。 历年度春节红包收发总量 老交易系统面临的问题 由于老的交易记录存储系统是采用key/value的方式存储用户数据 每个用户的所有交易记录存储在一个value中 随着用户交易数据的不断增长 单个value数据会不断变大 最终单个value的20M上限会导致用户新增数据无法写入。 老系统将交易记录的写入流程放在了支付的关键途径上 然而 从整个支付业务场景来看 交易记录应该属于用户支付后的应用场景 如 查看交易详情、确认交易状态等 。所以将交易记录写入流程与支付关键途径解耦合能优化提升支付的效率以及体验。 老系统中交易记录的种类不全 这里的主要原因是在业务
15、开展经过中有些场景的交易记录并没有纳入进来 如 收红包记录以及派奖收入等 。记录不全对用户会造成体验上的损害。 记录查询方式过于简单 老的系统里把所有的交易记录按时间顺序排到一起 用户只能通过不断下拉的方式来查看。当用户想查找某种类型交易 或者某条历史的交易记录是 只能通过人肉遍历 非常不方便。 老交易记录系统交互界面 针对当时的业务背景以及问题 我们需要开发一套可以支持海量数据存储、高性能、高可靠、查询灵敏的交易数据存储系统。 技术方案 方案 采用关系型数据库存储需要分库分表 扩展不方便。采用简单的分布式kv存储 可以解决数据程度扩展的问题 但是对单个用户的数据存储以及管理存在问题 老系统存
16、在的问题 单个value过大 。因此我们采用基于分布式kv存储平台tssd 对用户数据进展分档管理。 画图示意存储构造 用户数据存储示意图 每个用户的数据由假设干个value组成。其中一个value为根节点 存储用户分档数据的元信息。其余value为数据节点 存储用户实际数据。用户的数据按时间的顺序分档 根节点中保存每档数据的时间范围条数等信息 当用户按顺序翻页查询时 根据恳求的数据的起始偏移以及条数 可以快速查询到所需要的数据。假如要查询某一条交易记录 先通过记录的时间在根节点中查找到对应的数据节点 再从该节点快速查找到该条数据。 数据分档是为解析决数据增长后单个value大小成为瓶颈的问题
17、。那么存储用户数据元信息的根节点随着数据的增加是否也会成为瓶颈 这里的答案是肯定的 按照业务实际的数据大小 一个根节点管理20万条用户数据时 其大小就会到达瓶颈 需要对根节点进展分档。假如我们再用一个元数据节点来管理分档的根节点 那么随着数据的增长 这个节点也需要再分 需要再增加一层节点来管理。这样数据就像一个不断增高的树一样 对读写访问的性能造成影响。 如何来管理一个不断增长的数据 同时保证数据的访问维持在一个相对固定的深度 首先我们再来看看用户数据的特点 按时间数据写入。访问主要是近期的数据 越老的数据访问频率越低。因此 我们将根节点的分档数据按照一个链的方式串起来 最新的在链头 最老的在
18、链尾。当用户访问新的数据时 平均只需要2次查询 根节点 数据节点 访问较老数据时需要遍历根节点的链 由于这个链是有序的 所以可以采用二分查找 时间复杂度为O logn 。 数据分档组织示意图 分类以及统计功能是用户查询交易记录的一个根本需求。分类可以让用户快速定位到想要查看的交易记录 统计功能可以一目了然某月的收入以及支出情况。但是采用key/value的存储平台不能像关系型数据库那样方便的按条件查询。根据业务的访问场景 所有的分类以及统计查询都是在一定时间范围内的 而我们的数据是按时间来组织的 因此 对于分类恳求 我们可以取指定时间段内的数据进展遍历。由于用户平均的数据在800条左右 一般查
19、询时间范围在一个月左右 这样实际遍历的数据条数在几十条 因此时间延时可以知足需求。对于统计恳求 是按自然月 这样我们可以将历史月的统计计算出缓存起来 而对当前月的统计实时计算。 线上运营 历史数据问题 历史数据问题是一个很繁琐很耗人力的问题。前面提到过 老的交易记录系统中用户的数据并不全 为了保证新系统中历史数据完好 需要从不同的数据源导出数据 而且每份数据都不是完好的 只有他们合在一起才是完好的。对于一条交易记录 其中局部字段要以微信支付数据源为准 局部字段要以财付通数据源为准 因此对历史数据的整合、清洗以及校验需要微信支付、财付通等各团队同事的配合。最终我们用了6个月左右的时间完成了723
20、亿条历史数据整理、校验以及导入。 数据异常问题 数据的完好性以及可靠性是存储系统要提供的最根本保证 因此系统在对数据的所有写以及修改操作都记录了详细的流水。在最初灰度数据阶段 我们发现当底层存储平台出现大量超时的异常情况下 总会存在少量用户的数据丧失的现象。通过分析流水日志 发现超时个别用户的少量数据发生了回退的现象。进一步分析发现是因为存储层超时时间远远大于我们恳求的超时时间 当业务的写恳求超时后 会提议新的写恳求 而这时老的写恳求后到达覆盖了新恳求的数据。针对这种场景 由于底层暂不支持CAS机制 因此我们采用全链路的排队机制 让单个用户的恳求在每一层都落在指定的效劳器以及进程上 排队执行
21、防止数据覆盖。 数据覆盖示意 节假日效应 微信支付中红包占了很大的比例。而红包的节假日效应非常明显 在春节除夕这样的节假日 恳求量能到达平时的10倍。还有一些提早难以预计到的特殊日子 如 5.20 11.11等 恳求量也会突然翻倍。针对这种场景 假如用大量机器资源去扛节假日峰值 一会造成资源的浪费 此外还会加重运维扩容、缩容机器的工作。因此 我们在节假日顶峰采用一些柔性策略 削弱峰值恳求的影响。当恳求峰值大于我们预设的阈值 就把大于这个阈值的恳求先缓存到接入机的本地磁盘 当峰值过后再将这些恳求按一定速度落到底层存储。在未落底层存储前 这些记录无法查询 因此那些记录可以做消峰的柔性处理 需要结合
22、业务场景 在实际应用中 我们只会将红包的恳求做消峰处理 而对其他支付恳求不会做这样的处理。 2017年度春节恳求量与平时恳求量比照 数据平安 用户的交易数据是非常敏感的数据 一旦数据泄露 会对用户造成极大的损害 同时对微信支付也会是致命的打击。因此用户的数据平安问题是头等重要的问题。怎样保证用户的数据平安 目前我们从三个方面来做 1.访问控制 所有恳求必须带票据访问 票据是用户身份的认证 保证只有该用户提议的恳求才能访问该用户的数据。对于非用户提议的访问 客服查询、退款恳求等 需要公共票据。此外 系统内部效劳器访问有白名单控制 非白名单内的效劳器无权进展访问。 2.数据脱敏以及加密 用户数据内
23、的敏感字段要进展脱敏或者加密 比方 用户的微信号、微信uin、商户号等信息 都要进展加密处理。同时 对用户的身份id进展虚化 即使用户数据泄露 也无法跟详细的个人对应起来。 3.人员制度标准 在数据平安方面 出现问题往往是在人这个环节。开发人员以及运维人员往往具有较高的数据操作权限 因此 对开发人员以及运维人员的平安意识培养 以及完备的管理制度是非常必要的。收敛数据操作权限 权限最小化。对于线上所有的运维操作以及开发测试工具权限我们都接入到公司敏感权限管理系统 使得数据操作权限集中掌握在少数人手中 假如出现数据泄露问题首先从这些掌握操作权限的人问责。同时 所有的数据操作都会记录操作流水 可以用
24、于对数据操作异常的审计 和出现问题后的追查。 效果 通过对微信交易记录系统的重构 用户数据的完好性、准确性得到极大的进步。其中零钱明细之前因为数据不全的投诉已经没有 整体投诉率下降67%。用户的活泼度得到极大的提升。当前的日交易记录数接近几十亿 含红包收 总数据量已破万亿。在交易记录的查询体验上也更加方便。在数据的存储以及管理方面 我们遵循行业内的平安标准来要求 以保证用户的个人信息以及数据平安。 新交易记录系统交互界面 总结 “滴“一下就可以支付的时代已经降临 “微信支付 一定会是一个全球性的支付。伴随“无现金生活在全球范围内的普及 我们的舞台也将越来越大。目前新的交易记录系统是基于当前支付业务的特点以及需求 后续随着支付业务的开展 支付场景会更加丰富 支付的形式会更加多样化 对于交易记录的需求以及挑战也会不断变化。将来我们对系统的优化方向 是提供更加全面、实时、准确、平安的用户交易记录存储以及查询平台。而我们追求的是“尽可能把交易系统做好 给用户带来最好的体验 腾讯技术工程