平台体系构架

1、电子商务平台构架一、设计理念空间换时间1）多级缓存，静态化客户端页面缓存（httpheader中包含Expires/CacheofControl,lastmodified（304,server不返回body，客户端可以继续用cache，减少流量），ETag）反向代理缓存应用端的缓存（memcache）内存数据库Buffer、cache机制（数据库，中间件等）2）索引哈希、B树、倒排、bitmap哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。B树索引适合于查询为主导的场景，避免多次的10,提髙查询的效率。倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用

2、在搜索领域。Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。并行与分布式计算1）任务切分、分而治之（MR）在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffleandsort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。2)多进程、多线程并行执行(MPP)并行计算(ParallelComputing

3、)是指同时使用多种计算资源解决计算问题的过程，是提高计算机系统计算速度和处理能力的一种有效手段。它的基本思想是用多个处理器/进程/线程来协同求解同一问题，即将被求解的问题分解成若干个部分，各部分均由一个独立的处理机来并行计算。和MR的区别在于，它是基于问题分解的，而不是基于数据分解。多维度的可用负载均衡、容灾、备份随着平台并发量的增大，需要扩容节点进行集群，利用负载均衡设备进行请求的分发；负载均衡设备通常在提供负载均衡的同时，也提供失效检测功能；同时为了提高可用性，需要有容灾备份，以防止节点宕机失效带来的不可用问题；备份有在线的和离线备份，可以根据失效性要求的不同，进行选择不同的备份策略。读写

4、分离读写分离是对数据库来讲的，随着系统并发量的增大，提髙数据访问可用性的一个重要手段就是写数据和读数据进行分离；当然在读写分离的同时，需要关注数据的一致性问题；对于一致性的问题，在分布式的系统CAP定量中，更多的关注于可用性。依赖关系平台中各个模块之间的关系尽量是低耦合的，可以通过相关的消息组件进行交互，能异步则异步，分清楚数据流转的主流程和副流程，主副是异步的，比如记录日志可以是异步操作的，增加整个系统的可用性。当然在异步处理中，为了确保数据得到接收或者处理，往往需要确认机制（confirm、ack）。但是有些场景中，虽然请求已经得到处理，但是因其他原因（比如网络不稳定），确认消息没有返回，

5、那么这种情况下需要进行请求的重发，对请求的处理设计因重发因素需要考虑幂等性。4）监控监控也是提高整个平台可用性的一个重要手段，多平台进行多个维度的监控；模块在运行时候是透明的，以达到运行期白盒化。伸缩1）拆分拆分包括对业务的拆分和对数据库的拆分。系统的资源总是有限的，一段比较长的业务执行如果是一竿子执行的方式，在大量并发的操作下，这种阻塞的方式，无法有效的及时释放资源给其他进程执行，这样系统的吞吐量不高。需要把业务进行逻辑的分段，采用异步非阻塞的方式，提高系统的吞吐量。随着数据量和并发量的增加，读写分离不能满足系统并发性能的要求，需要对数据进行切分，包括对数据进行分库和分表。这种分库分表的方式

6、，需要增加对数据的路由逻辑支持。2）无状态对于系统的伸缩性而言，模块最好是无状态的，通过增加节点就可以提高整个的吞吐量。优化资源利用1）系统容量有限系统的容量是有限的，承受的并发量也是有限的，在架构设计时，一定需要考虑流量的控制，防止因意外攻击或者瞬时并发量的冲击导致系统崩溃。在设计时增加流控的措施，可考虑对请求进行排队，超出预期的范围，可以进行告警或者丢弃。2）原子操作与并发控制对于共享资源的访问，为了防止冲突，需要进行并发的控制，同时有些交易需要有事务性来保证交易的一致性，所以在交易系统的设计时，需考虑原子操作和并发控制。保证并发控制一些常用高性能手段有，乐观锁、Latch、mutex、写

7、时复制、CAS等；多版本的并发控制MVCC通常是保证一致性的重要手段，这个在数据库的设计中经常会用到。3）基于逻辑的不同，采取不一样的策略平台中业务逻辑存在不同的类型，有计算复杂型的，有消耗IO型的，同时就同一种类型而言，不同的业务逻辑消耗的资源数量也是不一样的，这就需要针对不同的逻辑采取不同的策略。针对IO型的，可以采取基于事件驱动的异步非阻塞的方式，单线程方式可以减少线程的切换引起的开销，或者在多线程的情况下采取自旋spin的方式，减少对线程的切换（比如oraclelatch设计）；对于计算型的，充分利用多线程进行操作。同一类型的调用方式，不同的业务进行合适的资源分配，设置不同的计算节点数

