一些常见的后端工具框架简介(1)--Hadoop，Memcached，Gunicorn

Hadoop

是一个由Apache基金会所开发的开源分布式系统基础架构，用户可以在不了解分布式底层细节的情况下，开发分布式程序，充分利用集群的威力进行高速运算和存储。是一个能够对大量数据进行分布式处理的软件框架(即大数据处理框架，包括搜集、存储、调度、查询、计算、输出等各个方面)，以一种可靠、高效、可伸缩的方式进行数据处理。(如图所示为大数据处理系统的生态圈，其中大部分为Hadoop的组件/子项目，Spark为新兴的具有发展潜力的框架)

优点

高可靠性，Hadoop按位存储和处理数据的能力值得人们信赖。
高扩展性，Hadoop是在可用的计算机集簇间分配数据并完成计算任务的，这些集簇可以方便地扩展到数以千计的节点中。
高效性，Hadoop能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快。
高容错性，Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配。
低成本，与一体机、商用数据仓库以及QlikView、Yonghong Z-Suite等数据集市相比，hadoop是开源的，项目的软件成本因此会大大降低。

核心子项目：

①HDFS(Hadoop Distributed File System)分布式文件存储系统，是分布式计算中数据存储管理的基础。
②MapReduce分布式计算模式，其是一种分布式运算技术，与Hadoop是相对独立的，Hadoop只是一个实现了MapReduce模式的框架。

其他子项目：

①HBase分布式列存数据库，是一个建立在HDFS之上，面向列的针对结构化数据的可伸缩、高可靠、高性能、分布式动态模式数据库。
②Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，通过类SQL语句快速实现MapReduce功能。
③YARN(Yet Another Resource Negotiator)集群资源管理和调度系统，是下一代的MapReduce，且整合了一些调度和管理的工具。
④其余如Zookeeper，Pig等都是一些工具或框架，协作用于大数据的处理。
可参https://www.cnblogs.com/hanzhi/articles/8969109.html

MapReduce简介

MapReduce是一种计算模型，该模型可以将大型数据处理任务分解成很多单个的、可以在服务器集群中并行执行的任务，而这些任务的计算结果可以合并在一起来计算最终的结果。
映射(Mapping):对集合里的每个目标应用同一个操作。
化简(Reducing):遍历集合中的元素来返回一个综合的结果。

MapReduce框架只操作键值对，其作业流程如下：
map阶段：①读取数据并格式化为键值对；②mapper，输入数据的处理，对于不同的业务有不同的处理方式；③partitioner，数据分组选择不同的reduce；
reduce阶段：①选择从某些map中拷贝部分结果(由map中数据分组决定)；②数据按照key排序；③reducer，数据处理，对于不同的业务有不同的处理方式；④数据输出格式化；
其中用户一般只需要实现mapper和reducer，其余按照默认格式即可。

HDFS简介

HDFS(Hadoop Distributed File System)分布式文件存储系统，是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是Google GFS存储系统的开源实现。
设计理念
①大数据文件存储，存储非常大的文件，甚至以PB为单位；
②文件分块存储，HDFS会将一个完整的大文件平均分块存储到不同计算器上，它的意义在于读取文件时可以同时从多个主机取不同区块的文件，多主机读取比单主机读取效率要高得多；
③流式数据访问，HDFS基于假设：最有效的数据处理模式是一次写入、多次读取数据集，经常从数据源生成或者拷贝一次，然后在其上做很多分析工作；
④商业硬件，HDFS可以应用在普通PC机上，这种机制能够让给一些公司用几十台廉价的计算机就可以撑起一个大数据集群；
⑤硬件故障，HDFS认为所有计算机都可能会出问题，为了防止某个主机失效读取不到该主机的块文件，它将同一个文件块副本分配到其它某几个主机上，如果其中一台主机失效，可以迅速找另一块副本取文件。

