高并发电子商务平台技术架构

原文出自：http://blog.csdn.net/yangbutao/article/details/12242441

http://stamen.iteye.com/blog/1525924

我本身的大型B2B和B2C站点原来也是用Hibernate，但是后来不得不换成mybatis，
第一是用Hibernate 由于它封装得过高了。很是多东西是隐式进行的。经常引发问题，很是难定位。毕竟凡事有利必有弊；
第二大型站点确定不是一个数据库。这点Hibernate是很是麻烦的，用Jdbc或Mybatis 可以轻松应付之。我本身写的shard分库框架眼下就是支持mybatis和Jdbc Template。
    另，认为割舍不了Hibernate的iteyer,事实上也是建议直接再用Hibernate，待遇到痛苦时。再换，这样体会会更深些

    个人技术选型和onecan的相似，差异在于：

1.缓存：我採用ehcache+memcached结合的方式，ehcache作JVM本地缓存。memcached作进程外全局缓存，即由本地缓存和全局缓存构成系统的二级缓存；

2.数据库上。你用单数据库确定是不行的。

个人平台是划分为100多个库。早期我採用淘宝的amoeba(陈师儒兄写的)分库技术（事实上是一个分库中间件。经过一台代理amoeba实现对后端mysql集群的透明化代理。

后来发现问题多多，还有一个是中间件方案尽管使用简单。但不够灵活，不能作多数据库事务，因此弃之。不得以本身写了一个基于Java的分库框架。即Shard。在应用层直接经过Shard操做数据库集群；

3.全文索引，咱们採用Solr，只是眼下想把它换成ElasticSearch,因为Solr的全文索引同步比較慢，延时是一个很是大的问题，ES作得好些。

4.任务调度你这里没有讲，事实上这块对于大型站点是很是重要的。我是基于Quautz本身写了一个全局任务调度框架。至关于任务调度云的方式。

如天天晚上汇总数据。按期迁移数据等就可以很是好地使用任务调度来完毕。

5.编码生成：凡是商城或应用系统，确定是要有一个编码生成的框架，如单据号，商品编号等，要求是全局惟一。规则可本身定义。这个我是基于Spring Expression写了一个全局的编码框架。称为codeman,后面我也拟把它开源出来；

6.开放平台：假设你的商城要赞成多终端接入，如iphone,android,PCclient,或者第三方。则必定要有一条服务总线，如淘宝的TOP。这个原来是用Spring MVC直接写的，后来发现新增功能太麻烦。开发效率过低了。所以我就基于Spring MVC框架的设计思路和TOP的应用模型写了一个Rop框架。这个已经开源的。參见我这个帖子：http://www.iteye.com/topic/1121252

7.NoSQL和mySQL结合。mySQL毕竟是关系型的，对于高并发的数据。咱们是放到mogonDB中的，这个数据库的压力会小很是多。

8.日志的记录：大型站点的日志记录是很是重要的，是审计，问题定位的根据。原来早期，我直接把日志记录到MySQL中，日志很是大。数据库压力大。后来把它直接异步到Elastic Search中，不但可以全文检索。并发性大时也没有问题。
此外。对日志编写了一些分析引擎，可以从日志中发现关键的问题，即时报警。

9.会话管理的问题：由于应用服务节点很是多，所以弃用Web应用server自己的Session功能，直接本身编写了一个全局会话管理功能。以实现全局统一的会话管理。

10.图片server独立，每张图片仅仅保存一张物理的，事实上不一样规格的图片动态生成并放到内存中；

11.项目採用敏捷开发。DDT,Maven等。

1、 设计理念

 

 

1.      空间换时间

1)      多级缓存，静态化