8、量或者线程数量，对业务进行分流，优先执行优先级别高的业务。4）容错隔离系统的有些业务模块在出现错误时，为了减少并发下对正常请求的处理的影响，有时候需要考虑对这些异常状态的请求进行单独渠道的处理，甚至暂时自动禁止这些异常的业务模块。有些请求的失败可能是偶然的暂时的失败（比如网络不稳定），需要进行请求重试的考虑。5）资源释放系统的资源是有限的，在使用资源时，一定要在最后释放资源，无论是请求走的是正常路径还是异常的路径，以便于资源的及时回收供其他请求使用。admirL/GonfigrnonitorF5斗囲l-lginxrJSlvarniishCDMLB/Praxy/CachfiApp-tomca七j

9、bc55eprinstrutsSdsploy在设静态架构蓝图需要考虑超时的控制。对整个平三、部署和监控。:minaspring.itutis將由1HAzoiDk&gp-rroirterZDDk&epsrh-e-artb-iestFlumeMQCacherabbitMQmemMQhe|Salr/lucen-&IMRTS-tormiTiDgileFsuraczle-ffnysqlhadDophhasemongodbecfim整个架构是分层的分布式的架构，纵向包括CDN,负载均衡/反向代理，web应用，业务层，基础服务层，数据存储层。水平方向包括1.CDNCDN系统能够实时地根据网络流量和各节点的连

10、接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决Internet网络拥挤的状况，提髙用户访问网站的响应速度。对于大规模电子商务平台一般需要建CDN做网络加速，大型平台如淘宝、京东都采用自建CDN，中小型的企业可以采用第三方CDN厂商合作，如蓝汛、网宿、快网等。当然在选择CDN厂商时，需要考虑经营时间长短，是否有可扩充的带宽资源、灵活的流量和带宽选择、稳定的节点、性价比。2.负载均衡、反向代理一个大型的平台包括很多个业务域，不同的业务域有不同的集群,可以用DNS做域名解析的分发或轮询，DNS方式实现简单，但是因存在

11、cache而缺乏灵活性；一般基于商用的硬件F5、NetScaler或者开源的软负载lvs在4层做分发，当然会采用做冗余(比如lvs+keepalived)的考虑，采取主备方式。4层分发到业务集群上后，会经过web服务器如nginx或者HAProxy在7层做负载均衡或者反向代理分发到集群中的应用节点。选择哪种负载，需要综合考虑各种因素(是否满足高并发高性能，Session保持如何解决，负载均衡的算法如何，支持压缩，缓存的内存消耗)；下面基于几种常用的负载均衡软件做个介绍。LVS，工作在4层，Linux实现的髙性能髙并发、可伸缩性、可靠的的负载均衡器，支持多种转发方式(NAT、DR、IPTunne

12、ling)，其中DR模式支持通过广域网进行负载均衡。支持双机热备(Keepalived或者Heartbeat)。对网络环境的依赖性比较髙。Nginx工作在7层，事件驱动的、异步非阻塞的架构、支持多进程的髙并发的负载均衡器/反向代理软件。可以针对域名、目录结构、正则规则针对http做一些分流。通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。对于sessionsticky，可以基于iphash的算法来实现，通过基于cookie的扩展nginx-sticky-module支持sessions

13、ticky。HAProxy支持4层和7层做负载均衡，支持session的会话保持，cookie的引导；支持后端url方式的检测；负载均衡的算法比较丰富，有RR、权重等。对于图片，需要有单独的域名，独立或者分布式的图片服务器或者如mogileFS，可以图片服务器之上加varnish做图片缓存。App接入应用层运行在jboss或者tomcat容器中，代表独立的系统，比如前端购物、用户自主服务、后端系统等协议接口，HTTP、JS0N可以采用servlet3.0,异步化servlet,提髙整个系统的吞吐量http请求经过Nginx，通过负载均衡算法分到到App的某一节点，这一层层扩容起来比较简单。除了

14、利用cookie保存少量用户部分信息外（cookie般不能超过4K的大小），对于App接入层，保存有用户相关的session数据，但是有些反向代理或者负载均衡不支持对sessionsticky支持不是很好或者对接入的可用性要求比较髙（app接入节点宕机，session随之丢失），这就需要考虑session的集中式存储，使得App接入层无状态化，同时系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的。Session的集中式存储，需要满足以下几点要求：a、髙效的通讯协议b、session的分布式缓存，支持节点的伸缩，数据的冗余备份以及数据的迁移c、session过期的管理业务服务

15、代表某一领域的业务提供的服务，对于电商而言，领域有用户、商品、订单、红包、支付业务等等，不同的领域提供不同的服务，这些不同的领域构成一个个模块，良好的模块划分和接口设计非常重要，一般是参考髙内聚、接口收敛的原则，这样可以提髙整个系统的可用性。当然可以根据应用规模的大小模块可以部署在一起，对于大规模的应用，一般是独立部署的。髙并发：业务层对外协议以NIO的RPC方式暴露，可以采用比较成熟的NIO通讯框架，如netty、mina可用性：为了提高模块服务的可用性，一个模块部署在多个节点做冗余，并自动进行负载转发和失效转移;最初可以利用VIP+heartbeat方式，目前系统有一个单独的组件HA,利用

