构建高并发高可用的电商平台架构实践2

上次发布内容：

如没有接上，可以查看下面原文：

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开源产品使用最为广泛。 对于实时计算平台，从架构设计上需要考虑以下几个因素： 1、 伸缩性 随着业务量的增加，计算量的增加，通过增加节点处理，就可以处理。 2、 高性能、低延迟 从数据流入计算平台数据，到计算输出结果，需要性能高效且低延迟，保证消息得到快速的处理，做到实时计算。 3、 可靠性 保证每个数据消息得到一次完整处理。 4、 容错性 系统可以自动管理节点的宕机失效，对应用来说，是透明的。 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应用。 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到文件上的，才真正返回客户端。 要定时对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供结果的展现和搜索。

完毕.