client页面缓存（http header中包括Expires/Cache of Control。last modified(304，server不返回body，client可以继续用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而缺少灵活性；通常基于商用的硬件F5、NetScaler或者开源的软负载lvs在4层作分发，固然会採用作冗余(比方lvs+keepalived)的考虑，採取主备方式。

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

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

LVS。工做在4层，Linux实现的高性能高并发、可伸缩性、可靠的的负载均衡器。支持多种转发方式(NAT、DR、IP Tunneling)，当中DR模式支持经过广域网进行负载均衡。

支持双机热备(Keepalived或者Heartbeat)。对网络环境的依赖性比較高。

Nginx工做在7层。事件驱动的、异步非堵塞的架构、支持多进程的高并发的负载均衡器/反向代理软件。可以针对域名、文件夹结构、正则规则针对http作一些分流。经过port检測到server内部的故障。比方依据server处理网页返回的状态码、超时等等。并且会把返回错误的请求又一次提交到还有一个节点，只是当中缺点就是不支持url来检測。

对于session sticky。可以基于ip hash的算法来实现，经过基于cookie的扩展nginx-sticky-module支持session sticky。

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

对于图片，需要有单独的域名。独立或者分布式的图片server或者如mogileFS。可以图片server之上加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) 通讯组件

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

整个通讯组件包含client和服务端两部分。

client和server端维护的是长链接，可以下降每次请求创建链接的开销，在client对于每个server定义一个链接池，初始化链接后。可以并发链接服务端进行rpc操做，链接池中的长链接需要心跳维护，设置请求超时时间。

对于长链接的维护过程可以分两个阶段。一个是发送请求过程。另一个是接收响应过程。在发送请求过程当中。若发生IOException，则把该链接标记失效。

接收响应时，服务端返回SocketTimeoutException，假设设置了超时时间，那么就直接返回异常，清除当前链接中那些超时的请求。不然继续发送心跳包(因为多是丢包，超过pingInterval间隔时间就发送ping操做)，若ping不通(发送IOException)。则说明当前链接是有问题的。那么就把当前链接标记成已经失效；若ping通，则说明当前链接是可靠的，继续进行读操做。

失效的链接会从链接池中清除掉。

每个链接对于接收响应来讲都以单独的线程执行，client可以经过同步(wait,notify)方式或者异步进行rpc调用，

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

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

 

2) 路由Router

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

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

对于訪问数据库client来说，需要依据用户的ID，定位到需要訪问的数据；

数据切分算法，

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

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

这样每个bizclient都需要保持所有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作分布式的协调，实现集群的列表维护和失效通知，client可以选择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做为快速的分布式缓存server。协议比較简单。基于libevent的事件处理机制。

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

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

 

Buffer系统

用在快速的写操做的场景中，平台中有些数据需要写入数据库。并且数据是分库分表的，但对数据的可靠性不是那么高，为了下降对数据库的写压力。可以採取批量写操做的方式。

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

6) 搜索

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

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

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

b、 索引的实时性

c、 性能

Solr是基于lucene的高性能的全文搜索server。提供了比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、 分布式可扩展。具备高的扩展性。当数据量添加时。可以经过添加节点水平扩展

日志收集系统是可以伸缩的，在系统的各个层次均可伸缩。对数据的处理不需要带状态，伸缩性方面也比較easy实现。

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来进行的。

client提交拓扑到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的tcpport来接收消息，消息放到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基于server长链接的“server推”技术，包括两种：

Long Polling：server端在接到请求后挂起。有更新时返回链接即断掉，而后client再发起新的链接

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

Websocket：长链接。全双工通讯

是 Html5 的一种新的协议。它实现了浏览器与server的双向通信。webSocket API 中。浏览器和server端仅仅需要经过一个握手的动做。便能造成浏览器与client之间的高速双向通道，使得数据可以高速的双向传播。

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

12) 推荐引擎

 待补充

 

6. 数据存储

数据库存储大致分为如下几类。有关系型（事务型）的数据库。以oracle、mysql为表明，有keyvalue数据库。以redis和memcached db为表明。有文档型数据库如mongodb，有列式分布式数据库以HBase，cassandra,dynamo为表明。还有其它的图形数据库、对象数据 库、xml数据库等。

每种类型的数据库应用的业务领域是不同的，如下从内存型、关系型、分布式三个维度针对相关的产品作性能可用性等方面的考量分析。

1) 内存型数据库

内存型的数据库，以高并发高性能为目标，在事务性方面没那么严格，以开源nosql数据库mongodb、redis为例

Ø Mongodb

通讯方式