16、zookeeper实现（比原来方案的优点）一致性、事务：对于分布式系统的一致性，尽量满足可用性，一致性可以通过校对来达到最终一致的状态。5.基础服务中间件1）通信组件通信组件用于业务系统内部服务之间的调用，在大并发的电商平台中，需要满足高并发高吞吐量的要求。整个通信组件包括客户端和服务端两部分。客户端和服务器端维护的是长连接，可以减少每次请求建立连接的开销，在客户端对于每个服务器定义一个连接池，初始化连接后，可以并发连接服务端进行rpc操作，连接池中的长连接需要心跳维护，设置请求超时时间。对于长连接的维护过程可以分两个阶段，一个是发送请求过程，另外一个是接收响应过程。在发送请求过程中，若发生I

17、OException，则把该连接标记失效。接收响应时，服务端返回SocketTimeoutException,如果设置了超时时间，那么就直接返回异常，清除当前连接中那些超时的请求。否则继续发送心跳包（因为可能是丢包，超过pinginterval间隔时间就发送ping操作），若ping不通（发送IOException），则说明当前连接是有问题的，那么就把当前连接标记成已经失效；若ping通，则说明当前连接是可靠的，继续进行读操作。失效的连接会从连接池中清除掉。每个连接对于接收响应来说都以单独的线程运行，客户端可以通过同步（wait,notify）方式或者异步进行rpc调用，序列化采用更高效的he

18、ssion序列化方式。服务端采用事件驱动的NIO的MINA框架，支撑高并发高吞吐量的请求。在大多数的数据库切分解决方案中，为了提高数据库的吞吐量，首先是对不同的表进行垂直切分到不同的数据库中，然后当数据库中一个表超过一定大小时，需要对该表进行水平切分，这里也是一样，这里以用户表为例；对于访问数据库客户端来讲，需要根据用户的ID,定位到需要访问的数据；数据切分算法，根据用户的ID做hash操作，一致性Hash，这种方式存在失效数据的迁移问题，迁移时间内服务不可用维护路由表，路由表中存储用户和sharding的映射关系，sharding分为leader和replica，分别负责写和读这样每个biz

19、客户端都需要保持所有sharding的连接池，这样有个缺点是会产生全连接的问题；一种解决方法是sharding的切分提到业务服务层进行，每个业务节点只维护一个shard的连接即可。见图（router）db11-bizl1-bizl2hardlgrutpsdbll-dhl2vatch；watch-tentersroutBrlrouter2clientb-irUshardlbi1152Qkespr|lardlrouterrouterdb13db12路由组件的实现是这样的（可用性、高性能、高并发）基于性能方面的考虑，采用mongodb中维护用户id和shard的关系，为了保证可用性，搭建replic

20、atset集群。biz的sharding和数据库的sharding是一一对应的，只访问一个数据库业务注册节点至Hzookeeper上/bizs/shard/下。router监听zookeeper上/bizs/下节点状态，缓存在线biz在router中。client请求router获取biz时，router首先从mongodb中获取用户对应的shard,router根据缓存的内容通过RR算法获取biz节点。为了解决router的可用性和并发吞吐量问题，对router进行冗余，同时client监听zookeeper的/routers节点并缓存在线router节点列表。HA传

21、统实现HA的做法一般是采用虚拟IP漂移，结合Heartbeat、keepalived等实现HA，Keepalived使用vrrp方式进行数据包的转发，提供4层的负载均衡，通过检测vrrp数据包来切换，做冗余热备更加适合与LVS搭配。LinuxHeartbeat是基于网络或者主机的服务的髙可用，HAProxy或者Nginx可以基于7层进行数据包的转发，因此Heatbeat更加适合做HAProxy、Nginx，包括业务的髙可用。在分布式的集群中，可以用zookeeper做分布式的协调，实现集群的列表维护和失效通知，客户端可以选择hash算法或者roudrobin实现负载均衡；对于master-ma

22、ster模式、master-slave模式，可以通过zookeeper分布式锁的机制来支持。消息Message对于平台各个系统之间的异步交互，是通过MQ组件进行的。在设计消息服务组件时，需要考虑消息一致性、持久化、可用性、以及完善的监控体系。业界开源的消息中间件主要RabbitMQ、kafka有两种，RabbitMQ,遵循AMQP协议，由内在髙并发的erlanng语言开发;kafka是Linkedin于2010年12月份开源的消息发布订阅系统，它主要用于处理活跃的流式数据,大数据量的数据处理上。对消息一致性要求比较髙的场合需要有应答确认机制，包括生产消息和消费消息的过程；不过因网络等原理导致的

23、应答缺失，可能会导致消息的重复，这个可以在业务层次根据幂等性进行判断过滤；RabbitMQ采用的是这种方式。还有一种机制是消费端从broker拉取消息时带上LSN号，从broker中某个LSN点批量拉取消息，这样无须应答机制，kafka分布式消息中间件就是这种方式。消息的在broker中的存储，根据消息的可靠性的要求以及性能方面的综合衡量，可以在内存中，可以持久化到存储上。对于可用性和髙吞吐量的要求，集群和主备模式都可以在实际的场景应用的到。RabbitMQ解决方案中有普通的集群和可用性更髙的mirrorqueue方式。kafka采用zookeeper对集群中的broker、consumer进

