电商系统与银行系统对比分析0.3

1、BOC and IBM Confidential1近年来，国内电商业务的快速发展，给电商及银行的核心应用系统带来了巨大的处理压力 2012.11.11 夜间00:00以后，最高TPS达239，较平常日增长64%。全天交易量达3600万 从夜间00:35以后，联机交易响应时间明显增长，前端支付宝相关交易出现超时IBM GBS第1分钟超过1000万人万人涌入天猫一分钟内支付宝交易成功笔数19.219.2万笔10分钟，支付宝总销售额2亿亿5000万万08时16分，支付宝总销售额5050亿亿13时38分，支付宝总销售额100亿亿n 支付宝总销售额 191亿亿n 2.2.亿亿独立用户访问n 支付宝实现成

2、功交易笔数1 亿零亿零580万万笔n 付款峰值20.5万/分钟2012.11.11核心系统交易量及响应时间统计单位:秒淘宝网2012 11.11促销业务统计BOC and IBM Confidential2为支持这种业务量的挑战，电商及类似的网站系统持续进行了大量的系统架构优化IBM GBS1995. eBay成立，时采用CGI编写，数据库采用的是GDBM，最多只能支撑5万件在线商品1997. 1997. FreeBSD迁移到Windows NT，数据库从GDBM迁移为Oracle，前端改造为Cluster，采用Resonate作为负载均衡，后端的Oracle机器升级为Sun E1000小型机

3、，同年给数据库增加了一台机器作为备库，提升可用性1999.1999.达到了瓶颈（已经不能再加CPU和内存了），于是开始将数据库按业务拆分为多个库，随后将数据表进行了水平拆分，例如按类目存储商品2002. 2002. 将整个网站迁移为用Java构建，在这个阶段，做了DAL框架来屏蔽数据库分库分表带来的影响，同时还设计了一个开发框架以供开发人员更好地上手进行功能开发。2003. Taobao成立，直接购买了一个商业的phpAuction的软件，在此基础上改造产生了淘宝。2004. 将系统由PHP迁移到Java，MySQL迁移为Oracle（小型机、高端存储设备），应用服务器采用了WebLogic2

4、005. . 用JBoss替代了WebLogic，对数据库进行了分库，基于BDB做了分布式缓存，自行开发了分布式文件系统TFS以支持小文件的存储，并建设了自己的CDN2007. . 对应用系统进行垂直拆分，拆分后的系统都以Service的方式对外提供功能，对数据采用了垂直和水平拆分。随后开始将数据逐渐从Oracle迁移到MySQL，同时开始尝试新型的数据存储方案(如采用HBase)1997. Google成立，网页内容及索引数据分别分散到多台Index与Doc服务器上。2001. 对Index格式进行修改，并将所有Index放入内存；通过并行处理+sharding 来保证在降低对硬件要求的同时

5、提高响应速度;通过GFS(Google文件系统)来存储大量数据并支持高并发2004. . 再次对Index的格式进行了修改，同时通过替换MapReduce与BigTable使得海量数据的分析能够达到在线系统的要求了，使得网站的响应速度继续提升2007. . 研发Colossus（下一代类GFS文件系统）、Spanner（下一代类BigTable海量存储和计算架构）、实时搜索（基于Colossus实现），主要都是为了提升搜索的实时性以及存储更多数据。可扩展性可扩展性可用性可用性高性能高性能可维护性可维护性低成本低成本注：为方便进行针对性比较，下文中若无特别说明，则电商指注：为方便进行针对性比较，

6、下文中若无特别说明，则电商指“淘宝网淘宝网”BOC and IBM Confidential典型电商架构分析 电电商典型淘宝的架构呈现出以下三个主要特点商典型淘宝的架构呈现出以下三个主要特点 动态、静态内容分离：出于降低带宽压力、提升客户体验的目的，淘宝将动态和静态内容作了切分并将消耗大量带宽的静态内容特别是图片的下载投放到CDN 后端应用架构SOA化：淘宝后端应用完全采用了面向服务的思想进行设计，子系统之间通过完整的服务定义以及高性能的自开发远程服务交互框架进行分布式调用 充分的数据分布式化：为了面对大数据量的处理，在服务化的基础上，淘宝的架构进一步将数据采用分布式存储、缓存的方式在系统内部

