构建高并发高可用的电商平台架构实践（上）

构建高并发高可用的电商平台架构实践（上）

 

1、 设计理念

1.      空间换时间

1)      多级缓存，静态化

客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端能够继续用cache，减小流量)，ETag）

反向代理缓存

应用端的缓存(memcache)

内存数据库

Buffer、cache机制（数据库，中间件等）

2)      索引

哈希、B树、倒排、bitmap

哈希索引适合综合数组的寻址和链表的插入特性，能够实现数据的快速存取。

B树索引适合于查询为主导的场景，避免屡次的IO，提升查询的效率。

倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，普遍用在搜索领域。

Bitmap是一种很是简洁快速的数据结构，他能同时使存储空间和速度最优化（而没必要空间换时间），适合于海量数据的的计算场景。

2.     并行与分布式计算

 

1)      任务切分、分而治之(MR)

在大规模的数据中，数据存在必定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。

MR模型是无共享的架构，数据集分布至各个节点。处理时，每一个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffle and sort)后再分发(至reduce节点)，避免了大量数据的传输，提升了处理效率。

 

2)      多进程、多线程并行执行(MPP)

并行计算（Parallel Computing）是指同时使用多种计算资源解决计算问题的过程，是提升计算机系统计算速度和处理能力的一种有效手段。它的基本思想是用多个处理器/进程/线程来协同求解同一问题，即将被求解的问题分解成若干个部分，各部分均由一个独立的处理机来并行计算。

和MR的区别在于，它是基于问题分解的，而不是基于数据分解。

3.      多维度的可用

1)      负载均衡、容灾、备份

随 着平台并发量的增大，须要扩容节点进行集群，利用负载均衡设备进行请求的分发；负载均衡设备一般在提供负载均衡的同时，也提供失效检测功能；同时为了提升 可用性，须要有容灾备份，以防止节点宕机失效带来的不可用问题；备份有在线的和离线备份，能够根据失效性要求的不一样，进行选择不一样的备份策略。

2)      读写分离

读写分离是对数据库来说的，随着系统并发量的增大，提升数据访问可用性的一个重要手段就是写数据和读数据进行分离；固然在读写分离的同时，须要关注数据的一致性问题；对于一致性的问题，在分布式的系统CAP定量中，更多的关注于可用性。

3)      依赖关系

平台中各个模块之间的关系尽可能是低耦合的，能够经过相关的消息组件进行交互，能异步则异步，分清楚数据流转的主流程和副流程，主副是异步的，好比记录日志能够是异步操做的，增长整个系统的可用性。

固然在异步处理中，为了确保数据获得接收或者处理，每每须要确认机制(confirm、ack)。

可是有些场景中，虽然请求已经获得处理，可是因其余缘由(好比网络不稳定)，确认消息没有返回，那么这种状况下须要进行请求的重发，对请求的处理设计因重发因素须要考虑幂等性。

4)      监控

监控也是提升整个平台可用性的一个重要手段，多平台进行多个维度的监控；模块在运行时候是透明的，以达到运行期白盒化。

4.      伸缩

1)      拆分

拆分包括对业务的拆分和对数据库的拆分。

系统的资源老是有限的，一段比较长的业务执行若是是一竿子执行的方式，在大量并发的操做下，这种阻塞的方式，没法有效的及时释放资源给其余进程执行，这样系统的吞吐量不高。

须要把业务进行逻辑的分段，采用异步非阻塞的方式，提升系统的吞吐量。

随着数据量和并发量的增长，读写分离不能知足系统并发性能的要求，须要对数据进行切分，包括对数据进行分库和分表。这种分库分表的方式，须要增长对数据的路由逻辑支持。

2)      无状态

对于系统的伸缩性而言，模块最好是无状态的，经过增长节点就能够提升整个的吞吐量。

5.      优化资源利用

1)      系统容量有限

