支付架构

支付架构

架构 乐视 订单架构

分库分表

构建一个支撑每秒十万只读系统并不复杂,无非是通过一致性哈希扩展缓存节点,水平扩展web服务器等。每秒钟数十万数据更新操作,在任何数据库上都是不可能的任务,首先需要对订单表进行分库分表。

在进行数据库操作时,一般会用ID(UID)字段,所以选择以UID进行分库分表。

分库策略我们选择了“二叉树分库”,所谓“二叉树分库”指:在进行数据库扩容时,以2倍数进行扩容。比如:1台扩容2台,2台扩容4台,以此类推。最后把Order库分了8个库中,每个库10个表。

根据uid计算数据库编号:

分库信息 = (uid / 10) % 8 + 1 
根据uid计算表编号: 
表编号 = uid %10

订单ID

订单系统的ID必须具有全局唯一的特征,简单的方式是利用数据库的序列,每操作一次就能获得一个全局唯一的自增ID,如果支持每秒10w订单,那每秒至少需要生成10w订单ID,通过数据库自增ID显然无法完成上述请求。所以通过内存计算获取全局唯一的订单ID。

JAVA领域著名的唯一ID应该是UUID了,不过UUID太长且包含字母,不适合做订单ID。通过反复比较筛选,借鉴Twitter的算法实现全局唯一ID。

三部分组成:

  • 时间戳

    时间戳的粒度是毫秒级,生成订单ID时,使用System.currentTimerMillis()作为时间戳。

  • 机器号

    每个订单服务器都被分配一个唯一的编号,生成订单ID时,直接使用该唯一编号作为机器即可。

  • 自增序号

    当同一服务器的同一号码中有多个生成订单ID的请求时,会在当前毫秒下自增此序号,下一个毫秒此序号继续同0开始。如同一服务器同一毫秒生成3个订单ID请求,这3个订单ID的自增序号分别是0,1,2。

最终订单结构:

分库分表信息 + 时间戳 + 机器号 + 自增序号

还是按照第一部分根据uid计算数据库编号和表编号的算法,当uid=9527时,分库信息=1,分表信息=7,将他们进行组合,两位的分库分表信息即为”17”。

最终一致性

我们通过对order表uid维度的分库分表,实现了order表的超高并发写入与更新,通过uid和订单ID查询订单信息。

上面方案虽然简单,但是保持两个order表机器的数据一致是很麻烦的事情。两个表集群显然是在不同的数据库集群中,如果写入与更新中引入强一致性的分布式事务,这无疑会大大降低系统效率,增长服务响应时间,这是我们所不能接受的,所以引入了消息队列进行异步数据同步,为了实现数据的最终一致性。

当然消息队列的各种异常会造成数据不一致,所以我们又引入了实时服务监控,实时计算两个集群的数据差异,并进行一致性同步。

数据库高可用

所谓数据库高可用指的是:当数据库由于各种原因出现问题时,能实时或快速的恢复数据库并修补数据,从整体集群角度看,就像没有出任何问题一样,需要注意的是,这里的恢复数据库服务并不一定是指修复原有数据库,也包括将服务切换到另外备用的数据库。

数据库高可用的主要工作是数据恢复月数据修补,一般我们完成这两项工作的时间长短,作为衡量高可用好坏的标准。

我们认为,数据库运维应该和项目组分开,当数据库出现问题时,应由DBA实现统一恢复,不需要项目组操作服务,这样便于做到自动化,缩短服务恢复时间。

如上图所示,web服务器将不再直接连接从库DB2和DB3,而是连接LVS负载均衡,由LVS连接从库。这样做的好处是LVS能自动感知从库是否可用,从库DB2宕机后,LVS将不会把读数据请求再发向DB2。同时DBA需要增减从库节点时,只需独立操作LVS即可,不再需要项目组更新配置文件,重启服务器来配合。

再来看主库高可用结构图:

如上图所示,web服务器将不再直接连接主库DB1,而是连接KeepAlive虚拟出的一个虚拟ip,再将此虚拟ip映射到主库DB1上,同时添加DB_bak从库,实时同步DB1中的数据。正常情况下web还是在DB1中读写数据,当DB1宕机后,脚本会自动将DB_bak设置成主库,并将虚拟ip映射到DB_bak上,web服务将使用健康的DB_bak作为主库进行读写访问。这样只需几秒的时间,就能完成主数据库服务恢复。