24、行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。总体来讲，RabbitMQ用在实时的对可靠性要求比较高的消息传递上。afka主要用于处理活跃的流式数据，大数据量的数据处理上。5)Cache&BufferCache系统在一些高并发高性能的场景中，使用cache可以减少对后端系统的负载，承担可大部分读的压力，可以大大提高系统的吞吐量，比如通常在数据库存储之前增加cache缓存。但是引入cache架

25、构不可避免的带来一些问题，cache命中率的问题，cache失效引起的抖动，cache和存储的一致性。Cache中的数据相对于存储来讲，毕竟是有限的，比较理想的情况是存储系统的热点数据，这里可以用一些常见的算法LRU等等淘汰老的数据；随着系统规模的增加，单个节点cache不能满足要求，就需要搭建分布式Cache；为了解决单个节点失效引起的抖动，分布式cache一般采用一致性hash的解决方案，大大减少因单个节点失效引起的抖动范围；而对于可用性要求比较高的场景，每个节点都是需要有备份的。数据在cache和存储上都存有同一份备份，必然有一致性的问题，一致性比较强的,在更新数据库的同时，更新数据库c

26、ache。对于一致性要求不高的，可以去设置缓存失效时间的策略。Memcached作为髙速的分布式缓存服务器，协议比较简单，基于libevent的事件处理机制。Cache系统在平台中用在router系统的客户端中，热点的数据会缓存在客户端，当数据访问失效时，才去访问router系统。当然目前更多的利用内存型的数据库做cache，比如redis、mongodb；redis比memcache有丰富的数据操作的API；redis和mongodb都对数据进行了持久化，而memcache没有这个功能，因此memcache更加适合在关系型数据库之上的数据的缓存。Buffer系统用在高速的写操作的场景中，平台

27、中有些数据需要写入数据库，并且数据是分库分表的，但对数据的可靠性不是那么高，为了减少对数据库的写压力，可以采取批量写操作的方式。开辟一个内存区域，当数据到达区域的一定阀值时如80%时，在内存中做分库梳理工作（内存速度还是比较快的），后分库批量flush。6）搜索在电子商务平台中搜索是一个非常的重要功能，主要有搜索词类目导航、自动提示和搜索排序功能。开源的企业级搜索引擎主要有lucene,sphinx，这里不去论述哪种搜索引擎更好一些，不过选择搜索引擎除了基本的功能需要支持外非功能方面需要考虑以下两点：a、搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提高可用性b、索引的实

28、时性c、性能Solr是基于lucene的高性能的全文搜索服务器，提供了比lucene更为丰富的查询语言，可配置可扩展，对外提供基于http协议的XML/JSON格式的接口。从Solr4版本开始提供了SolrCloud方式来支持分布式的索引，自动进行sharding数据切分；通过每个sharding的master-slave（leader、replica）模式提髙搜索的性能；利用zookeeper对集群进行管理，包括leader选举等等，保障集群的可用性。Lucene索引的Reader是基于索引的snapshot的，所以必须在索引commit的后，重新打开一个新的snapshot,才能搜索到新添

29、加的内容；而索引的commit是非常耗性能的，这样达到实时索引搜索效率就比较低下。对于索引搜索实时性，Solr4的之前解决方案是结合文件全量索引和内存增量索引合并的方式，参见下图。A訂初始狀态B訂門存索引A离后卅态合并門存盍引A和硬虽索豆C:磴绘亲弓用此內存索引台并结豆之后状Solr4提供了NRTsoftcommit的解决方案，softcommit无需进行提交索引操作，就可以搜素到最新对索引的变更，不过对索引的变更并没有synccommit到硬盘存储上，若发生意外导致程序非正常结束，未commit的数据会丢失，因此需要定时的进行commit操作。平台中对数据的索引和存储操作是异步的，可以大大提

30、高可用性和吞吐量；只对某些属性字段做索引操作，存储数据的标识key，减少索引的大小；数据是存储在分布式存储HBase中的，HBase对二级索引搜索支持的不好，然而可以结合Solr搜索功能进行多维度的检索统计。索引数据和HBase数据存储的一致性，也就是如何保障HBase存储的数据都被索引过，可以采用confirm确认机制，通过在索引前建立待索引数据队列，在数据存储并索引完成后，从待索引数据队列中删除数据。7）日志收集在整个交易过程中，会产生大量的日志，这些日志需要收集到分布式存储系统中存储起来，以便于集中式的查询和分析处理。日志系统需具备三个基本组件，分别为agent（封装数据源，将数据源中的