系统的容量是有限的，承受的并发量也是有限的，在架构设计时，必定须要考虑流量的控制，防止因意外攻击或者瞬时并发量的冲击致使系统崩溃。在设计时增长流控的措施，可考虑对请求进行排队，超出预期的范围，能够进行告警或者丢弃。

2)      原子操做与并发控制

对于共享资源的访问，为了防止冲突，须要进行并发的控制，同时有些交易须要有事务性来保证交易的一致性，因此在交易系统的设计时，需考虑原子操做和并发控制。

保证并发控制一些经常使用高性能手段有，乐观锁、Latch、mutex、写时复制、CAS等；多版本的并发控制MVCC一般是保证一致性的重要手段，这个在数据库的设计中常常会用到。

3)      基于逻辑的不一样，采起不同的策略

平台中业务逻辑存在不一样的类型，有计算复杂型的，有消耗IO型的，同时就同一种类型而言，不一样的业务逻辑消耗的资源数量也是不同的，这就须要针对不一样的逻辑采起不一样的策略。

针对IO型的，能够采起基于事件驱动的异步非阻塞的方式，单线程方式能够减小线程的切换引发的开销，或者在多线程的状况下采起自旋spin的方式，减小对线程的切换(好比oracle latch设计)；对于计算型的，充分利用多线程进行操做。

同一类型的调用方式，不一样的业务进行合适的资源分配，设置不一样的计算节点数量或者线程数量，对业务进行分流，优先执行优先级别高的业务。

4)      容错隔离

系统的有些业务模块在出现错误时，为了减小并发下对正常请求的处理的影响，有时候须要考虑对这些异常状态的请求进行单独渠道的处理，甚至暂时自动禁止这些异常的业务模块。

有些请求的失败多是偶然的暂时的失败(好比网络不稳定)，须要进行请求重试的考虑。

5)      资源释放

系统的资源是有限的，在使用资源时，必定要在最后释放资源，不管是请求走的是正常路径仍是异常的路径，以便于资源的及时回收，供其余请求使用。

在设计通讯的架构时，每每须要考虑超时的控制。

 

 

 

 

 

2、 静态架构蓝图

 

整个架构是分层的分布式的架构，纵向包括CDN，负载均衡/反向代理，web应用，业务层，基础服务层，数据存储层。水平方向包括对整个平台的配置管理部署和监控。

 

3、 剖析架构

1. CDN

CDN系统可以实时地根据网络流量和各节点的链接、负载情况以及到用户的距离和响应时间等综合信息将用户的请求从新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的情况，提升用户访问网站的响应速度。

对于大规模电子商务平台通常须要建CDN作网络加速，大型平台如淘宝、京东都采用自建CDN，中小型的企业能够采用第三方CDN厂商合做，如蓝汛、网宿、快网等。

固然在选择CDN厂商时，须要考虑经营时间长短，是否有可扩充的带宽资源、灵活的流量和带宽选择、稳定的节点、性价比。

2. 负载均衡、反向代理

一个大型的平台包括不少个业务域，不一样的业务域有不一样的集群，能够用DNS作域名解析的分发或轮询，DNS方式实现简单，可是因存在cache而缺少灵活性；通常基于商用的硬件F五、NetScaler或者开源的软负载lvs在4层作分发，固然会采用作冗余(好比lvs+keepalived)的考虑，采起主备方式。

4层分发到业务集群上后，会通过web服务器如nginx或者HAProxy在7层作负载均衡或者反向代理分发到集群中的应用节点。

选择哪一种负载，须要综合考虑各类因素（是否知足高并发高性能，Session保持如何解决，负载均衡的算法如何，支持压缩，缓存的内存消耗）；下面基于几种经常使用的负载均衡软件作个介绍。

LVS，工做在4层，Linux实现的高性能高并发、可伸缩性、可靠的的负载均衡器，支持多种转发方式(NAT、DR、IP Tunneling)，其中DR模式支持经过广域网进行负载均衡。支持双机热备(Keepalived或者Heartbeat)。对网络环境的依赖性比较高。

