支付系统由于本身和金融相关，不像其他高频系统面对海量请求可以大量使用缓存，异步mq等方式解决三高问题。支付系统对数据一致性要求更高，所以对于其架构设计原则还是有自己特点的。
构建一个支撑每秒十万只读系统并不复杂，无非是通过一致性哈希扩展缓存节点，水平扩展web服务器等。每秒钟数十万数据更新 *** 作，在任何数据库上都是不可能的任务，首先需要对订单表进行分库分表。
在进行数据库 *** 作时，一般会用ID（UID）字段，所以选择以UID进行分库分表。
分库策略我们选择了“二叉树分库”，所谓“二叉树分库”指：在进行数据库扩容时，以2倍数进行扩容。比如：1台扩容2台，2台扩容4台，以此类推。最后把Order库分了8个库中，每个库10个表。
根据uid计算数据库编号：
分库信息 = (uid / 10) % 8 + 1
根据uid计算表编号：
表编号 = uid %10
订单系统的ID必须具有全局唯一的特征，简单的方式是利用数据库的序列，每 *** 作一次就能获得一个全局唯一的自增ID，如果支持每秒10w订单，那每秒至少需要生成10w订单ID，通过数据库自增ID显然无法完成上述请求。所以通过内存计算获取全局唯一的订单ID。
JAVA领域著名的唯一ID应该是UUID了，不过UUID太长且包含字母，不适合做订单ID。
通过反复比较筛选，借鉴Twitter的算法实现全局唯一ID。
三部分组成：
最终订单结构：
分库分表信息 + 时间戳 + 机器号 + 自增序号
还是按照第一部分根据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级：
使用本地内存缓存有一个数据同步问题，因为配置信息缓存在内存中，而本地内存无法感知到配置信息在数据库的修改，这样会造成数据库中数据和本地内存中数据不一致的问题。
为了解决此问题，我们开发了一个高可用的消息推送平台，当配置信息被修改时，我们可以使用推送平台，给支付系统所有的服务器推送配置文件更新消息，服务器收到消息会自动更新配置信息，并给出成功反馈。
举个简单的例子，我们目前订单的处理能力是平均10万下单每秒，峰值14万下单每秒，如果同一秒钟有100万个下单请求进入支付系统，毫无疑问我们的整个支付系统就会崩溃，后续源源不断的请求会让我们的服务集群根本启动不起来，唯一的办法只能是切断所有流量，重启整个集群，再慢慢导入流量。
我们在对外的web服务器上加一层“粗细管道”，就能很好的解决上面的问题。
请看上面的结构图，http请求在进入web集群前，会先经过一层粗细管道。入口端是粗口，我们设置最大能支持100万请求每秒，多余的请求会被直接抛弃掉。出口端是细口，我们设置给web集群10万请求每秒。
剩余的90万请求会在粗细管道中排队，等待web集群处理完老的请求后，才会有新的请求从管道中出来，给web集群处理。
这样web集群处理的请求数每秒永远不会超过10万，在这个负载下，集群中的各个服务都会高校运转，整个集群也不会因为暴增的请求而停止服务。
如何实现粗细管道？nginx商业版中已经有了支持，相关资料请搜索
nginx max_conns，需要注意的是max_conns是活跃连接数，具体设置除了需要确定最大TPS外，还需确定平均响应时间。
问题一：网上支付系统由哪些组成？ 网上支付系统含义支付系统(Payment System)可以定义为由提供支付服务的中介机构、管理货币转移的法规以及实现支付的技术手段共同组成的，用来清偿经济活动参加者在获取实物资产或金融资产时所承担的债务的系统。因此，支付系统是重要的社会基础设施之一，是社会经济良好运行的基础和催化剂。
电子支付的体系构成
1、消费者：在网上选定商品，确认订单后进入电子支付环节。消费者需要拥有电子支付工具。
2、网上商城：电子支付的接受方。网上商城需要有各个银行的账号，网上商城可以搭建自己的支付平台，也可租用第三方支付平台，请同学说出有哪些专业的第三方支付平台。
3、消费者开户银行
4、商城收单银揣
5、银行专用网：银行之间进行通信和数据处理的专用网络。如中国国家金融通信网。
6、支付网关：公用互联网平台和银行专用网之间的安全接口。
7、CA认证中心：第三方公证机构，是电子商务市场的准入者和规范者，它的作用与工商局类似。
网上支付系统的功能：
1、实现对各方的认证；
2、对业务进行加密；
3、确认业务的完整性
4、保证业务的不可否认性；
5、处理贸易业务的多边支付问题。
问题二：网上支付系统由哪几个基本部分构成 电子支付的体系构成 1、消费者：在网上选定商品，确认订单后进入电子支付环节。消费者需要拥有电子支付工具。 2、网上商城：电子支付的接受方。网上商城需要有各个银行的账号，网上商城可以搭建自己的支付平台，也可租用第三方支付平台，请同学说出有哪些专业的第三方支付平台。 3、消费者开户银行 4、商城收单银行 5、银行专用网：银行之间进行通信和数据处理的专用网络。如中国国家金融通信网。 6、支付网关：公用互联网平台和银行专用网之间的安全接口。 7、CA认证中心：第三方公证机构，是电子商务市场的准入者和规范者，它的作用与工商局类似。 网上支付系统的功能： 1、实现对各方的认证； 2、对业务进行加密； 3、确认业务的完整性 4、保证业务的不可否认性； 5、处理贸易业务的多边支付问题。
问题三：支付系统是什么？ 支付系统实际上也可以称作第三方支付系统，支付系统有自己的一套客户/账户/账务体系，用于记录各个客户/商户的基本信息、账户信息、账务信息。支付系统基本信息包括实名认证信息、联系方式等等信息。账户信息比较重要的属性是账户资金/余额，此处的账户资金实际上只是虚拟账户的资金信息，并非实际的资金，实际的资金存放在支付平台在银行设立的银行账户上。
支付系统工具（智付、微信、支付宝等等等）有电子钱包 ，在线支付，移动支付，跨境结算，电子收款，扫码支付，xyk支付，转移支付，跨境结算等各种网上支付方式。简单说来，支付系统的账户体系实际上用于记录每一个客户/商户的账户资金等虚拟信息。
关于支付系统账户/账户体系，一般有单式记帐法、复式记账法，关于账户/账务系统的设计具体原理可以找一本《会计学原理》好好学习一下，琢磨清楚科目设置、账户、流水分录、账簿、复式记账法之类概念，再结合交易订单处理，基本上就可以做出一个简单的账户/账务系统。当然一般所说的账户/账务体系，实际上还涉及客户/商户模型，以满足“客户为中心”而非“账户为中心”的管理需求。
问题四：网上支付系统由哪几个基本部分构成？ 这样的问题，我建议你问问老师或是其他能够理解的同学。这样才是真正的能够掌握的途径，可以一次性的‘会’，不如一直的‘会’
这样可以么？
问题五：一般的移动支付系统由什么组成 翼海就是一个系统的第三方支付，安全稳健！
问题六：电子商务支付系统的组成元素有哪些？ 不要被哪些编概念的SB弄糊涂了，国内的电子商务本身就是刚起步，当然，全世界也不见得说一件很成熟了，（任何一个成熟的商务模式都不可能长时间的存在爆发性发展，这和发展中国家和发达国家的区别一样，愈成熟愈趋于稳定）。在不成熟的状态下大家都在摸索，很多人就会乘这个机会倒卖概念。 实际上支付方式就那么几个，谈不上“模式”，第三方中介担保（支付宝、财付通）、直接付款(货到付款、转账汇款)、预付款（充值消费）。 电子支付模式可以应用到电子商务支付模式，但是不能转变。
问题七：电子支付系统的组成内容 电子支付系统是实现网上支付的基础.电子支付系统的发展方向是兼容多种支付工具,但目前的各种支付工具之间存在较大差异,分别有自己的特点和运作模式,适用于不同的交易过程.因此当前的多种电子支付系统通常只是针对某一种支付工具而设计的.Mondex系统、First Virtual系统和FSTC系统是目前使用的几种主要的电子支付系统。支付系统是指由提供支付服务的中介机构、管理货币转移的法规以及实现支付的技术手段共同组成的，用来清偿经济活动参加者在获取实物资产或金融资产时所承担债务的一种特定方式与安排。因此支付系统是重要的社会基础设施之一。各种不同的支付系统通常是与各种不同的经济相联系在一起的。经济社会曾经使用过各种形态的货币在商品交换中转移价值。从最初的实物交换发展到商品货币（例如贵金属）标志着社会生产力的进步。而法定货币的出现则是支付工具发展史上的第一次飞跃，银行存款作为支付手段是货币制度的一大进步。用电子形式的支付工具完全取代纸凭证形式的现金和非现金支付工具在技术上是完全可以实现的。人们把电子支付工具看成是支付工具发展史上第二次飞跃或革命。网上支付是电子支付系统的发展和创新。传统的银行结算支付指令的传递完全依靠面对面的手工处理和经过邮政、电信部门的委托传递，因而存在着结算成本高、凭证传递时间长、在途资金占压大、资金周转慢等问题。电子资金转账系统缩短了银行之间支付指令的传递时间，并减少了在途资金的占压。基于互联网的电子交易支付系统由客户、商家、认证中心、支付网关、客户银行、商家银行和金融专用网络七个部分组成。 指POSEFT和ATM系统，其支付工具为yhk（xyk、借记卡或ATM卡、电子现金等）。主要特点是金额小、业务量大，交易资金采用净额结算（但POSEFT和ATM中需要对支付实时授信）
问题八：什么是POS系统？它由哪些部分组成 ，
问题九：电子商务系统主要由哪几上部分组成 电子商务系统的基础平台一般包括以下组成部分 ：
(1)负荷均衡 负荷均衡是指如何使电子商务系统服务器的处理能力和承受能力的压力保持均衡 。
负荷均衡还可以对服务器集群结构中的各个服务器性能进行动态调整和负荷分配。它使电子商务系统中硬件性能得到有效的均衡，避免特定的设备或系统软件由于压力过大而出现崩溃和拒绝服务的现象。这样在一定程度上能够提高系统的可靠性。
(2)连接/传输管理 这一部分的主要作用是满足系统可扩充性的需要，用以实现电子商务系统和其他系统之间的互联以及应用之间的互 *** 作。
一般来讲，这一部分包括三个方面的内容： 异构系统的连接及通讯，例如UNIX系统上的WEB服务器与IBM ES9000之间的连接。
应用间的通信接口，保证应用程序通过不可靠信道连接进行时，可以完成差错恢复及续传，并为应用之间的互 *** 作提供API接口，简化应用通信的开发工作。
应用和数据库的连接之间的接口。
(3)事务管理
电子商务系统支持的商务活动涉及到大量的联机事务处理OLTP和OLAP，这就要求系统具备很强的事务处理性能。事务管理的作用包括量方面，一是保证分布式环境下事务的完整性、一致性和原子性二时缩短系统的响应时间，提高交易过程的实时性。
(4)网站管理 网站是电子商务系统的客户服务接口，用于表达系统商务逻辑的处理结果。所以，在电子商务系统中，网站具有重要的地位。
网站管理的基本作用是为站点维护、管理和性能分析提供技术支持手段，它主要实现系统状态的监控、系统性能调整、用户访问授权、客户访问历史记录等功能。
通过网站管理功能，可以记录客户的访问数据，了解用户的需求。利用这些数据，企业能够了解客户的潜在需求。
(5)数据管理 该部分为电子商务应用相关数据的存储、加工、备份和表达提供支持，同时为应用程序提供应用开发接口。
通常该部分利用支持WEB的数据库管理系统实现。但是与传统的DBMS相比，该部分与WEB的接口方式更加丰富，例如支持API、JDBC、ODBC等接口方式，而且对多媒体数据的支持能力更强。
除利用传统的DBMS实现数据管理外，目前也又一种做法是将WEB和DBMS更紧密的结合起来，构造所谓的WebDB。例如，在CA公司的产品Justme-I中，就将应用平台和数据库集成为一体。
(6)安全管理 该部分为电子商务系统提供安全可靠的运行环境、防止或减少系统被攻击的可能、提高系统抗拒非法入侵或攻击的能力、保障联机交易过程的安全。
问题十：人民币支付清算系统的主要构成 五百
支付管理系统的功能性需求主要包括用户登录、数据的明细查询、查询结果生shx2成Excel文件、增添数据、文件数据批量入库、订单丢失扫描等非功能性需求主要包括界面的布局设定、登录用户权限管理、防SQL注入、防命令注入等。按照用户需求，对该系统进行总体设计。通过公司的设计规范，对系统的运神华科技营平台、数据库以及前端界面布局等多个模块进行设计。完成设计之后，利用PHP语言代码与图片展示，详细的介绍了如何逐步实现系统的功能性需求与非功能性需求。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）