31、数据发送给collector）,collector（接收多个agent的数据，并进行汇总后导入后端的store中），store（中央存储系统,应该具有可扩展性和可靠性，应该支持当前非常流行的HDFS）。开源的日志收集系统业界使用的比较多的是cloudera的Flume和facebook的Scribe，其中Flume目前的版本FlumeNG对Flume从架构上做了较大的改动。在设计或者对日志收集系统做技术选型时，通常需要具有以下特征：a、应用系统和分析系统之间的桥梁，将他们之间的关系解耦b、分布式可扩展，具有高的扩展性，当数据量增加时，可以通过增加节点水平扩展日志收集系统是可以伸缩的，在系统的各

32、个层次都可伸缩，对数据的处理不需要带状态，伸缩性方面也比较容易实现。c、近实时性在一些时效性要求比较高的场景中，需要可以及时的收集日志，进行数据分析；一般的日志文件都会定时或者定量的进行rolling，所以实时检测日志文件的生成，及时对日志文件进行类似的tail操作，并支持批量发送提高传输效率；批量发送的时机需要满足消息数量和时间间隔的要求。d、容错性Scribe在容错方面的考虑是，当后端的存储系统crash时，scribe会将数据写到本地磁盘上，当存储系统恢复正常后，scribe将日志重新加载到存储系统中。FlumeNG通过SinkProcessor实现负载均衡和故障转移。多个Sink可以构

33、成一个SinkGroup。一个SinkProcessor负责从一个指定的SinkGroup中激活一个Sink。SinkProcessor可以通过组中所有Sink实现负载均衡；也可以在一个Sink失败时转移到另一个。e、事务支持Scribe没有考虑事务的支持。Flume通过应答确认机制实现事务的支持，参见下图，ChannelSinktakacuGnisSourceChannelsbndonetxstartexputgYSflSandtx通常提取发送消息都是批量操作的，消息的确认是对一批数据的确认，这样可以大大提髙数据发送的效率。f、可恢复性FlumeNG的channel根据可靠性的要求的不同，可