Nginx工做在7层，事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向代理软件。能够针对域名、目录结构、正则规则针对http作一些分流。经过端口检测到服务器内部的故障，好比根据服务器处理网页返回的状态码、超时等等，而且会把返回错误的请求从新提交到另外一个节点，不过其中缺点就是不支持url来检测。对于session sticky，能够基于ip hash的算法来实现，经过基于cookie的扩展nginx-sticky-module支持session sticky。

HAProxy支持4层和7层作负载均衡，支持session的会话保持，cookie的引导；支持后端url方式的检测；负载均衡的算法比较丰富，有RR、权重等。

对于图片，须要有单独的域名，独立或者分布式的图片服务器或者如mogileFS，能够图片服务器之上加varnish作图片缓存。

3. App接入

应用层运行在jboss或者tomcat容器中，表明独立的系统，好比前端购物、用户自主服务、后端系统等

协议接口，HTTP、JSON

能够采用servlet3.0,异步化servlet,提升整个系统的吞吐量

http请求通过Nginx，经过负载均衡算法分到到App的某一节点，这一层层扩容起来比较简单。

除了利用cookie保存少许用户部分信息外(cookie通常不能超过4K的大小)，对于App接入层，保存有用户相关的session数据，可是有些反向代理或者负载均衡不支持对session sticky支持不是很好或者对接入的可用性要求比较高(app接入节点宕机，session随之丢失)，这就须要考虑session的集中式存储，使得App接入层无状态化，同时系统用户变多的时候，就能够经过增长更多的应用节点来达到水平扩展的目的。

Session的集中式存储，须要知足如下几点要求：

a、高效的通信协议

b、session的分布式缓存，支持节点的伸缩，数据的冗余备份以及数据的迁移

c、session过时的管理

 

4. 业务服务

表明某一领域的业务提供的服务，对于电商而言，领域有用户、商品、订单、红包、支付业务等等，不一样的领域提供不一样的服务，

这些不一样的领域构成一个个模块，良好的模块划分和接口设计很是重要，通常是参考高内聚、接口收敛的原则，

这样能够提升整个系统的可用性。固然能够根据应用规模的大小，模块能够部署在一块儿，对于大规模的应用，通常是独立部署的。

高并发：

业务层对外协议以NIO的RPC方式暴露，能够采用比较成熟的NIO通信框架，如netty、mina

可用性：

为了提升模块服务的可用性，一个模块部署在多个节点作冗余，并自动进行负载转发和失效转移;

最初能够利用VIP+heartbeat方式，目前系统有一个单独的组件HA,利用zookeeper实现(比原来方案的优势)

一致性、事务：

对于分布式系统的一致性，尽可能知足可用性，一致性能够经过校对来达到最终一致的状态。

5. 基础服务中间件

1) 通讯组件

通讯组件用于业务系统内部服务之间的调用，在大并发的电商平台中，须要知足高并发高吞吐量的要求。

整个通讯组件包括客户端和服务端两部分。

客户端和服务器端维护的是长链接，能够减小每次请求创建链接的开销，在客户端对于每一个服务器定义一个链接池，初始化链接后，能够并发链接服务端进行rpc操做，链接池中的长链接须要心跳维护，设置请求超时时间。

对于长链接的维护过程能够分两个阶段，一个是发送请求过程，另一个是接收响应过程。在发送请求过程当中，若发生IOException，则把该链接标记失效。接收响应时，服务端返回SocketTimeoutException，若是设置了超时时间，那么就直接返回异常，清除当前链接中那些超时的请求。不然继续发送心跳包(由于多是丢包，超过pingInterval间隔时间就发送ping操做)，若ping不通(发送IOException)，则说明当前链接是有问题的，那么就把当前链接标记成已经失效；若ping通，则说明当前链接是可靠的，继续进行读操做。失效的链接会从链接池中清除掉。