7、进行了分布以拥有更好的扩展性3IBM GBS淘宝淘宝客户群客户群网络网络传输传输前端前端应用应用后端后端应用应用DNSDNSABTN网络网络CDN系统系统静态页面图片站点缓存站点缓存店铺商城互动社区无线商品淘淘宝前端应用宝前端应用静态内容静态内容动动态内容态内容核心业务服务核心业务服务数据数据共享服务共享服务数据库数据库服务服务搜索搜索服务服务用户中心商品中心店铺中心交易中心促销中心TFS分布式文件存储DB管理中心分布式缓存MySQLOracle大C搜索实时搜索SPU搜索服务服务调用调用TDDL/读写分离读写分离分发分发索引索引搜索搜索BOC and IBM Confidential4与银行相

8、比，电商的交易具有一致性要求较低，可用性要求均等，吞吐量较大的特点IBM GBS电商基本交易模式网页浏览提交订单订单支付 电电商交易模式的特点分析商交易模式的特点分析 一致一致性：性：电商交易模式中，商品信息中的库存数量、订单提交后是否马上被处理等，都不一定需要实时反映系统的最新情况，除了线上支付部分反映现金、积分等即时增减的项目，电商对于时效性的要求较银行低 可用可用性：性：电商采用浏览器作为基本的访问方式，成千上万的用户同时进行访问，基本的三种交易模式组成了关键的购物流程，流程中任何一个节点的失效将导致订单流失，因此具有极高的可用性要求 高吞吐量高吞吐量: :电商的网页点击率在平时就高达2

9、5亿次每日，其中包含大量的图片等多媒体数据的访问，对于吞吐量有极高的要求 电商用户通过浏览如淘宝包含的海量商品进行商品选择。在浏览过程中，大量的数据被查询及展现。用户还会经常使用搜索功能，通过模糊搜索得到经过排序的搜索结果。这样的搜索通常需要使用到分词、搜索意图分析等搜索引擎技术 当用户浏览完商品并将需要购买的商品从“购物车”中取出结算，系统为用户生成订单，用户通过提交订单完成一次购买行为。订单提交过程中，电商系统需要进行查询客户信息、计算积分、锁定库存等一系列操作 当用户选择在线支付订单，那么电商系统通过将用户引导到特定的支付界面或者银行的支付界面，通过银行等金融机构的接口获取货款，在记录自

10、身内部账务的同时，完成对用户订单状态以及用户信息如积分信息等的更新BOC and IBM Confidential5针对电商系统架构及交易的特点，电商主要从基础设施、数据库与应用设计等方面对其系统架构进行持续优化IBM GBSn数据库：数据同步机制n数据库：数据路由DBRouten应用设计：分布式交易处理模式TCC一致性高吞吐量可用性n基础设施：多层级分布式部署n数据库及应用设计：读写分离n数据库及应用设计：缓存机制n基础设施：多层级分布计部署n基础设施及数据库：自主研发的文件系统及数据库系统n应用设计：异步处理机制BOC and IBM Confidential6基础设施 完全分布式架构设计

11、，去中心化IBM GBS电商系统电商系统 通过完全分布式架构设计，突破了单台主机或数据库计算能力的瓶颈。通过增加/减少服务器的个数，可支持海量交易的处理，并保证了系统处理能力的高扩展性银行系统银行系统Taobao完全分布式架构设计体现在WEB Server, Application Server, Database Server等不同层级均采用分布式部署，并在应用上设计分布式算法（Fourinone）以支持海量数据的分布式计算银行系统相对较为封闭，仅银行内部主机参与存储计算。外围系统的访问与通常也仅限于本系统内部的安全网络BOC and IBM Confidential7基础设施 采用自主研发