组合上面的结构,得到主从高可用结构图:

数据库高可用还包含数据修补,由于我们在操作核心数据时,都是先记录日志再执行更新,加上实现了近乎实时的快速恢复数据库服务,所以修补的数据量都不大,一个简单的恢复脚本就能快速完成数据修复。

数据分级

支付系统除了最核心的支付订单表与支付流水表外,还有一些配置信息表和一些用户相关信息表。如果所有的读操作都在数据库上完成,系统性能将大打折扣,所以我们引入了数据分级机制。

我们简单的将支付系统的数据划分成了3级:

第1级:订单数据和支付流水数据;这两块数据对实时性和精确性要求很高,所以不添加任何缓存,读写操作将直接操作数据库。

第2级:用户相关数据;这些数据和用户相关,具有读多写少的特征,所以我们使用redis进行缓存。

第3级:支付配置信息;这些数据和用户无关,具有数据量小,频繁读,几乎不修改的特征,所以我们使用本地内存进行缓存。

使用本地内存缓存有一个数据同步问题,因为配置信息缓存在内存中,而本地内存无法感知到配置信息在数据库的修改,这样会造成数据库中数据和本地内存中数据不一致的问题。

为了解决此问题,我们开发了一个高可用的消息推送平台,当配置信息被修改时,我们可以使用推送平台,给支付系统所有的服务器推送配置文件更新消息,服务器收到消息会自动更新配置信息,并给出成功反馈。

粗细管道

举个简单的例子,我们目前订单的处理能力是平均10万下单每秒,峰值14万下单每秒,如果同一秒钟有100万个下单请求进入支付系统,毫无疑问我们的整个支付系统就会崩溃,后续源源不断的请求会让我们的服务集群根本启动不起来,唯一的办法只能是切断所有流量,重启整个集群,再慢慢导入流量。

我们在对外的web服务器上加一层“粗细管道”,就能很好的解决上面的问题。

请看上面的结构图,http请求在进入web集群前,会先经过一层粗细管道。入口端是粗口,我们设置最大能支持100万请求每秒,多余的请求会被直接抛弃掉。出口端是细口,我们设置给web集群10万请求每秒。剩余的90万请求会在粗细管道中排队,等待web集群处理完老的请求后,才会有新的请求从管道中出来,给web集群处理。这样web集群处理的请求数每秒永远不会超过10万,在这个负载下,集群中的各个服务都会高校运转,整个集群也不会因为暴增的请求而停止服务。

如何实现粗细管道?nginx商业版中已经有了支持,相关资料请搜索

nginx max_conns,需要注意的是max_conns是活跃连接数,具体设置除了需要确定最大TPS外,还需确定平均响应时间。

时间: 2024-10-13 23:02:13

支付架构的相关文章

第三方支付架构设计之—帐户体系

第三方支付架构设计之-帐户体系 一,      什么是第三方支付? 什么是第三方支付?相信很多人对这个名字很熟悉,不管是从各种媒体等都经常听到,可以说是耳熟能熟.但,如果非得给这个名词总结出一个概念,却发现很难准确和全面的表述清楚.不过关系不大,我们无法给出一个很准确的概念的时候,我们就列举一下实际生活中我们经常使用第三方支付的例子:支付宝,财付通,微信支付等等,这些就是我们国内目前在第三方支付市场中比较有影响力的第三方支付了. 搜索一下百度,所谓第三方支付,就是一些和产品所在国家以及国外各大银

第三方支付架构设计之—自有账户支付

笔者在上一篇blog<<第三方支付架构设计之-帐户体系>>中已经稍微全面的阐述了第三方支付架构设计中的账户体系,在该体系中,其实涉及了各种各样的账户:银行侧账户(包括用户在银行侧的账户:用户借记卡,信用卡,商户在银行侧的清算账户,结算账户等),第三方支付自有账户(跟银行侧账户比较类似,包括用户在第三方支付公司的账户和商户在第三方支付公司的账户)等. 我们知道,第三方支付本身是不直接接触实际资金的,所有的资金流必须走银行系统进行,因此这里涉及到的实际资金流的时候就会把交易请求转接到银

第三方支付架构之账户体系架构设计

参考: [财务]账户体系架构设计相关思路记录 第三方支付架构设计之-帐户体系