每一个链接对于接收响应来讲都以单独的线程运行，客户端能够经过同步(wait,notify)方式或者异步进行rpc调用，

序列化采用更高效的hession序列化方式。

服务端采用事件驱动的NIO的MINA框架，支撑高并发高吞吐量的请求。

 

2) 路由Router

在大多数的数据库切分解决方案中，为了提升数据库的吞吐量，首先是对不一样的表进行垂直切分到不一样的数据库中，

而后当数据库中一个表超过必定大小时，须要对该表进行水平切分，这里也是同样，这里以用户表为例；

对于访问数据库客户端来说，须要根据用户的ID，定位到须要访问的数据；

数据切分算法，

根据用户的ID作hash操做，一致性Hash，这种方式存在失效数据的迁移问题，迁移时间内服务不可用

维护路由表，路由表中存储用户和sharding的映射关系,sharding分为leader和replica，分别负责写和读

这样每一个biz客户端都须要保持全部sharding的链接池，这样有个缺点是会产生全链接的问题；

一种解决方法是sharding的切分提到业务服务层进行，每一个业务节点只维护一个shard的链接便可。

见图（router）

 

   

路由组件的实现是这样的（可用性、高性能、高并发）

基于性能方面的考虑，采用mongodb中维护用户id和shard的关系，为了保证可用性，搭建replicatset集群。

biz的sharding和数据库的sharding是一一对应的，只访问一个数据库sharding.

biz业务注册节点到zookeeper上/bizs/shard/下。

router监听zookeeper上/bizs/下节点状态，缓存在线biz在router中。

client请求router获取biz时，router首先从mongodb中获取用户对应的shard,router根据缓存的内容经过RR算法获取biz节点。

为了解决router的可用性和并发吞吐量问题，对router进行冗余，同时client监听zookeeper的/routers节点并缓存在线router节点列表。

 

3) HA

传统实现HA的作法通常是采用虚拟IP漂移，结合Heartbeat、keepalived等实现HA，

Keepalived使用vrrp方式进行数据包的转发，提供4层的负载均衡，经过检测vrrp数据包来切换，作冗余热备更加适合与LVS搭配。Linux Heartbeat是基于网络或者主机的服务的高可用，HAProxy或者Nginx能够基于7层进行数据包的转发，所以Heatbeat更加适合作HAProxy、Nginx，包括业务的高可用。

在分布式的集群中，能够用zookeeper作分布式的协调，实现集群的列表维护和失效通知，客户端能够选择hash算法或者roudrobin实现负载均衡；对于master-master模式、master-slave模式，能够经过zookeeper分布式锁的机制来支持。

4) 消息Message

对于平台各个系统之间的异步交互，是经过MQ组件进行的。

在设计消息服务组件时，须要考虑消息一致性、持久化、可用性、以及完善的监控体系。

业界开源的消息中间件主要RabbitMQ、kafka有两种，

RabbitMQ,遵循AMQP协议，由内在高并发的erlanng语言开发；kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。

对消息一致性要求比较高的场合须要有应答确认机制，包括生产消息和消费消息的过程；不过因网络等原理致使的应答缺失，可能会致使消息的重复，这个能够在业务层次根据幂等性进行判断过滤；RabbitMQ采用的是这种方式。还有一种机制是消费端从broker拉取消息时带上LSN号，从broker中某个LSN点批量拉取消息，这样无须应答机制，kafka分布式消息中间件就是这种方式。

消息的在broker中的存储，根据消息的可靠性的要求以及性能方面的综合衡量，能够在内存中，能够持久化到存储上。

对于可用性和高吞吐量的要求，集群和主备模式均可以在实际的场景应用的到。RabbitMQ解决方案中有普通的集群和可用性更高的mirror queue方式。 kafka采用zookeeper对集群中的broker、consumer进行管理，能够注册topic到zookeeper上；经过zookeeper的协调机制，producer保存对应topic的broker信息，能够随机或者轮询发送到broker上；而且producer能够基于语义指定分片，消息发送到broker的某分片上。