12、的文件系统以提高性能IBM GBS电商系统电商系统 TAOBAO存储数据的一个突出特点是单个文件尺寸较小，通常不大于1MB，但是数量巨大，传统的文件系统或者网络存储设备很难解决类似的问题 银行系统为保证应用开发的便利性，通常使用数据库来进行数据存储。部份情况也只使用操作系统的文件系统，不会根据自身的数据要求对文件系统定制 银行系统可借鉴电商的做法，对一些非结构化的数据，使用定制的文件系统来方便存储，并加快处理速度银行系统银行系统 淘宝自主研发TFS(TAOBAO分布式文件系统)，用于存储淘宝网主站的数据，例如商品图片、商品描述、交易快照、社区图片等。 TFS通过扁平化的数据组织结构，抛弃了传统

13、文件系统的目录结构 在块设备基础上建立自有的文件系统，减少EXT3等文件系统数据碎片带来的性能损耗 尽量缩减元数据大小，将元数据全部加载入内存，提升访问速度 基本通过关系型数据库（RDBMS）来进行数据的存储 根据操作系统的不同，联机交易会使用VSAM或UNIX文件来进行少量数据的读取（如参数的读取） 在批处理中，为提高处理效率，部份作业会将数据从数据库导成文件，再对文件进行操作处理BOC and IBM Confidential8数据库 采用读写分离提高数据库处理能力IBM GBS读写分离最根本的思想是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻IO

14、压力： 将应用程序中对数据库的写操作指向主服务器，而将读操作指向从服务器。 当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性 MySQL有自己的同步数据技术。它是通过二进制日志来复制数据。从服务器定时向主服务器请求最新日志，主服务器异步将二进制日志输送给从服务器。 应用程序与多台数据库之间，可以通过MySQL Proxy反向代理解耦。应用程序只需要跟MySQL Proxy 通信即可，而读写分离的工作都由MySQL Proxy 来完成，与此同时，MySQL Proxy 还对多个从服务器实现负载均衡以及可用性检测。 通过MySQL Proxy将读写分离操作从应用程序中进

15、行隔离BOC and IBM Confidential9数据库 读写分离方式比较IBM GBS电商系统电商系统 电商系统通过对数据库的读写分离技术，将客户交易和海量查询进行隔离，从而提高性能，但电商系统对查询结果无法保证实时性（数据同步存在一定时差） 银行系统不对交易行为进行区分，全部使用统一的数据库，虽能保证查询结果的准确性，但存在竞争数据库资源的情况，易造成性能瓶颈 银行可借鉴电商的做法，对业务进行梳理，对查询实时性要求较低的业务可采用读写分离的方式来提高交易处理能力银行系统银行系统 建立主、从数据库，主数据库用于写操作，从数据库只做读取操作 主库的数据在更新后会同步到从库中 复制是异步的

16、，从服务器定时向主数据库服务器请求最新日志，主服务器只需通过一个IO线来读取本地二进制日志，并发送给从服务器。复制过程对主服务器的影响有限 只使用一个主数据库服务 数据的读写在同一数据库的同一表上进行，相互存在竞争。 读写混搭，一次交易过程中不会将读、写处理分散到不同的服务器中分别进行处理。BOC and IBM Confidential10数据库 数据同步IBM GBS 在实现数据库读写分离后，需考虑主数据库数据更新后，如何与从数据库同步的问题。Taobao主要用以下三种工具来实现数据同步： Dbsync：异构数据库之间同步的工具。用于同步服务库数据到HDFS的产品，通过分析数据库服务器的l