多线程方式，主线程监听新的链接。链接后，启动新的线程作数据的操做（IO切换）。

数据结构

 

 

数据库-->collection-->record

MongoDB在数据存储上按命名空间来划分，一个collection是一个命名空间，一个索引也是一个命名空间。

同一个命名空间的数据被分红很是多个Extent，Extent之间使用双向链表链接。

在每一个Extent中，保存了详细每一行的数据，这些数据也是经过双向连接链接的。

每一行数据存储空间不只包括数据占用空间，还可能包括一部分附加空间。这使得在数据update变大后可以不移动位置。

索引以BTree结构实现。

假设你开启了jorunaling日志，那么还会有一些文件存储着你所有的操做记录。

 

 

持久化存储

MMap方式把文件地址映射到内存的地址空间，直接操做内存地址空间就可以操做文件，不用再调用write,read操做。性能比較高。

mongodb调用mmap把磁盘中的数据映射到内存中的，因此必须有一个机制时刻的刷数据到硬盘才干保证可靠性。多久刷一次是与syncdelay參数相关的。

 journal（进行恢复用）是Mongodb中的redo log。而Oplog则是负责复制的binlog。假设打开journal，那么即便断电也仅仅会丢失100ms的数据，这对大多数应用来讲都可以容忍了。

从1.9.2+，mongodb都会默认打开journal功能，以确保数据安全。而且journal的刷新时间是可以改变的，2-300ms的范围,使用 --journalCommitInterval 命令。Oplog和数据刷新到磁盘的时间是60s，对于复制来讲，不用等到oplog刷新磁盘，在内存中就可以直接拷贝到Sencondary节点。

 

事务支持

Mongodb仅仅支持对单行记录的原子操做

 

HA集群

用的比較多的是Replica Sets，採用选举算法。本身主动进行leader选举。在保证可用性的同一时候。可以作到强一致性要求。

 

固然对于大量的数据，mongodb也提供了数据的切分架构Sharding。

 

Ø Redis

丰富的数据结构，快速的响应速度，内存操做

通讯方式

因都在内存操做，因此逻辑的操做很快，下降了CPU的切换开销。因此为单线程的模式（逻辑处理线程和主线程是一个）。

 reactor模式。实现本身的多路复用NIO机制（epoll，select，kqueue等）

 单线程处理多任务

数据结构

  hash+bucket结构，当链表的长度过长时，会採取迁移的措施（扩展原来两倍的hash表，把数据迁移过去，expand+rehash）

 

持久化存储

a、全量持久化RDB（遍历redisDB,读取bucket中的key,value），save命令堵塞主线程，bgsave开启子进程进行snapshot持久化操做。生成rdb文件。

 在shutdown时。会调用save操做

 数据发生变化，在多少秒内触发一次bgsave

sync。master接受slave发出来的命令

b、增量持久化（aof相似redolog），先写到日志buffer,再flush到日志文件里（flush的策略可以配置的。而已单条。也可以批量），仅仅有flush到文件上的，才真正返回client。

要定时对aof文件和rdb文件作合并操做（在快照过程当中，变化的数据先写到aof buf中等子进程完毕快照<内存snapshot>后。再进行合并aofbuf变化的部分以及全镜像数据）。

在高并发訪问模式下，RDB模式使服务的性能指标出现明显的抖动。aof在性能开销上比RDB好，但是恢复时又一次载入到内存的时间和数据量成正比。

 

集群HA

通用的解决方式是主从备份切换，採用HA软件，使得失效的主redis可以高速的切换到从redis上。主从数据的同步採用复制机制，该场景可以作读写分离。

眼下在复制方面。存在的一个问题是在遇到网络不稳定的状况下。Slave和Master断开（包含闪断）会致使Master需要将内存中的数据全部又一次生成rdb文件（快照文件），而后传输给Slave。

Slave接收完Master传递过来的rdb文件之后会将自身的内存清空，把rdb文件又一次载入到内存中。这样的方式效率比較低下，在后面的将来版本号Redis2.8做者已经实现了部分复制的功能。

2) 关系型数据库