整体来说，RabbitMQ用在实时的对可靠性要求比较高的消息传递上。kafka主要用于处理活跃的流式数据,大数据量的数据处理上。

 

5) Cache&Buffer

Cache系统

在一些高并发高性能的场景中，使用cache能够减小对后端系统的负载，承担可大部分读的压力，能够大大提升系统的吞吐量，好比一般在数据库存储以前增长cache缓存。

可是引入cache架构不可避免的带来一些问题，cache命中率的问题, cache失效引发的抖动，cache和存储的一致性。

Cache中的数据相对于存储来说，毕竟是有限的，比较理想的状况是存储系统的热点数据，这里能够用一些常见的算法LRU等等淘汰老的数据；随着系统规模的增长，单个节点cache不能知足要求，就须要搭建分布式Cache；为了解决单个节点失效引发的抖动 ，分布式cache通常采用一致性hash的解决方案，大大减小因单个节点失效引发的抖动范围；而对于可用性要求比较高的场景，每一个节点都是须要有备份的。数据在cache和存储上都存有同一份备份，必然有一致性的问题，一致性比较强的，在更新数据库的同时，更新数据库cache。对于一致性要求不高的，能够去设置缓存失效时间的策略。

Memcached做为高速的分布式缓存服务器，协议比较简单，基于libevent的事件处理机制。

Cache系统在平台中用在router系统的客户端中，热点的数据会缓存在客户端，当数据访问失效时，才去访问router系统。

固然目前更多的利用内存型的数据库作cache，好比redis、mongodb；redis比memcache有丰富的数据操做的API；redis和mongodb都对数据进行了持久化，而memcache没有这个功能，所以memcache更加适合在关系型数据库之上的数据的缓存。

 

Buffer系统

用在高速的写操做的场景中，平台中有些数据须要写入数据库，而且数据是分库分表的，但对数据的可靠性不是那么高，为了减小对数据库的写压力，能够采起批量写操做的方式。

开辟一个内存区域，当数据到达区域的必定阀值时如80%时，在内存中作分库梳理工做(内存速度仍是比较快的)，后分库批量flush。

6) 搜索

在电子商务平台中搜索是一个很是的重要功能，主要有搜索词类目导航、自动提示和搜索排序功能。

开源的企业级搜索引擎主要有lucene, sphinx，这里不去论述哪一种搜索引擎更好一些，不过选择搜索引擎除了基本的功能须要支持外，非功能方面须要考虑如下两点：

a、 搜索引擎是否支持分布式的索引和搜索，来应对海量的数据，支持读写分离，提升可用性

b、 索引的实时性

c、 性能

Solr是基于lucene的高性能的全文搜索服务器，提供了比lucene更为丰富的查询语言，可配置可扩展，对外提供基于http协议的XML/JSON格式的接口。

从Solr4版本开始提供了SolrCloud方式来支持分布式的索引，自动进行sharding数据切分；经过每一个sharding的master-slave(leader、replica)模式提升搜索的性能；利用zookeeper对集群进行管理，包括leader选举等等，保障集群的可用性。

Lucene索引的Reader是基于索引的snapshot的，因此必须在索引commit的后，从新打开一个新的snapshot，才能搜索到新添加的内容；而索引的commit是很是耗性能的，这样达到实时索引搜索效率就比较低下。

对于索引搜索实时性，Solr4的以前解决方案是结合文件全量索引和内存增量索引合并的方式，参见下图。

 

Solr4提供了NRT softcommit的解决方案，softcommit无需进行提交索引操做，就能够搜素到最新对索引的变动，不过对索引的变动并无sync commit到硬盘存储上，若发生意外致使程序非正常结束，未commit的数据会丢失，所以须要定时的进行commit操做。