不适合的应用场景：
①低延时的数据访问，HDFS是为高吞吐数据传输设计的,因此可能牺牲延时HBase更适合低延时的数据访问；
②大量小文件，文件的元数据（如目录结构，文件block的节点列表，block-node mapping）保存在NameNode的内存中， 整个文件系统的文件数量会受限于NameNode的内存大小；
③多方读写，需要任意的文件修改，HDFS采用追加(append-only)的方式写入数据，不支持文件任意offset的修改，不支持多个写入器(writer)。

HDFS的核心概念
①blocks，HDFS的block默认为64/128M，
ⅠHDFS的文件被拆分成block-sized的chunk，chunk作为独立单元存储。比Block小的文件不会占用整个Block，只会占据实际大小；
ⅡHDFS的block特别大是为了最小化查找(seek)时间，根据FDFS的设计理念，定位到Block所用时间占传输时间的比例控制在1%；
Ⅲ将文件抽象为block，取消了磁盘容量对单个文件大小的限制，并简化了存储系统，对于block无需关注其权限、所有者等内容；Ⅳblock是FDFS系统中的基本单元，其容错、高可用等机制都建立在block的复制上进行。

②Namenode，管理者，其管理 HDFS 的名称空间，管理数据块（Block）映射信息，配置副本策略，处理客户端读写请求，存放文件系统树及所有文件、目录的元数据，但不包括Block所在的节点列表，及文件的Block分布节点，这些信息是在系统重启的时候重新构建（通过Datanode汇报的Block信息）。

③Datanode，从者，其根据NameNode下达的命令执行实际的操作，存储实际的数据块，执行数据块的读/写操作，读写请求可能来自namenode，也可能直接来自客户端，周期性向Namenode汇报自己节点上所存储的Block相关信息。
④Secondary Namenode，其并非NameNode的热备，当NameNode挂掉时它并不能马上替换并提供服务，辅助NameNode并分担其工作量，定期合并fsimage(镜像文件)和fsedits，并推送给NameNode，在紧急情况下，可辅助恢复NameNode。

HDFS的一些特殊机制
①NameNode的单点故障，在HDFS集群中，NameNode是单点故障，这是因为NameNode是唯一一个对文件元数据和file-block映射负责的地方，当NameNode故障时，整个文件系统是不可用的，常规的做法是使用元数据备份重新启动一个NameNode。元数据备份可能来源于：Ⅰ多文件系统写入中的备份ⅡSecond NameNode的检查点文件。

②Block Caching，DataNode通常直接从磁盘读取数据，但是频繁使用的Block可以在内存中缓存。默认情况下，一个Block只有一个数据节点会缓存。但是可以针对每个文件可以个性化配置，用户/应用可以向NameNode发送缓存指令(缓存哪个文件，缓存多久)，缓存池的概念用于管理一组缓存的权限和资源。

③HDFS Federation，NameNode的内存会制约文件数量，HDFS Federation提供了一种横向扩展NameNode的方式，在Federation模式中，每个NameNode管理命名空间的一部分，分管不同的目录，所有的NameNode共同构成文件系统的命名空间，但是对于特定的NN，依然存在单点故障。

④HDFS HA(High Availability高可用性)，采用HA的HDFS集群配置两个NameNode，分别处于Active和Standby状态。当Active NameNode故障之后，Standby接过责任继续提供服务，用户没有明显的中断感觉，一般耗时在几十秒到数分钟。
其需要实现的逻辑有：
Ⅰ主备共享edit log存储，主NameNode和待命的NameNode共享一份edit log，当主备切换时，Standby通过回放edit log同步数据，共享存储有两个选择：NFS传统的网络文件系统，QJM(quorum journal manager),QJM是专门为HDFS的HA实现而设计的，用来提供高可用的edit log；
Ⅱ DataNode需要同时往主备发送Block Report，因为Block映射数据存储在内存中（不是在磁盘上），为了在Active NameNode挂掉之后，新的NameNode能够快速启动，不需要等待来自Datanode的Block Report，DataNode需要同时向主备两个NameNode发送Block Report；
Ⅲ客户端需要配置failover模式（失效备援模式，对用户透明），Namenode的切换对客户端来说是无感知的，通过客户端库来实现；
ⅣStandby替代Secondary NameNode。