关系型数据库在知足并发性能的同一时候。也需要知足事务性，以mysql数据库为例。讲述架构设计原理，在性能方面的考虑。以及怎样知足可用性的需求。

 

Ø mysql的架构原理(innodb)

在架构上，mysql分为server层和存储引擎层。

Server层的架构对于不一样的存储引擎来说都是同样的,包含链接/线程处理、查询处理(parser、optimizer)以及其它系统任务。

存储引擎层有很是多种，mysql提供了存储引擎的插件式结构，支持多种存储引擎。用的最普遍的是innodb和myisamin。inodb主要面向OLTP方面的应用，支持事务处理，myisam不支持事务，表锁，对OLAP操做速度快。

下面主要针对innodb存储引擎作相关介绍。

 

 

 

在线程处理方面，Mysql是多线程的架构，由一个master线程。一个锁监控线程，一个错误监控线程，和多个IO线程组成。并且对一个链接会开启一个线程进行服务。

io线程又分为节省随机IO的insert buffer。用于事务控制的相似于oracle的redo log，以及多个write。多个read的硬盘和内存交换的IO线程。

在内存分配方面，包含innodb buffer pool ，以及log buffer。

当中innodb buffer pool包含insert buffer、datapage、index page、数据字典、自适应hash。Log buffer用于缓存事务日志，提供性能。

在数据结构方面，innodb包含表空间、段、区、页/块，行。

索引结构是B+tree结构，包含二级索引和主键索引。二级索引的叶子节点是主键PK，依据主键索引的叶子节点指向存储的数据块。这样的B+树存储结构可以更好的知足随机查询操做IO要求，分为数据页和二级索引页，改动二级索引页面涉及到随机操做，为了提升写入时的性能，採用insert buffer作顺序的写入，再由后台线程以必定频率将多个插入合并到二级索引页面。

为了保证数据库的一致性(内存和硬盘数据文件)，以及缩短实例恢复的时间，关系型数据库另外一个checkpoint的功能，用于把内存buffer中以前的脏页依照比例(老的LSN)写入磁盘，这样redolog文件的LSN曾经的日志就可以被覆盖了，进行循环使用；在失效恢复时，仅仅需要从日志中LSN点进行恢复就能够。

在事务特性支持上。关系型数据库需要知足ACID四个特性，需要依据不一样的事务并发和数据可见性要求，定义了不一样的事务隔离级别，并且离不开对资源争用的锁机制。要避免产生死锁。mysql在Server层和存储引擎层作并发控制，主要体现在读写锁，依据锁粒度不一样，有各个级别的锁(表锁、行锁、页锁、MVCC)；基于提升并发性能的考虑，使用多版本号并发控制MVCC来支持事务的隔离。并基于undo来实现，在作事务回滚时。也会用到undo段。

mysql 用redolog来保证数据的写入的性能和失效恢复。在改动数据时仅仅需要改动内存，再把改动行为记录到事务日志中(顺序IO)。不用每次将数据改动自己持久化到硬盘(随机IO)，大大提升性能。

在可靠性方面。innodb存储引擎提供了两次写机制double writer用于防止在flush页面到存储上出现的错误。解决磁盘half-writern的问题。

 

Ø 对于高并发高性能的mysql来说，可以在多个维度进行性能方面的调优。

a、硬件级别，

日志和数据的存储，需要分开，日志是顺序的写。需要作raid1+0。并且用buffer-IO。数据是离散的读写。走direct IO就能够，避免走文件系统cache带来的开销。

存储能力，SAS盘raid操做（raid卡缓存，关闭读cache，关闭磁盘cache，关闭预读，仅仅用writeback buffer，只是需要考虑充放电的问题）。固然假设数据规模不大。数据的存储可以用快速的设备，Fusion IO、SSD。

对于数据的写入，控制脏页刷新的频率。对于数据的读取，控制cache hit率；所以而估算系统需要的IOPS，评估需要的硬盘数量(fusion io上到IOPS 在10w以上，普通的硬盘150)。

Cpu方面，单实例关闭NUMA，mysql对多核的支持不是太好，可以对多实例进行CPU绑定。

b、操做系统级别，

内核以及socket的优化，网络优化bond、文件系统、IO调度