平台中对数据的索引和存储操做是异步的，能够大大提升可用性和吞吐量；只对某些属性字段作索引操做，存储数据的标识key，减小索引的大小；数据是存储在分布式存储HBase 中的，HBase对二级索引搜索支持的很差，然而能够结合Solr搜索功能进行多维度的检索统计。

索引数据和HBase数据存储的一致性，也就是如何保障HBase存储的数据都被索引过，能够采用confirm确认机制，经过在索引前创建待索引数据队列，在数据存储并索引完成后，从待索引数据队列中删除数据。

 

 

7) 日志收集

在整个交易过程当中，会产生大量的日志，这些日志须要收集到分布式存储系统中存储起来，以便于集中式的查询和分析处理。

日志系统需具有三个基本组件，分别为agent（封装数据源，将数据源中的数据发送给collector），collector（接收多个agent的数据，并进行汇总后导入后端的store中），store（中央存储系统，应该具备可扩展性和可靠性，应该支持当前很是流行的HDFS）。

开源的日志收集系统业界使用的比较多的是cloudera的Flume和facebook的Scribe，其中Flume目前的版本FlumeNG对Flume从架构上作了较大的改动。

在设计或者对日志收集系统作技术选型时，一般须要具备如下特征：

a、 应用系统和分析系统之间的桥梁，将他们之间的关系解耦

b、 分布式可扩展，具备高的扩展性，当数据量增长时，能够经过增长节点水平扩展

日志收集系统是能够伸缩的，在系统的各个层次均可伸缩，对数据的处理不须要带状态，伸缩性方面也比较容易实现。

c、 近实时性

在一些时效性要求比较高的场景中，须要能够及时的收集日志，进行数据分析；

通常的日志文件都会定时或者定量的进行rolling，因此实时检测日志文件的生成，及时对日志文件进行相似的tail操做，并支持批量发送提升传输效率；批量发送的时机须要知足消息数量和时间间隔的要求。 

d、 容错性

Scribe在容错方面的考虑是，当后端的存储系统crash时，scribe会将数据写到本地磁盘上，当存储系统恢复正常后，scribe将日志从新加载到存储系统中。

FlumeNG经过Sink Processor实现负载均衡和故障转移。多个Sink能够构成一个Sink Group。一个Sink Processor负责从一个指定的Sink Group中激活一个Sink。Sink Processor能够经过组中全部Sink实现负载均衡；也能够在一个Sink失败时转移到另外一个。

e、 事务支持

Scribe没有考虑事务的支持。

Flume经过应答确认机制实现事务的支持，参见下图，

一般提取发送消息都是批量操做的，消息的确认是对一批数据的确认，这样能够大大提升数据发送的效率。

 

f、 可恢复性

FlumeNG的channel根据可靠性的要求的不一样，能够基于内存和文件持久化机制，基于内存的数据传输的销量比较高，可是在节点宕机后，数据丢失，不可恢复；而文件持久化宕机是能够恢复的。

g、 数据的定时定量归档

数据通过日志收集系统归集后，通常存储在分布式文件系统如Hadoop，为了便于对数据进行后续的处理分析，须要定时(TimeTrigger)或者定量(SizeTrigger的rolling分布式系统的文件。

8) 数据同步

在 交易系统中，一般须要进行异构数据源的同步，一般有数据文件到关系型数据库，数据文件到分布式数据库，关系型数据库到分布式数据库等。数据在异构源之间的 同步通常是基于性能和业务的需求，数据存储在本地文件中通常是基于性能的考虑，文件是顺序存储的，效率仍是比较高的；数据同步到关系型数据通常是基于查询 的需求；而分布式数据库是存储愈来愈多的海量数据的，而关系型数据库没法知足大数据量的存储和查询请求。

在数据同步的设计中须要综合考虑吞吐量、容错性、可靠性、一致性的问题

同步有实时增量数据同步和离线全量数据区分，下面从这两个维度来介绍一下，