17、og文件来提取相应的数据库动作，进而达到数据库到HADOOP的数据同步，供相关部门提取增量数据 Timetunnel：实时数据传输平台。主要功能就是实时完成海量数据的交换，因此TimeTunnel的业务逻辑主要也就有两个：一个是发布数据，将数据发送到TimeTunnel；一个是订阅数据，从TimeTunnel读取自己关心的数据 DataX：一个在异构的数据库/文件系统之间高速交换数据的工具，实现了在任意的数据处理系统(RDBMS/Hdfs/Local filesystem）之间的数据交换，由淘宝数据平台部门完成。 淘宝针对全量与增量数据，分别采用了不同的实时/非实时同步工具 随着银行业务的发展

18、，系统中的数据增量与存量也越来越大。对一些各系统需用到的公用信息（如客户信息），其数据的同步需更好的规划BOC and IBM Confidential数据库 数据分析与展示11IBM GBS业务理解数据理解概念设计交互设计应用开发用 户展示确定指标 数据丰富是电商的最大优势之一。通过对海量用户日志及交易数据的分析，可判断用户的消费偏好及商品的买家地域、年龄、信用等级等各项指标 相对电商，银行具有用户的第一手真实交易信息。在当前利率市场化的背景下，如何快速、准确的对海量数据进行分析，以更好的进行业务营销及客户关系定价，是银行面临的重点课题之一BOC and IBM Confidential12

19、数据库 通过数据库扩展来支持业务量的增长IBM GBS080709集中式集中式垂直拆分垂直拆分水平水平拆分拆分 用户数据 基础数据 业务数据 07年，只有三个主要的数据库，全部在小型机和存储上面 小型机从Unix操作系统到硬件，稳定性都会比PC server其实要高很多，当时的情况下淘宝用小型机是一个非常自然的选择 08年，把三个数据库拆成更多的数据库，或每一个数据库支持一个比较单一的业务 比如用户、商品和交易，都会分成独立的数据库，然后放到独立的小型计算中去(垂直拆分) 09,10年，从业界能看到很多的经验分享，包括eBay、亚马逊这些国外的大公司。水平拆分是淘宝的数据库涨到一定程度后的架构

20、选择 水平拆分后机器、数据库的数量都会多很多，所以从成本考虑的话，小型机和Oracle成本高，自然会选择用PC Server 和MySQL数据库 银行系统的DB2 Data Sharing架构，基本上满足水平拆分架构的超大容量、分散存取的压力瓶颈 电商数据库架构演变：07年开始淘宝的业务量保持每年自然翻一番的增长 前端业务量增长一倍，在数据库上有可能增长是好几倍隔离BOC and IBM Confidential13数据库 数据库扩展在银行的应用IBM GBS电商系统电商系统 电商系统运用分表、分库进行容量的扩展，以及数据垂直的分类，在容量方面得到很好的解决，但必须在应用层配合，发展出DBRo

21、ute来解决分割带来的完整性议题 银行使用主机DB2的数据容量加上分区的技术，可以满足银行目前的数据的扩展需求银行系统银行系统 拆分大字段、分表、分库（垂直、水平分割） 使用多个几个 Oracle 数据库 分库分表 用户的信息按照 ID 来放到两个数据库里面（DB1/DB2） 商品的信息跟着卖家放在两个对应的数据库 商品类目等通用信息放在第三个库里面(DBcommon) 优点：扩展很大的数据容量 缺点：应用程序很麻烦，必须到两个数据库里面分别查询出来对应的商品；要按时间排序必须全部查出来在应用程序里面做合并；还有分页怎么处理？关键字查询怎么处理？ 解法：发展数据库路由的框架 DBRoute 为

22、保持数据的一致性、完整性与易维护性，账务与查询数据基本上是只有一份，比如表中集中存放相应主体的数据（如存款账户主表INVM等） 主机DB2数据库的数据容量极大，不需要因容量缘故去拆分，减少分散式数据库的问题 DB2数据库分区技术，相同的表信息存放在一个表的不同分区，对于应用处理是透明的，不需要在应用中去考虑数值的位置 BOCS少部分表也采取分表设计，根据不同特性数值分布到分表BOC and IBM Confidential14数据库 数据库扩展带来的数据库的一致性问题（ACID vs BASE）IBM GBS电商系统电商系统 问题：ACID原则适用于互联网应用吗？可用性似乎比一致性重要些。 B

23、ASE策略与ACID不同，其基本思想就是通过牺牲强一致性，以获得更好的可用性或可靠性银行系统银行系统n ACID（ Atomicity 、 Consistency 、 Isolation 、 Durability ）是关系型数据库的最基本原则，遵循ACID原则强调一致性，对成本要求很高，对性能影响很大。n 银行系统的业务特性，一致性比可用性更重要，必须符合ACID的要求。BASE策略: Basically Available Soft state Eventually consistentBOC and IBM Confidential银行系统银行系统15数据库 采用NOSQL（Not Onl

24、y SQL 不仅仅是SQL）提高处理能力IBM GBS 可借鉴电商的做法，对不同的数据类型采取不同的存储及处理方式电商系统电商系统 网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。 对于大型的电商网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。 NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。No

25、SQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同银行通常采用关系型数据库来进行数据的存储 由于银行业务对于数据库事务的一致性，以及数据库读写的实时性，要求进行数据库事务管理 目前银行应用中，仍存在一定的大表关联查询，以及复杂的数据分析类型的复杂SQL报表查询，给系统性能及稳定性造成了隐患Taobao为应对数据库高并发读写的需求，同时满足海量数据的存储，采用NOSQL数据存储方式BOC and IBM Confidential16数据库 可扩展关系型数据库OceanBaseIBM GBS 数据表存储

26、形式数据表存储形式：OceanBase的主键采用二进制字符串，表数据按主键值范围切分为多个Tablet块按主键顺序存放 存储数据划分：存储数据划分：增删改的数据称为动态数据(通常在内存，也称为内存表)，以增量方式记录；一段时间内相对稳定的主体数据称为基准数据 ChunkServer：用于保存基准数据的服务器，通常是多台，从而避免软件硬件故障导致的服务 UpdateServer：保存动态数据的服务器 MergeServer：进行静动态数据合并的服务器，使得用户能够访问到完整的最新的数据 RootServer：记录commit log并通常采用双机热备 淘宝根据自身数据的特点，设计了支持海量数据的

27、分布式数据库系统，实现了数千亿条记录、数百TB数据上的跨行跨表事务 银行在目前使用的RDBMS基础上，可考虑根据自身数据类型的特点，设计自已的数据存储方式BOC and IBM Confidential17应用设计 采用基于SOA的HSF服务框架（淘宝远程服务调用框架）IBM GBS 银行应用基本上还停留在CALL公共函数 / 公共模块阶段，SOA的服务化程度较低 服务化过程本身并不容易，要求对业务、技术的高度理解及归纳。银行业务纷繁复杂，其概念化、抽象化过程相比淘宝网站复杂度更高，因此，银行应用的标准服务化是一个长期的渐进过程。但SOA服务化将给银行应用的开发、部署模式，业务服务水平带来极大

28、的便利调用者调用者服务提供者服务注册查找中心异步通信服务服务提供者 淘宝HSF遵循SOA框架体系开发，是淘宝网站成熟服务化过程中最重要的基础性支撑框架，是其网站能够承受每日巨大用户访问压力仍能从容扩展的关键因素之一 大规模使用HSF，服务化相对成熟之后淘宝网站变得：前端应用高度分化，拆分成一个个功能单一的应用系统，后端服务化接口也划分的较细，同时针对不同业务和具体的技术实现做个性化优化，增强了各个节点的健壮性，高效性 淘宝HSF给整个系统架构带来的好处： 应用间的耦合降低：在服务化接口成熟的情况下，扩展新的业务需求变得方便，主要就是一个组合服务化接口的过程 开发人员可以专心关注业务，而不用考虑

29、分布式领域中的各种细节技术，例如远程通讯、性能损耗、调用的透明化、同步/异步调用方式的实现等等问题 各个系统负责的业务更纯粹，方便做针对新的性能调优和功能改进：如容灾性，并发，监控等方面的优化。这种针对性有助于增强系统的高性能，高健壮BOC and IBM Confidential银行系统银行系统18应用设计 为保证分布式事务完整性而设计的TCC交易模式IBM GBS 为节省协议成本，通过自主开发的TCC机制实现跨数据库的事务完整性和一致性处理电商系统电商系统 一个完整的业务活动由一个主业务服务与若干从业务服务组成。主业务服务负责发起并完成整个业务活动，从业务服务提供TCC型业务操作 业务活动

30、管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交 时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作 Try: 尝试执行业务：尝试执行业务：完成所有业务检查(一致性)，预留必须业务资源(准隔离性) Confirm:确认执行业务确认执行业务：真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源 Cancel: 取消取消执行业务执行业务：释放Try阶段预留的业务资源 启动业务活动 登记业务操作 提交/回滚业务活动主业务服务主业务服务业务活动业务活动管理器管理器从从业业务务服服务务TryConfirmCancelLOG数

31、据库数据库数据库数据库数据库数据库数据库数据库对于分布式事务，通过CICS等中间件来实现两阶段提交（Two Phase Commit）或DTP模型 存在一定的协议成本（包括准备阶段与全局事务状态的持久成本） 准备后，提交前的故障引发一系列隔离与恢复难题BOC and IBM Confidential19应用设计 采用大量异步处理以使得系统具有更高的吞吐能力IBM GBS电商系统电商系统 银行可以考虑两方面的异步化处理 部分业务流程异步化：银行可以根据业务流程特性，将业务流程中可以异步完成的步骤异步完成，如会计分录的记录等，以增加交易性能 交易处理完全异步化：对于资源消耗较大的交易（如大数据量的

32、查询等）进行异步化处理，请求发起方提交查询请求并在一段时间后查看查询结果银行系统银行系统商品信息异步异步订单审核库存锁定分布式存储异步异步订单库商品浏览商品浏览订单提交订单提交订单支付订单支付电商交易路径上尽可能地利用异步处理，来降低对系统的负载，但涉及到金额的操作则使用同步以保证一致性典型的银行交易中，每一个步骤都需要同步的返回以保证一致性，如上述典型的开户交易，存款需要开户的生效，余额查询需要存款的生效开户存款余额查询同同步步前端核心BOC and IBM Confidential20应用设计 7x24设计IBM GBS电商系统电商系统 银行可考虑将部分参与批量的数据在数据抄写机制下，向其

33、他库进行复制，设置两个复制库，在开始批量时，通过控制时机，将主库向其一个复制库的抄写转向另一库，那么后续的批量作业能够在数据静止的那个复制库上进行，避免干扰联机交易的运行银行系统银行系统实时数据实时数据准实时数据准实时数据批量数据批量数据报表报表BI电商由于不涉及到复杂的计息及计费等处理。并且电商系统设计上已经做了充分的数据分布，因此批量完成相对简单实时数据实时数据批量数据批量数据 银行出于在多个系统间交换大量数据、生成统计报表等原因，在夜间会进行批量数据处理操作。批量往往对于具有较高的负载，同时会要求某些数据静止，因此会影响非批量的交易，因此核心系统通常设计有特别的机制来使得交易服务的连续提

34、供，并且由于批量过程中对其它系统的数据交换会影响第二天的业务，批量往往具有很严格的时间要求。银行在批量期间所处理的数据基本上都是采用数据库技术通过UNLOAD等方式直接抓取的实时数据，为了避免对还在进行交易的影响，银行批量需要经过复杂设计BOC and IBM Confidential21应用设计 动、静态资源分离IBM GBS 对银行而言，只是被查询、不再被更新的数据可认为是静态资源，例如交易日志、账户日志；尚处于持续更新的数据可认为是动态资源，例如客户信息、账户信息 对银行的动、静态资源可考虑分别提供服务能力，避免静态资源的服务影响到对动态资源的服务性能。例如，可考虑将超过1年的历史账户交

35、易日志的查询和日常核心业务处理区分开，单独部署一套查询系统，避免占用日常核心业务处理能力BrowserWebServerWebServer静态资源动态资源ApplicationServer 页面中规划好静态、动态资源区域。静态资源区域放置相对不变的文本、图形图像、视频等信息；动态资源区域放置需和用户随时交互变化更新的信息 动态、静态资源区域分别连接独立的Web Server处理页面请求DBServerBOC and IBM Confidential数据库缓存应用缓存公共网络缓存应用设计 - 电商如淘宝通过在交易路径上设置多级缓存以增加性能 总体而言，电商在交易路径上设置了四道缓存 电商外部：电

36、商外部：通过设置静态内容的过期时间来使用了一部分的浏览器缓存，同时通过使用CDN来缓存大量的静态内容在公共网络上 电商电商内部：内部：对于需要动态生成的内容，以及在电商系统内部各个有调用关系的子系统之间，电商在应用以及数据库上设置缓存，如WebService 的返回对象以及数据库查询结果以提升性能22IBM GBS电商内部（主要对动态内容进行缓存）浏览器缓存CDN电商外部（主要对静态内容进行缓存）BOC and IBM Confidential应用设计 - 通过CDN技术提高用户访问网站的响应速度 CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现

37、有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络边缘，使用户可以就近取得所需的内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。 (也就是一个服务器的内容，平均分部到多个服务器上，服务器智能识别，让用户获取离用户最近的服务器，提高速度23IBM GBS 所需的资源不在缓存里，需回源站抓取 所需的资源在缓存里，直接返回给用户缓存服务器BOC and IBM Confidential应用设计 淘宝通过Tair（分布式缓存）+MySQL/Oracl

38、e的两级缓存，形成其内部缓存机制，提升访问性能 24IBM GBS核心业务服务核心业务服务数据数据共享服务共享服务数据库数据库服务服务用户中心商品中心店铺中心交易中心促销中心TFS分布式文件存储DB管理中心分布式缓存MySQLOracleTDDL/读写分离读写分离外外部部调调用用淘宝后端服务系统群淘宝后端服务系统群以淘宝为例，它的后端服务系统群中有一部分数据共享服务，专门用来给予外部系统以及后端其他系统数据访问服务，它基于分布式缓存产品Tair，Tair通过将缓存数据以键值对的形式分布式地存储在多台服务器上，使得缓存数据的访问和维护十分的高效和可靠作为快速分布式缓存Tair的后端，数据库服务的

39、MySQL和Oracle通过使用数据库缓存BufferPool，缓存数据和索引信息，提升了数据库的访问性能。同时，到数据库的持久化应用设计也做了特殊的处理，对于应用缓存中的数据的变更以异步方式写入数据库，同时较少应用与数据库的压力 对于银行系统来说，由于数据的准确性要求非常高，可以放入缓存中的数据种类也比较有限。缓存较多的如静态的参数信息等。可考虑将一些实时性要求不高的业务查询结果放入缓存，以提高常见查询的交易性能BOC and IBM Confidential25应用设计 模糊查询解决方案IBM GBS 根据电商的经验，读写分离以及业务控制是提升模糊查询的性能或者减少模糊查询对正常交易性能影

40、响的惯常方法。银行一般尽可能地实现了业务控制，而在加入读写分离，并对读库进行分布化的数据存储后，采用更新的数据库技术进行查询，以获得较高的模糊查询性能。联机购物流程联机购物流程核心业务服务核心业务服务数据基础服务数据基础服务搜索服务搜索服务TDDL读写分离读写分离分布式数据存储分布式数据存储DUMP、BUILD、分发索引文件分发索引文件外部用户通过输入商品搜索条件，淘宝的搜索服务对其进行分词，并对分词结果进行搜索意图分析，最后从基于分布式数据存储获取搜索结果进行展示内部用户的查询请求通常为对于商品、外部用户等信息的查询，已经使用读写分离来保证联机交易性能。通过指定搜索的类型和范围预先生成搜索结果以提升性能。外部用户对于交易记录、付款记录等信息的查询已经通过读写分离在查询库上进行操作，同时查询记录通过精准查询进行了限制BOC and IBM Confidential26应用设计 提高查询搜索的客户体验IBM GBS电商系统电商系统 电商系统通过主搜索系统，为用户提供统一的查询入口，为用户提供灵活查询功能 后台搜索引擎根据用户输入关键字或输入的数字特点，自动调用后台相关交易，从数据库或缓存中返回匹配信息银行系统银行系统 提供统一的查询入口，一般在首页设置搜索框，允许用户输入各种查询关键词 主搜索系统根据输入关键词，进行分词操作，并分析用户搜索意