统一结算数据存储方案-京东内部分享.docxVIP

北京市宏观经济与社会发展基础数据库一期工程项目 技术文件 平台架构部 第 PAGE ii页 平台架构部 统一结算项目 数据存储方案 部 门：平台架构部 编写人： 核准人： 日 期： 技术方案 CRM项目技术方案 平台架构部 第 PAGE i页 目录 TOC \o 1-3 \h \z \u 1 统一结算数据存储方案 2 1.1 背景介绍 2 1.2 总体方案 3 1.3 生产库数据库产品选型及部署方案 4 1.4 历史数据库部署方案 5 1.5 数据访问服务功能描述 6 1.6 数据交换平台需完善的功能 6  技术方案 平台架构部 第 PAGE 6页 统一结算数据存储方案 平台架构部 第 PAGE 2页 统一结算数据存储方案 背景介绍 随着网上支付平台瓶颈打破，近年来B2C电子商务发展异常迅速，支付结算也越来越成为电子商务一个非常重要环节，这个环节在用户体验方面占有相当大比重，准确高效的支付结算体系将在用户保留以及提高用户忠诚度方面起到至关重要的作用。 统一结算项目主体功能如下： 前台支付流程优化 单笔订单多次支付 多笔订单合并支付并分多次跨平台支付 不允许客户多支付 增加月结用户合并支付功能 支票支付订单可以输入支票号 余额和礼品卡选择仍放在提交订单之前，但余额和礼品卡需按虚拟银行管理 先款订单付款后允许修改，遇订单部分缺货时按照拆单后退款的方式实现 订单支付确认 银行自动对账 实现部分平台银行资金对账的流程简化 银行对账单导入 生成余额调节表以便于后续处理过程 银行对账的入口统一，按平台收款、对公账户和货到收款分权限管理 数据量静态分析： 按照公司总体战略规划及业务增长预测，2012年下半年公司生产能力将达到并突破百万订单，假定统一结算项目生命周期3-5年及公司业务增长率200%/年，每年对统一结算核心数据表的压力预测如下表所示： 表名 2012年底 120万单/天 2013年底 260万单/天 2014年底 400万单/天 收款单 180万条/天 390万条/天 600万/天 结算单 240万条/天 520万条/天 800万/天 结算单明细 300万条/天 650万条/天 1000万条 订单结算成功记录 120万条/天 260万条/天 400万条/天 总体数据量预测 930万条/天 2000万条/天 3100万条/天 由上表的推算可知，对收款、结算及结算明细和订单结算等大数据量业务表存储及查询处理的好坏直接影响到系统稳定、高效的运行。由于统一结算业务是订单流程业务处理流程中的重要业务环节，该系统的稳定将直接影响整体业务的稳定性和客户满意度。 总体方案 数据存储总体方案图 数据存储总体方案如上图所示，总体上分为Web服务层、数据层和数据交换平台构成。主体功能描述如下： 按照系统应用优化原则，在数据层面将数据存储分为生产数据存储服务和历史数据查询服务两大DB服务体系，以订单结算为界。即：生产库中主要存储订单未结算前的结算信息并保留一个月订单结算信息；订单结算后的信息通过数据交换平台同步到历史库中。 基于现有的数据交换平台和ETL服务，将生产数据定期推送到BI中，支撑统一结算系统的报表分析服务。 在Web服务层中，构建统一的数据访问层，通过提供生产库连接服务、历史库连接服务、BI访问服务、生产数据存储服务、数据查询路由服务以及生产/历史数据查询等服务，支撑（统一结算）系统对其他系统所提供的WebService服务、对用户的各项业务操作及查询统计分析功能。 生产库数据库产品选型及部署方案 鉴于统一结算系统的重要性、系统数据处理的复杂性和高效性要求，参照国内同行业经验，建议生产数据库选择Oracle产品。部署模式建议采用RAC方式，分析如下： 优势分析：RAC优势主要表现在如下几个方面 高可用性：RAC技术能保证不会出现单点故障时导致的系统崩溃。在RAC环境中，任何一个节点的宕机，RAC会自动将该节点正在处理的业务和数据库连接透明地故障切换（Fail-over）到其他正常工作的节点。除非所有的节点均出现宕机，才会导致业务中断，系统崩溃。这种高可用性对统一结算系统是至关重要的。 高性能和高吞吐量：RAC的并行性能使更多的应用系统运行在多个节点之上，合理的应用设计和实施策略能保障系统的并发访问量和吞吐量大大提高。另外，针对一些大型的事务处理，如一些涉及多个表连接的查询计算，RAC不仅能利用节点内的并行处理能力，而且能利用集群系统中所有节点的并行处理能力，甚至于进行动态的并行处理。 可扩展性：RAC能使系统随着应用的增长，在纵向上增加CPU和内存，在横向上灵活