实时增量通常是Tail文件来实时跟踪文件变化，批量或者多线程往数据库导出,这种方式的架构相似于日志收集框架。这种方式须要有确认机制，包括两个方面。

一个方面是Channel须要给agent确认已经批量收到数据记录了，发送LSN号给agent，这样在agent失效恢复时，能够从这个LSN点开始tail；固然对于容许少许的重复记录的问题(发生在channel给agent确认的时，agent宕机并未受到确认消息)，须要在业务场景中判断。

另一个方面是sync给channel确认已经批量完成写入到数据库的操做，这样channel能够删除这部分已经confirm的消息。

基于可靠性的要求，channel能够采用文件持久化的方式。

参见下图

离线全量遵循空间间换取时间，分而治之的原则，尽可能的缩短数据同步的时间，提升同步的效率。

须要对源数据好比MySQL进行切分，多线程并发读源数据，多线程并发批量写入分布式数据库好比HBase,利用channel做为读写之间的缓冲，实现更好的解耦，channel能够基于文件存储或者内存。参见下图：

对于源数据的切分，若是是文件能够根据文件名称设置块大小来切分。

对于关系型数据库，因为通常的需求是只离线同步一段时间的数据(好比凌晨把当天的订单数据同步到HBase)，因此须要在数据切分时(按照行数切分)，会多线程扫描整个表(及时建索引，也要回表)，对于表中包含大量的数据来说，IO很高，效率很是低；这里解决的方法是对数据库按照时间字段(按照时间同步的)创建分区，每次按照分区进行导出。

9) 数据分析

从传统的基于关系型数据库并行处理集群、用于内存计算近实时的，到目前的基于hadoop的海量数据的分析，数据的分析在大型电子商务网站中应用很是普遍，包括流量统计、推荐引擎、趋势分析、用户行为分析、数据挖掘分类器、分布式索引等等。

并行处理集群有商业的EMC Greenplum，Greenplum的架构采用了MPP(大规模并行处理)，基于postgresql的大数据量存储的分布式数据库。

内存计算方面有SAP的HANA，开源的nosql内存型的数据库mongodb也支持mapreduce进行数据的分析。

海量数据的离线分析目前互联网公司大量的使用Hadoop，Hadoop在可伸缩性、健壮性、计算性能和成本上具备无可替代的优点，事实上已成为当前互联网企业主流的大数据分析平台

Hadoop经过MapReuce的分布式处理框架，用于处理大规模的数据，伸缩性也很是好；可是MapReduce最大的不足是不能知足实时性的场景，主要用于离线的分析。

基于MapRduce模型编程作数据的分析，开发上效率不高，位于hadoop之上Hive的出现使得数据的分析能够相似编写sql的方式进行，sql通过语法分析、生成执行计划后最终生成MapReduce任务进行执行，这样大大提升了开发的效率，作到以ad-hoc(计算在query发生时)方式进行的分析。

基于MapReduce模型的分布式数据的分析都是离线的分析，执行上都是暴力扫描，没法利用相似索引的机制；开源的Cloudera Impala是基于MPP的并行编程模型的，底层是Hadoop存储的高性能的实时分析平台，能够大大下降数据分析的延迟。

目前Hadoop使用的版本是Hadoop1.0，一方面原有的MapReduce框架存在JobTracker单点的问题，另一方面JobTracker在作资源管理的同时又作任务的调度工做，随着数据量的增大和Job任务的增多，明显存在可扩展性、内存消耗、线程模型、可靠性和性能上的缺陷瓶颈；Hadoop2.0 yarn对整个框架进行了重构，分离了资源管理和任务调度，从架构设计上解决了这个问题。

参考Yarn的架构

10) 实时计算

在互联网领域，实时计算被普遍实时监控分析、流控、风险控制等领域。电商平台系统或者应用对平常产生的大量日志和异常信息，须要通过实时过滤、分析，以断定是否须要预警；