innodb主要用在OLTP类应用，通常都是IO密集型的应用。在提升IO能力的基础上，充分利用cache机制。

需要考虑的内容有。

在保证系统可用内存的基础上，尽量的扩大innodb buffer pool，通常设置为物理内存的3/4

文件系统的使用。仅仅在记录事务日志的时候用文件系统的cache；尽可能避免mysql用到swap(可以将vm.swappiness=0，内存紧张时。释放文件系统cache)

IO调度优化，下降没必要要的堵塞，下降随机IO訪问的延时(CFQ、Deadline、NOOP)

c、server以及存储引擎级别（链接管理、网络管理、table管理、日志）

包含cache/buffer、Connection、IO

d、应用级别（比方索引的考虑，schema的优化适当冗余。优化sql查询致使的CPU问题和内存问题。下降锁的范围，下降回表扫描，覆盖索引）

Ø 在高可用实践方面，

支持master-master、master-slave模式。master-master模式是一个做为主负责读写，另一个做为standby提供灾备，maser-slave是一个做为主提供写操做，其它几个节点做为读操做，支持读写分离。

对于节点主备失效检測和切换，可以採用HA软件，固然也可以从更细粒度定制的角度，採用zookeeper做为集群的协调服务。

对于分布式的系统来说，数据库主备切换的一致性始终是一个问题，可以有下面几种方式：

a、集群方式，如oracle的rack，缺点是比較复杂

b、共享SAN存储方式，相关的数据文件和日志文件都放在共享存储上。长处是主备切换时数据保持一致，不会丢失。但由于备机有一段时间的拉起，会有短暂的不可用状态

c、主备进行数据同步的方式，常见的是日志的同步，可以保障热备，实时性好，但是切换时。可能有部分数据没有同步过来，带来了数据的一致性问题。可以在操做主数据库的同一时候，记录操做日志，切换到备时，会和操做日志作个check。补齐未同步过来的数据；

d、另外一种作法是备库切换到主库的regolog的存储上。保证数据不丢失。

数据库主从复制的效率在mysql上不是过高，主要缘由是事务是严格保持顺序的，索引mysql在复制方面包含日志IO和relog log两个过程都是单线程的串行操做，在数据复制优化方面。尽可能下降IO的影响。

只是到了Mysql5.6版本号，可以支持在不一样的库上的并行复制。

Ø 基于不一样业务要求的存取方式

平台业务中。不一样的业务有不一样的存取要求，比方典型的两大业务用户和订单，用户通常来说总量是可控的，而订单是不断地递增的，对于用户表首先採取分库切分，每个sharding作一主多读。相同对于订单因不少其它需求的是用户查询本身的订单，也需要依照用户进行切分订单库。并且支持一主多读。

在硬件存储方面，对于事务日志因是顺序写。闪存的优点比硬盘高不了多少，因此採取电池保护的写缓存的raid卡存储；对于数据文件，无论是对用户或者订单都会存在大量的随机读写操做，固然加大内存是一个方面，另外可以採用快速的IO设备闪存，比方PCIe卡 fusion-io。

使用闪存也适合在单线程的负载中，比方主从复制，可以对从节点配置fusion-IO卡，减小复制的延迟。

对于订单业务来说，量是不断递增的，PCIe卡存储容量比較有限。并且订单业务的热数据仅仅有近期一段时间的(比方近3个月的)。对此这里列两种解决方式，一种是flashcache方式，採用基于闪存和硬盘存储的开源混合存储方式，在闪存中存储热点的数据。第二种是可以按期把老的数据导出到分布式数据库HBase中，用户在查询订单列表是近期的数据从mysql中获取，老的数据可以从HBase中查询。固然需要HBase良好的rowkey设计以适应查询需求。

 

 

3) 分布式数据库

对于数据的高并发的訪问。传统的关系型数据库提供读写分离的方案，但是带来的确实数据的一致性问题提供的数据切分的方案；对于愈来愈多的海量数据。传统的数据库採用的是分库分表，实现起来比較复杂，后期要不断的进行迁移维护；对于高可用和伸缩方面，传统数据採用的是主备、主从、多主的方案。但是自己扩展性比較差，添加节点和宕机需要进行数据的迁移。对于以上提出的这些问题。分布式数据库HBase有一套无缺的解决方式，适用于高并发海量数据存取的要求。

 