HDFS副本存放策略
如图所示。

HDFS中文件的读取流程
①客户端传递一个文件Path给FileSystem的open方法；
②DFS采用RPC远程获取文件最开始的几个block的datanode地址，Namenode会根据网络拓扑结构决定返回哪些节点（前提是节点有block副本），如果客户端本身是Datanode并且节点上刚好有block副本，直接从本地读取；
③客户端使用open方法返回的FSDataInputStream对象读取数据（调用read方法）；
④DFSInputStream（FSDataInputStream实现了改类）连接持有第一个block的、最近的节点，反复调用read方法读取数据；
⑤第一个block读取完毕之后，寻找下一个block的最佳datanode，读取数据。如果有必要，DFSInputStream会联系Namenode获取下一批Block 的节点信息(存放于内存，不持久化），这些寻址过程对客户端都是不可见的；
⑥数据读取完毕，客户端调用close方法关闭流对象；

注：①在读数据过程中，如果与Datanode的通信发生错误，DFSInputStream对象会尝试从下一个最佳节点读取数据，并且记住该失败节点， 后续Block的读取不会再连接该节点；
②读取一个Block之后，DFSInputStram会进行检验和验证，如果Block损坏，尝试从其他节点读取数据，并且将损坏的block汇报给Namenode；
③客户端连接哪个datanode获取数据，是由namenode来指导的，这样可以支持大量并发的客户端请求，namenode尽可能将流量均匀分布到整个集群；
④Block的位置信息是存储在namenode的内存中，因此相应位置请求非常高效，不会成为瓶颈。

HDFS中文件的写入流程
①客户端调用DistributedFileSystem的create方法；
②DistributedFileSystem远程RPC调用Namenode在文件系统的命名空间中创建一个新文件，此时该文件没有关联到任何block。 这个过程中，Namenode会做很多校验工作，例如是否已经存在同名文件，是否有权限，如果验证通过，返回一个FSDataOutputStream对象。 如果验证不通过，抛出异常到客户端；
③客户端写入数据的时候，DFSOutputStream分解为packets（数据包），并写入到一个数据队列中，该队列由DataStreamer消费；
④DateStreamer负责请求Namenode分配新的block存放的数据节点。这些节点存放同一个Block的副本，构成一个管道。 DataStreamer将packet写入到管道的第一个节点，第一个节点存放好packet之后，转发给下一个节点，下一个节点存放 之后继续往下传递；
⑤DFSOutputStream同时维护一个ack queue队列，等待来自datanode确认消息。当管道上的所有datanode都确认之后，packet从ack队列中移除；
⑥数据写入完毕，客户端close输出流。将所有的packet刷新到管道中，然后安心等待来自datanode的确认消息。全部得到确认之后告知Namenode文件是完整的。 Namenode此时已经知道文件的所有Block信息（因为DataStreamer是请求Namenode分配block的），只需等待达到最小副本数要求，然后返回成功信息给客户端。

HDFS的使用方法及配置
此处略，其一般用于大数据处理时的存储，在具体项目实战中再行应用掌握。

Memcached

是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高动态、数据库驱动网站的速度。Memcached基于一个存储键/值对的hashmap。

基本特点：
①协议简单：使用基于文本行的协议，二进制协议使用比较少；
②基于内存存储，与redis不同的，其完全基于内存(redis可以定期将数据保存至磁盘)，且不支持持久化，因此断电数据即丢失；
③事件处理：基于libevent(一个异步的事件处理库)开发，所以可以应对C10问题；
④不互相通信的分布式：多台memcached服务器之间不互相通信，由客户端实现分布式算法，所以通常客户端使用一致性hash策略，通常拥有快隔离，慢恢复的特性。
在Memcached中，每条记录都由四部分组成：记录的键，有效期，一系列可选的标记以及表示记录内容的数据。由于记录内容的数据中并不包含任何数据结构，因此在Memcached中所记录的数据需要是经过序列化之后的表示，一般使用json。

与redis的对比：
①数据结构：redis5种，memcached只支持简单的kv；
②可靠性：redis支持持久化，memcached不支持持久化；
③内存管理：redis是申请内存机制，理论上可以存储比内存容量更多的数据(可以持久化)，memcached使用预分配池管理，速度更快，redis更适合做数据存储，memcache更适合做缓存；
④数据一致性：memcache提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。 redis是串行操作，所以不用考虑数据一致性的问题；
⑤IO角度：都选用非阻塞的I/O多路复用模型，但memcached因为支持功能少，速度更快；
⑥线程：redis使用单线程，只能多开来解决，memcached使用多线程，需要考虑锁的问题；
⑦集群：redis天然支持高可用集群，支持主从，而memcache需要自己实现类似一致性hash的负载均衡算法才能解决集群的问题(如搭配Keepalived实现主从复制从而实现高可用集群)，扩展性比较低。
综合来说，redis比memcached功能更全，集成更方便，但是memcache相比redis在内存、线程、IO角度来说都有一定的优势，可以利用cpu提高机器性能，在不考虑扩展性和持久性的访问频繁的情况下，只存储kv格式的数据，建议使用memcache，memcache更像是个缓存，而redis更偏向于一个存储数据的系统。

不适用的场景：
①缓存对象的大小超过1M；
②key的长度过长，超过250个字符；
③应用运行在不安全的环境中(memcached本身未提供任何安全策略)

使用与配置：
memcached的使用较为简单，一般在特定的语言环境下讨论。
set key flags exptime bytes [noreply] / gets key1 key2 key3
key：键值 key-value 结构中的 key，用于查找缓存值。
flags：可以包括键值对的整型参数，客户机使用它存储关于键值对的额外信息 。
exptime：在缓存中保存键值对的时间长度（以秒为单位，0 表示永远）。
bytes：在缓存中存储的字节数。
noreply（可选）： 该参数告知服务器不需要返回数据。
value：存储的值（始终位于第二行）（可直接理解为key-value结构中的value）
配置方面根据不同的环境和后端语言略有不同。

Gunicorn

“绿色独角兽”是一个被广泛使用的高性能的Python WSGI UNIX HTTP服务器，移植自Ruby的独角兽（Unicorn）项目, 具有使用非常简单，轻量级的资源消耗，以及高性能等特点。Gunicorn 服务器作为wsgi app的容器，能够与各种Web框架兼容（flask，django等）,得益于gevent等技术，使用Gunicorn能够在基本不改变wsgi app代码的前提下，大幅度提高wsgi app的性能。　
Gunicorn使用prefork master-worker模型（在gunicorn中，master被称为arbiter），有一个中心管理进程(master process)用来管理worker进程集合，Master从不知道任何关于客户端的信息，所有的请求和响应处理都是由worker进程来处理的。

master(管理者)：主程序是一个简单的循环,监听各种信号以及相应的响应进程，master管理着正在运行的worker集合,通过监听各种信号比如TTIN, TTOU, and CHLD. TTIN and TTOU响应的增加和减少worker的数目。
worker：woker有很多种，包括：ggevent、geventlet、gtornado等，能够处理高并发/多任务。
使用方法：参flask部署。



以上内容总结自网络博客资料，大部分内容参考文章如下：
https://www.cnblogs.com/hanzhi/articles/8969109.html
https://blog.csdn.net/yuan_xw/article/details/50003197
https://blog.csdn.net/v_july_v/article/details/6704077
https://cloud.tencent.com/developer/ask/137599
https://blog.csdn.net/weixin_41910244/article/details/80412209
https://blog.csdn.net/lhx574938077/article/details/81838819