同时须要对系统作自我保护机制，好比对模块作流量的控制，以防止非预期的对系统压力过大而引发的系统瘫痪，流量过大时，能够采起拒绝或者引流等机制；有些业务须要进行风险的控制，好比彩票中有些业务须要根据系统的实时销售状况进行限号与放号。

原始基于单节点的计算，随着系统信息量爆炸式产生以及计算的复杂度的增长，单个节点的计算已不能知足实时计算的要求，须要进行多节点的分布式的计算，分布式实时计算平台就出现了。

这里所说的实时计算，实际上是流式计算，概念前身实际上是CEP复琐事件处理，相关的开源产品如Esper，业界分布式的流计算产品Yahoo S4,Twitter storm等，以storm开源产品使用最为普遍。

对于实时计算平台，从架构设计上须要考虑如下几个因素：

一、 伸缩性

随着业务量的增长，计算量的增长，经过增长节点处理，就能够处理。

二、 高性能、低延迟

从数据流入计算平台数据，到计算输出结果，须要性能高效且低延迟，保证消息获得快速的处理，作到实时计算。

三、 可靠性

保证每一个数据消息获得一次完整处理。

四、 容错性

系统能够自动管理节点的宕机失效，对应用来讲，是透明的。

Twitter的Storm在以上这几个方面作的比较好，下面简介一下Storm的架构。

整个集群的管理是经过zookeeper来进行的。

客户端提交拓扑到nimbus。

Nimbus针对该拓扑创建本地的目录根据topology的配置计算task，分配task，在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，Worker提供了一个transfer的功能，用于当前task把tuple发到到其余的task中。以目的taskid和tuple参数，序列化tuple数据并放到transfer queue中。

在0.8版本以前，这个queue是LinkedBlockingQueue，0.8以后是DisruptorQueue。

在0.8版本以后，每个woker绑定一个inbound transfer queue和outbond queue，inbound queue用于接收message，outbond queue用于发送消息。

发送消息时，由单个线程从transferqueue中拉取数据，把这个tuple经过zeroMQ发送到其余的woker中。

接收Tuple，每一个woker都会监听zeroMQ的tcp端口来接收消息，消息放到DisruptorQueue中后，后从queue中获取message(taskid,tuple)，根据目的taskid,tuple的值路由到task中执行。每一个tuple能够emit到direct steam中，也能够发送到regular stream中，在Reglular方式下，由Stream Group（stream id-->component id -->outbond tasks）功能完成当前tuple将要发送的Tuple的目的地。

经过以上分析能够看到，Storm在伸缩性、容错性、高性能方面的从架构设计的角度得以支撑；同时在可靠性方面，Storm的ack组件利用异或xor算法在不失性能的同时，保证每个消息获得完整处理的同时。 

 

11) 实时推送

实时推送的应用场景很是多，好比系统的监控动态的实时曲线绘制，手机消息的推送，web实时聊天等。

实时推送有不少技术能够实现，有Comet方式，有websocket方式等。

Comet基于服务器长链接的“服务器推”技术，包含两种：

Long Polling：服务器端在接到请求后挂起，有更新时返回链接即断掉，而后客户端再发起新的链接

Stream方式: 每次服务端数据传送不会关闭链接，链接只会在通讯出现错误时，或是链接重建时关闭（一些防火墙常被设置为丢弃过长的链接， 服务器端能够设置一个超时时间， 超时后通知客户端从新创建链接，并关闭原来的链接）。

Websocket：长链接，全双工通讯

是 Html5 的一种新的协议。它实现了浏览器与服务器的双向通信。webSocket API 中，浏览器和服务器端只须要经过一个握手的动做，便能造成浏览器与客户端之间的快速双向通道，使得数据能够快速的双向传播。

Socket.io是一个NodeJS websocket库，包括客户端的JS和服务端的的nodejs，用于快速构建实时的web应用。

12) 推荐引擎