Ø HBase

基于列式的高效存储减小IO
一般的查询不需要一行的全部字段，大多数仅仅需要几个字段
对与面向行的存储系统，每次查询都会全部数据取出，而后再从中选出需要的字段
面向列的存储系统可以单独查询某一列。从而大大减小IO
提升压缩效率
同列数据具备很是高的类似性，会添加压缩效率
Hbase的很是多特性。都是由列存储决定的

高性能

LSM Tree

适合快速写的场景

 

 

强一致的数据訪问

MVCC

HBase的一致性数据訪问是经过MVCC来实现的。

HBase在写数据的过程当中，需要通过好几个阶段，写HLog。写memstore，更新MVCC;

仅仅有更新了MVCC，才算真正memstore写成功，当中事务的隔离需要有mvcc的来控制，比方读数据不可以获取别的线程还未提交的数据。

高可靠

HBase的数据存储基于HDFS。提供了冗余机制。

Region节点的宕机，对于内存中的数据还未flush到文件里，提供了可靠的恢复机制。

  

 

可伸缩。本身主动切分。迁移

经过Zookeeper定位目标Region Server，最后定位Region。 

Region Server扩容，经过将自身公布到Master，Master均匀分布。

 

可用性

存在单点故障，Region Server宕机后，短期内该server维护的region没法訪问。等待failover生效。 

经过Master维护各Region Server健康情况和Region分布。

多个Master。Master宕机有zookeeper的paxos投票机制选取下一任Master。

Master就算全宕机，也不影响Region读写。

Master仅充当一个本身主动运维角色。

HDFS为分布式存储引擎，一备三，高可靠，0数据丢失。

HDFS的namenode是一个SPOF。

为避免单个region訪问过于频繁，单机压力过大，提供了split机制

HBase的写入是LSM-TREE的架构方式，随着数据的append，HFile愈来愈多。HBase提供了HFile文件进行compact，对过时数据进行清除。提升查询的性能。

Schema free

HBase没有像关系型数据库那样的严格的schema，可以自由的添加和删除schema中的字段。

 

HBase分布式数据库。对于二级索引支持的不太好，眼下仅仅支持在rowkey上的索引，因此rowkey的设计对于查询的性能来说很关键。

7. 管理与部署配置

统一的配置库

部署平台

 

 

8. 监控、统计

 

大型分布式系统涉及各类设备。比方网络交换机，普通PC机。各类型号的网卡。硬盘，内存等等，还有应用业务层次的监控。数量许多的时候，出现错误的几率也会变大，并且有些监控的时效性要求比較高，有些达到秒级别；在大量的数据流中需要过滤异常的数据，有时候也对数据会进行上下文相关的复杂计算，进而决定是否需要告警。所以监控平台的性能、吞吐量、已经可用性就比較重要，需要规划统一的一体化的监控平台对系统进行各个层次的监控。

 

平台的数据分类

应用业务级别：应用事件、业务日志、审计日志、请求日志、异常、请求业务metrics、性能度量

系统级别：CPU、内存、网络、IO

 

时效性要求

阀值。告警：

实时计算：

近实时分钟计算

按小时、天的离线分析

实时查询

 

架构

节点中Agent代理可以接收日志、应用的事件以及经过探针的方式採集数据，agent採集数据的一个原则是和业务应用的流程是异步隔离的。不影响交易流程。

数据统一经过collector集群进行收集，依照数据的不一样类型分发到不一样的计算集群进行处理；有些数据时效性不是那么高，比方按小时进行统计，放入hadoop集群；有些数据是请求流转的跟踪数据，需要可以查询的，那么就可以放入solr集群进行索引；有些数据需要进行实时计算的进而告警的，需要放到storm集群中进行处理。

数据通过计算集群处理后。结果存储到Mysql或者HBase中。

监控的web应用可以把监控的实时结果推送到浏览器中，也可以提供API供结果的展示和搜索。