34、以基于内存和文件持久化机制，基于内存的数据传输的销量比较髙，但是在节点宕机后，数据丢失，不可恢复；而文件持久化宕机是可以恢复的。g、数据的定时定量归档数据经过日志收集系统归集后，一般存储在分布式文件系统如Hadoop，为了便于对数据进行后续的处理分析，需要定时(TimeTrigger)或者定量(SizeTrigger的rolling分布式系统的文件。数据同步在交易系统中，通常需要进行异构数据源的同步，通常有数据文件到关系型数据库，数据文件到分布式数据库，关系型数据库到分布式数据库等。数据在异构源之间的同步一般是基于性能和业务的需求,数据存储在本地文件中一般是基于性能的考虑，文件是顺序存储的，效

35、率还是比较髙的；数据同步到关系型数据一般是基于查询的需求；而分布式数据库是存储越来越多的海量数据的，而关系型数据库无法满足大数据量的存储和查询请求。在数据同步的设计中需要综合考虑吞吐量、容错性、可靠性、一致性的问题同步有实时增量数据同步和离线全量数据区分，下面从这两个维度来介绍一下，实时增量一般是Tail文件来实时跟踪文件变化，批量或者多线程往数据库导出，这种方式的架构类似于日志收集框架。这种方式需要有确认机制，包括两个方面。一个方面是Channel需要给agent确认已经批量收到数据记录了,发送LSN号给agent,这样在agent失效恢复时，可以从这个LSN点开始tail；当然对于允许少量

36、的重复记录的问题（发生在channel给agent确认的时，agent宕机并未受到确认消息），需要在业务场景中判断。另外一个方面是sync给channel确认已经批量完成写入到数据库的操作，这样channel可以删除这部分已经confirm的消息。基于可靠性的要求，channel可以采用文件持久化的方式。参见下图离线全量遵循空间间换取时间，分而治之的原则，尽量的缩短数据同步的时间，提髙同步的效率。需要对源数据比如MySQL进行切分，多线程并发读源数据，多线程并发批量写入分布式数据库比如HBase，利用channel作为读写之间的缓冲，实现更好的解耦，channel可以基于文件存储或者内存。参见

37、下图：对于源数据的切分，如果是文件可以根据文件名称设置块大小来切分。对于关系型数据库，由于一般的需求是只离线同步一段时间的数据（比如凌晨把当天的订单数据同步到HBase），所以需要在数据切分时（按照行数切分），会多线程扫描整个表（及时建索引，也要回表），对于表中包含大量的数据来讲，10很髙，效率非常低；这里解决的方法是对数据库按照时间字段（按照时间同步的）建立分区，每次按照分区进行导出。9）数据分析从传统的基于关系型数据库并行处理集群、用于内存计算近实时的，到目前的基于hadoop的海量数据的分析，数据的分析在大型电子商务网站中应用非常广泛，包括流量统计、推荐引擎、趋势分析、用户行为分析、数据

38、挖掘分类器、分布式索引等等。并行处理集群有商业的EMCGreenplum，Greenplum的架构采用了MPP（大规模并行处理），基于postgresql的大数据量存储的分布式数据库。内存计算方面有SAP的HANA，开源的nosql内存型的数据库mongodb也支持mapreduce进行数据的分析。海量数据的离线分析目前互联网公司大量的使用Hadoop，Hadoop在可伸缩性、健壮性、计算性能和成本上具有无可替代的优势，事实上已成为当前互联网企业主流的大数据分析平台Hadoop通过MapReuce的分布式处理框架，用于处理大规模的数据，伸缩性也非常好；但是MapReduce最大的不足是不能满足

39、实时性的场景，主要用于离线的分析。基于MapRduce模型编程做数据的分析，开发上效率不髙，位于hadoop之上Hive的出现使得数据的分析可以类似编写sql的方式进行，sql经过语法分析、生成执行计划后最终生成MapReduce任务进行执行，这样大大提髙了开发的效率，做到以ad-hoc（计算在query发生时）方式进行的分析。基于MapReduce模型的分布式数据的分析都是离线的分析，执行上都是暴力扫描，无法利用类似索引的机制；开源的ClouderaImpala是基于MPP的并行编程模型的，底层是Hadoop存储的髙性能的实时分析平台，可以大大降低数据分析的延迟。目前Hadoop使用的版本是

40、Hadoopl.0,方面原有的MapReduce框架存在JobTracker单点的问题，另外一方面JobTracker在做资源管理的同时又做任务的调度工作，随着数据量的增大和Job任务的增多，明显存在可扩展性、内存消耗、线程模型、可靠性和性能上的缺陷瓶颈；Hadoop2.0yarn对整个框架进行了重构，分离了资源管理和任务调度，从架构设计上解决了这个问题。参考Yarn的架构10）实时计算在互联网领域，实时计算被广泛实时监控分析、流控、风险控制等领域。电商平台系统或者应用对日常产生的大量日志和异常信息，需要经过实时过滤、分析，以判定是否需要预警；同时需要对系统做自我保护机制，比如对模块做流量的控

41、制，以防止非预期的对系统压力过大而引起的系统瘫痪，流量过大时，可以采取拒绝或者引流等机制；有些业务需要进行风险的控制，比如彩票中有些业务需要根据系统的实时销售情况进行限号与放号。原始基于单节点的计算，随着系统信息量爆炸式产生以及计算的复杂度的增加，单个节点的计算已不能满足实时计算的要求，需要进行多节点的分布式的计算，分布式实时计算平台就出现了。这里所说的实时计算，其实是流式计算，概念前身其实是CEP复杂事件处理，相关的开源产品如Esper，业界分布式的流计算产品YahooS4,Twitterstorm等，以storm开源产品使用最为广泛。对于实时计算平台，从架构设计上需要考虑以下几个因素：1、

42、伸缩性随着业务量的增加，计算量的增加，通过增加节点处理，就可以处理。2、髙性能、低延迟从数据流入计算平台数据，到计算输出结果，需要性能髙效且低延迟，保证消息得到快速的处理，做到实时计算。3、可靠性保证每个数据消息得到一次完整处理。4、容错性建立Topology地目录提交topology-*NimbusI-/taskbeatsI-Jri-task-id监控丁话知卜跳计算工作星TasksE-/ta&ksI-topoiovidIT琢I。client茯取分吨的佰g饰启动任务建立说烂间的连蜜Supervisor分flasks工二zookeeper启S?Topoipg?Super/isor-/assign

43、ments-tORqjogyjdfnasterf-CrrBSnh（!sttaskrmdE+port（加Re）taskhtart-tiT-tecm-/storms|-tqpoloqid-/supervisors净supervisor-idI；woker1sccKetTask1Taskfsocketf系统可以自动管理节点的宕机失效，对应用来说，是透明的。Twitter的Storm在以上这几个方面做的比较好，下面简介一下Storm的架构。整个集群的管理是通过zookeeper来进行的。客户端提交拓扑到nimbus。Nimbus针对该拓扑建立本地的目录根据topology的配置计算task，分配tas

44、k,在zookeeper上建立assignments节点存储task和supervisor机器节点中woker的对应关系。在zookeeper上创建taskbeats节点来监控task的心跳；启动topology。Supervisor去zookeeper上获取分配的tasks，启动多个woker进行，每个woker生成task，一个task个线程；根据topology信息初始化建立task之间的连接；Task和Task之间是通过zeroMQ管理的；之后整个拓扑运行起来。Tuple是流的基本处理单元，也就是一个消息，Tuple在task中流转，Tuple的发送和接收过程如下：发送Tuple,Wo

45、rker提供了一个transfer的功能，用于当前task把tuple发到到其他的task中。以目的taskid和tuple参数，序列化tuple数据并放到transferqueue中。在0.8版本之前，这个queue是LinkedBlockingQueue，0.8之后是DisruptorQueue。在0.8版本之后，每一个woker绑定一个inboundtransferqueue和outbondqueue，inboundqueue用于接收message，outbondqueue用于发送消息。发送消息时，由单个线程从transferqueue中拉取数据，把这个tuple通过zeroMQ发送到其

46、他的woker中。接收Tuple，每个woker都会监听zeroMQ的tcp端口来接收消息，消息放到DisruptorQueue中后，后从queue中获取message(taskid,tuple)，根据目的taskid,tuple的值路由到task中执行。每个tuple可以emit到directsteam中，也可以发送到regularstream中，在Reglular方式下，由StreamGrou(pstreamid-componentidoutbondtasks)功能完成当前tuple将要发送的Tuple的目的地。通过以上分析可以看到，Storm在伸缩性、容错性、髙性能方面的从架构设计的角度

47、得以支撑；同时在可靠性方面，Storm的ack组件利用异或xor算法在不失性能的同时，保证每一个消息得到完整处理的同时。11）实时推送实时推送的应用场景非常多，比如系统的监控动态的实时曲线绘制，手机消息的推送，web实时聊天等。实时推送有很多技术可以实现，有Comet方式，有websocket方式等。Comet基于服务器长连接的“服务器推”技术，包含两种：LongPolling：服务器端在接到请求后挂起，有更新时返回连接即断掉，然后客户端再发起新的连接Stream方式:每次服务端数据传送不会关闭连接，连接只会在通信出现错误时，或是连接重建时关闭（一些防火墙常被设置为丢弃过长的连接，服务器端可以

48、设置一个超时时间，超时后通知客户端重新建立连接，并关闭原来的连接）。Websocket：长连接，全双工通信是Html5的一种新的协议。它实现了浏览器与服务器的双向通讯。webSocketAPI中，浏览器和服务器端只需要通过一个握手的动作，便能形成浏览器与客户端之间的快速双向通道，使得数据可以快速的双向传播。Socket.io是一个NodeJSwebsocket库，包括客户端的JS和服务端的的nodejs，用于快速构建实时的web应用。数据存储数据库存储大体分为以下几类，有关系型（事务型）的数据库，以oracle、mysql为代表，有keyvalue数据库，以redis和memcacheddb为

49、代表，有文档型数据库如mongodb，有列式分布式数据库以HBase，cassandra,dynamo为代表，还有其他的图形数据库、对象数据库、xml数据库等。每种类型的数据库应用的业务领域是不一样的，下面从内存型、关系型、分布式三个维度针对相关的产品做性能可用性等方面的考量分析。1）内存型数据库内存型的数据库，以髙并发髙性能为目标，在事务性方面没那么严格，以开源nosql数据库mongodb、redis为例通信方式多线程方式，主线程监听新的连接，连接后，启动新的线程做数据的操作（10切换）。数据结构ExtentRecordDocReccjrdDocResortDocRetwdCdBction

50、NamespacestructDisklDcaiion(hleNooffsetIndexMarnespaceActualdatJ*paddingPaddingfactoriscolecticmspecific日treeBteelNodeMode数据库-collection-recordMongoDB在数据存储上按命名空间来划分，一个collection是一个命名空间，一个索引也是一个命名空间。同一个命名空间的数据被分成很多个Extent，Extent之间使用双向链表连接。在每一个Extent中，保存了具体每一行的数据，这些数据也是通过双向链接连接的。每一行数据存储空间不仅包括数据占用空间，还可

51、能包含一部分附加空间，这使得在数据update变大后可以不移动位置。索引以BTree结构实现。如果你开启了jorunaling日志，那么还会有一些文件存储着你所有的操作记录。持久化存储MMap方式把文件地址映射到内存的地址空间，直接操作内存地址空间就可以操作文件，不用再调用write,read操作，性能比较高。mongodb调用mmap把磁盘中的数据映射到内存中的，所以必须有一个机制时刻的刷数据到硬盘才能保证可靠性，多久刷一次是与syncdelay参数相关的。journal（进行恢复用）是Mongodb中的redolog，而Oplog则是负责复制的binlogo如果打开journal,那么即使

52、断电也只会丢失100ms的数据，这对大多数应用来说都可以容忍了。从1.9.2+，mongodb都会默认打开journal功能，以确保数据安全。而且journal的刷新时间是可以改变的，2-300ms的范围,使用-journalCommitinterval命令。Oplog和数据刷新到磁盘的时间是60s,对于复制来说，不用等到oplog刷新磁盘，在内存中就可以直接复制到Sencondary节点。事务支持Mongodb只支持对单行记录的原子操作HA集群用的比较多的是ReplicaSets,采用选举算法，自动进行leader选举，在保证可用性的同时，可以做到强一致性要求。、Querycangotoma

53、steroranyslaveThiscanbesetperqueryheartbeatUpdatealwaysgotomaster.csdn.nf/yflngfcitcUpdatepropagatestosecondaryasyncSecondaryDBSecondaryDBClientLib当然对于大量的数据，mongodb也提供了数据的切分架构Sharding。0Redis丰富的数据结构，高速的响应速度，内存操作通信方式因都在内存操作，所以逻辑的操作非常快，减少了CPU的切换开销，所以为单线程的模式（逻辑处理线程和主线程是一个）。reactor模式，实现自己的多路复用N10机制（epoll

54、，select,kqueue等）单线程处理多任务数据结构hash+bucket结构，当链表的长度过长时，会采取迁移的措施（扩展原来两倍的hash表，把数据迁移过去，expand+rehash）持久化存储a、全量持久化RDB（遍历redisDB,读取bucket中的key,value）,save命令阻塞主线程，bgsave开启子进程进行snapshot持久化操作，生成rdb文件。在shutdown时，会调用save操作数据发生变化，在多少秒内触发一次bgsavesync，master接受slave发出来的命令b、增量持久化（aof类似redolog）,先写到日志buffer,再flush到日志文

55、件中（flush的策略可以配置的，而已单条，也可以批量），只有flush到文件上的，才真正返回客户端。要定时对aof文件和rdb文件做合并操作（在快照过程中，变化的数据先写到aofbuf中等子进程完成快照内存snapshot后，再进行合并aofbuf变化的部分以及全镜像数据）。在髙并发访问模式下，RDB模式使服务的性能指标出现明显的抖动，aof在性能开销上比RDB好，但是恢复时重新加载到内存的时间和数据量成正比。集群HA通用的解决方案是主从备份切换，采用HA软件，使得失效的主redis可以快速的切换到从redis上。主从数据的同步采用复制机制，该场景可以做读写分离。目前在复制方面，存在的一个问

56、题是在遇到网络不稳定的情况下Slave和Master断开（包括闪断）会导致Master需要将内存中的数据全部重新生成rdb文件（快照文件），然后传输给Slave。Slave接收完Master传递过来的rdb文件以后会将自身的内存清空，把rdb文件重新加载到内存中。这种方式效率比较低下，在后面的未来版本Redis2.8作者已经实现了部分复制的功能。2）关系型数据库关系型数据库在满足并发性能的同时，也需要满足事务性，以mysql数据库为例，讲述架构设计原理，在性能方面的考虑，以及如何满足可用性的需求。0mysql的架构原理（innodb）在架构上，mysql分为server层和存储引擎层。Serv

57、er层的架构对于不同的存储引擎来讲都是一样的，包括连接/线程处理、查询处理（parser、optimizer）以及其他系统任务。存储引擎层有很多种，mysql提供了存储引擎的插件式结构，支持多种存储引擎，用的最广泛的是innodb和myisamin；inodb主要面向OLTP方面的应用，支持事务处理，myisam不支持事务，表锁，对0LAP操作速度快。以下主要针对innodb存储引擎做相关介绍。在线程处理方面，Mysql是多线程的架构，由一个master线程，一个锁监控线程，一个错误监控线程，和多个10线程组成。并且对一个连接会开启一个线程进行服务。io线程又分为节省随机IO的insertbu

58、ffer，用于事务控制的类似于oracle的redolog,以及多个write,多个read的硬盘和内存交换的IO线程。在内存分配方面，包括innodbbufferpool，以及logbuffer。其中innodbbufferpool包括insertbuffer、datapage、indexpage、数据字典、自适应hash。Logbuffer用于缓存事务日志，提供性能。在数据结构方面，innodb包括表空间、段、区、页/块，行。索引结构是B+tree结构，包括二级索引和主键索引，二级索引的叶子节点是主键PK，根据主键索引的叶子节点指向存储的数据块。这种B+树存储结构可以更好的满足随机查询操作

59、IO要求，分为数据页和二级索引页，修改二级索引页面涉及到随机操作，为了提高写入时的性能，采用insertbuffer做顺序的写入，再由后台线程以一定频率将多个插入合并到二级索引页面。为了保证数据库的一致性（内存和硬盘数据文件），以及缩短实例恢复的时间，关系型数据库还有一个checkpoint的功能，用于把内存buffer中之前的脏页按照比例（老的LSN）写入磁盘，这样redolog文件的LSN以前的日志就可以被覆盖了，进行循环使用；在失效恢复时，只需要从日志中LSN点进行恢复即可。在事务特性支持上，关系型数据库需要满足ACID四个特性，需要根据不同的事务并发和数据可见性要求，定义了不同的事务隔

60、离级别，并且离不开对资源争用的锁机制，要避免产生死锁，mysql在Server层和存储引擎层做并发控制，主要体现在读写锁，根据锁粒度不同，有各个级别的锁（表锁、行锁、页锁、MVCC）；基于提髙并发性能的考虑,使用多版本并发控制MVCC来支持事务的隔离，并基于undo来实现，在做事务回滚时，也会用到undo段。mysql用redolog来保证数据的写入的性能和失效恢复，在修改数据时只需要修改内存，再把修改行为记录到事务日志中（顺序I0），不用每次将数据修改本身持久化到硬盘（随机10）,大大提髙性能。在可靠性方面，innodb存储引擎提供了两次写机制doublewriter用于防止在flush页面