每秒处理10万订单乐视集团支付架构

随着乐视硬件抢购的不断升级,乐视集团支付面临的请求压力百倍乃至千倍的暴增.作为商品购买的最后一环,保证用户快速稳定的完成支付尤为重要.所以在15年11月,我们对整个支付系统进行了全面的架构升级,使之具备了每秒稳定处理10万订单的能力.为乐视生态各种形式的抢购秒杀活动提供了强有力的支撑.   一. 分库分表 在redis,memcached等缓存系统盛行的互联网时代,构建一个支撑每秒十万只读的系统并不复杂,无非是通过一致性哈希扩展缓存节点,水平扩展web服务器等.支付系统要处理每秒十万笔订单,需要

基础向:从 0 开始学习支付系统架构

今天为大家带来 Ping++ 高级技术总监--叶波光老师的<支付系统架构详述>.本篇内容由五个部分组成. 1. 架构的定义:架构一定是基于业务功能来展开的,主要是制定技术规范.框架,指导系统落地,好的架构是需要不断演变和进化而来的. 2. 架构需要关注的基础核心点主要是:安全.稳定.可扩展. 3. 构建架构时需要关注的点:目标客户是谁.主要场景有哪些.流程是怎样的.模型.职责有哪些.边界在哪里以及设计.其中比较难以理解的点是困难及模型这两块. 4. 架构与业务需求的关系:架构的产生来自于业务需

互联网金融系列-支付清算体系样例-下

笔者上一篇<互联网金融系列-支付清算体系介绍-上>已经比較全面的介绍了以银联为样例的支付清算体系,为了更好的理解里面的运作.本章以两个样例为重点,全面剖析整个清算的过程. 1,记账原则 这块跟会计相关.不清楚的同学能够先看一下笔者之前的文章<第三方支付架构设计之-账户体系>.在会计学上,须要分清楚一个概念:会计主体.简言之,就是会计信息体现或者代表谁的经济利益,代表给谁做的账.做帐的人不一定是会计主体,比方替别人做帐. 在參与清算的各个主体来说.他们首先须要在央行开立清算账户或者在

乐视秒杀架构解读:从零开始搭建百万每秒订单系统

在各种秒杀活动大行其道的今天,订单系统的性能与稳定日益重要.乐视集团作为这一技术的佼佼者,在多次的电商狂欢节中都能抢占商机.拔得头筹,其表现无疑为其他企业和厂商提供了非常有价值的参考. 在Gdevops全球敏捷运维峰会北京站的现场,乐视BOSS平台技术部架构师梁阳鹤就给大家带来了<从零开始搭建百万每秒订单系统>的精彩演讲.从部分到整体,从微观到宏观,层层递进,步步为营,详尽地介绍了整套乐视支付架构及其实现每秒处理百万笔交易的成功要点. (点击“这里”听梁阳鹤演讲完整录音) 演讲主要分为三个部分

电商峰值系统架构设计--转载

1.1 系统架构设计目录 摘要:双11来临之际,<程序员>以“电商峰值系统架构设计”为主题,力邀京东.当当.小米.1号店.海尔商城.唯品会.蘑菇街.麦包包等电商企业,及商派.基调网络等服务公司,分享电商峰值系统架构设计的最佳技术实践. 自2009年11月11日,淘宝商城(现名天猫)拉开网购狂欢节的序幕,各大电商的促销浪潮此起彼伏.此时的电商大战不仅是价格之争,更是技术的较量.如何设计电商峰值系统来更好地满足用户蜂拥而至的访问,如何在海量数据处理中实时发现有效信息并转化为商机,成为众多电商企业密

互联网金融系列-支付清算体系例子-下

笔者上一篇<互联网金融系列-支付清算体系介绍-上>已经比较全面的介绍了以银联为例子的支付清算体系,为了更好的理解里面的运作,本章以两个例子为重点,全面剖析整个清算的过程. 1,记账原则 这块跟会计相关,不清楚的同学可以先看一下笔者之前的文章<第三方支付架构设计之-账户体系>,在会计学上,需要分清楚一个概念:会计主体,简言之,就是会计信息体现或者代表谁的经济利益,代表给谁做的账.做帐的人不一定是会计主体,比如替别人做帐.在参与清算的各个主体来说,他们首先需要在央行开立清算账户或者在对