Zookeeper

作用：Zookeeper是分布式协调服务，主要提供文件系统和通知机制2个功能；

文件系统：提供多层级节点空间的树状结构，每个节点都可以存数据（包括目录），由于数据存放于内存，所有不能存储大量数据，单节点1M；

节点znode类型：持久节点、持久有序节点、临时节点、临时有序节点；临时节点会话断开自动删除；有序通过父节点生成自增整数；

通知机制watcher：客户端注册某个znode节点的watcher（将watcher封装到请求中）、服务端处理watcher（解析请求中的watcher放入注册管理器，后续请求解析时判断是否有watcher，有则通过TCP发送通知）、客户端回调watcher（线程接收事件处理）；watcher是一次性的，触发后删除，避免节点频繁变更的性能问题；轻量，不传实体只传boolean；

ACL（Access Control List）：包括权限模式（授权方式）、授权对象（IP）、权限（CREATE、DELETE、READ、WRITE、ADMIN）；

会话session：客户端与服务端建立TCP长连接（心跳、处理请求响应、watcher事件）；客户端挂掉后在会话超时时间内重连可以保持会话；

服务器角色：Leader（只有1个、可读可写、负责事务管理）、Follower（负责选举、只读）、Observer（只读），类似Paxos协议的3个角色；

服务器状态：LOOKING（选举中）、FOLLOWING（跟随者）、LEADING（领导者）、OBSERVING（观察者）；

版本控制：每个znode节点会存储3个版本信息：当前ZNode的版本、当前ZNode子节点的版本、当前ZNode的ACL版本；

数据同步：当Learner服务器向Leader服务器完成注册后，进入数据同步，包括全量同步、差异化同步、回滚同步；

ZK特点：高性能（数据在内存，读场景性能高，写场景因为要同步节点越多越低）、临时节点（会话断开自动删除）、顺序一致性（所有更新全局有序、统一客户端请求有序，zxid事务ID保证，超半数机器成功才成功）、单一系统镜像（从任一服务器节点看到的数据一致）、原子性（事务在所有机器应用结果一致）；

ZK集群：Master/Slave模式、服务器节点数奇数（ZAB选举协议决定）、不支持动态添加新机器（需手动重启，3.5后支持）；

ZAB协议：ZooKeeper Atomic Broadcast 原子广播，两种基本的模式：崩溃恢复和消息广播；框架启动、Leader 异常时进入崩溃恢复，已选举新Leader并且半数机器和leader完成同步后进入消息广播模式；新加入服务器则该机器进人数据恢复，找到Leader，进行数据同步后进入消息广播；

ZK应用场景：配置管理、分布式协调通知、集群管理、分布式锁、分布式队列（基于znode存数据、watcher机制、临时有序节点机制）；

HDFS

整体架构：NameNode：master节点，管理名称空间namespace，管理数据块映射信息，处理客户端读写请求；创建镜像文件fsimage和编辑日志edits文件，处理客户端请求、记录操作日志、内存中执行数据增删改查；SecondaryNameNode：备份非热备，定期合并镜像和日志、分担NameNode工作，辅助恢复NameNode；执行checkpoint（下载NameNode的edits和fsimage进行合并并发给NameNode）；DataNode：Slave节点，执行NameNode的命令，存储数据块，执行读写；周期性（1小时）的向NameNode上报所有的块信息；和NameNode心跳（3秒），执行带回的命令；Client：客户端，切分Block，从NameNode获取文件位置信息，从DataNode读写文件，提供管理命令；

处理小文件：Hadoop Archive，SequenceFile、CombineFileInputFormat，支持对多个小文件的合并打包；

写数据流程：客户端请求NameNode上传第一个Block、NameNode返回所有DataNode信息、客户端与所有DataNode建立连接上传Block、DataNode间互相复制、继续上传其他Block；

读数据流程：客户端请求NameNode下载、NameNode返回文件所在的DataNode地址、客户端挑选（就近、随机）一台DataNode读取数据、DataNode传输数据给客户端；

文件存储：默认3副本，非均匀分布在机架中，1/3的副本在本地节点，1/3副本在同一个机架上，另外1/3个副本均匀地分布在其他机架上；文件处理单位：block（文件存储单位，默认128M）、packet（文件传输单位，默认64k）、chunk（文件校验单位，默认512B）；

HBase

NoSQL分类：键值数据库：通过Key管理数据，Value存储数据内容；代表：Redis；不适用场景：通过Value查询、关联查询、不支持回滚；文档数据库：数据存储的最小单位是文档；代表：MongoDB；适用场景：日志、分析；不适用场景：文档间的事务；列存储数据库：数据储存在列族中，一个列族存储经常被一起查询的相关数据；代表：HBase、Cassandra；适用场景：日志、博客；不适用场景：事务、数据模型设计（基于查询结果存储的）；图数据库：数据以图的方式储存，实体会被作为顶点，而实体之间的关系则会被作为边；适用范围较小；

特点：面向列、可扩展节点、数据存储在HDFS可备份、通过ZK协调查找数据，访问速度快；

集群角色：Hmaster（一个或多个主节点）、HregionServer（多个从节点）、ZK（外部依赖）；

数据模型：表（schema，包含多个行）、行键（类似Redis key，包含多个列族和一个时间戳列）、列族（包含多个列）、列（键值对集合，键即时间戳、值为Cell）、时间戳（控制同一份数据的不同版本）、Cell（值，字节存储，不限数据类型）；

Memcache

Key-Value数据库，基于内存存储，内存分配采用固定空间分配，不支持持久化；

服务器节点间协同通过客户端路由，不是真正的分布式缓存，各节点间无通信，分布式依赖于客户端API的路由算法；

可以保存的数据量是没有限制的，只要内存足够，Key最大为250个字节，Value最大1M；

两阶段哈希：首先在客户端通过Hash算法根据Key值算出一个服务器节点；再在服务端通过一个内部的Hash算法，查找Item并返回；

通过C实现，采用了单进程，单线程，异步I/O，基于事件通知 (libevent ) 的服务方式实现；

Ehcache

纯Java的进程内缓存框架，Hibernate、Mybatis中缓存提供者；对分布式支持不够好，多个节点不能同步，通常用于单应用内缓存；

缓存数据有两级：内存和磁盘，因此无需担心容量问题；缓存数据可以在机器重启后从磁盘加载；提供API手动刷新缓存到磁盘；

具备对象API接口和可序列化AP接口，不能序列化的对象可以使用除磁盘存储外ehcache的所有功能；

支持基于Cache和Element的过期策略，每个Cache的存活时间都可以设置和控制，提供了LRU、LFU和FIFO缓存淘汰算法；

缓存框架对比：Redis：通过Socket访问缓存、效率比Ehcache低，比Memcache快；数据类型支持丰富；可持久化数据；Item存储空间大；Ehcache：JVM中缓存，速度快，效率高，但是缓存共享麻烦，集群分布式应用不方便；Memcache：不能持久化，Item存储空间小，分布式依靠客户端；

ElasticSearch

概念：分布式搜索和处理平台，基于Lucene，可实现近实时查询（创建文档到可查询延迟在1秒）；索引：文档的集合，类似数据库；索引中的逻辑分类即类型，类似表；分片：一个索引被切成多块存在不同的服务器即分片，类似水平分表；包括主分片（默认5）和复制分片（默认1）；一个分片包括多个segment；文档：索引和搜索的原子单位，JSON表示，由多个域（包含一个名字和多个值）组成；节点：集群通过名字标识，节点通过节点名字加入；分为主节点（管理所有变更）、数据节点（存储数据和倒排索引）、协调节点（处理客户端请求）；倒排索引：对文档分词并维护一张分词、出现频率、出现的文档ID的表，搜索时也会建立；

使用：配置（集群和节点名称、数据和日志路径、改大操作系统默认文件描述符）、使用（提供内置RestAPI：_doc、_search等）；

写文档：协调节点处理请求计算新文档加入哪个主分片；主分片完成后再请求副分片；过程：内存+操作日志translog（用于故障恢复）、文件系统缓存生成segment（每隔1秒生成1个）、写磁盘（fsync操作，文件系统缓存所有segment落盘并清空translog）、合并segment（1秒1个太多而优化）；删文档：原索引不能直接修改，每个segment维护一个文件标识删除，查询请求中过滤掉删除的文档，segment合并时才真正删除；修改文档：原索引不能直接修改，先写入新文档，再标识旧文档为删除；查询文档：先查询需要查询哪些文档和segment（协调节点广播查询请求到所有相关分片，整合所有节点的响应并排序），再根据segment获取内容返回；

Logstash

概念：实时数据采集引擎，可以采集来自不同数据源的数据，并对数据进行处理后输出到多种输出源，执行模型Inputs（从数据源获取数据）>Filter（处理数据如格式转换）>Output（用于数据输出）;另外每个模块可指定Codecs进行编解码，每个模块通过插件进行选择配置；

执行模型：CS架构，每个服务器部署Agent，汇总到Server节点；每个Input启动一个线程获取数据并将数据加入队列；多个Worker线程从队列获取数据执行Filter和Output；

使用：配置文件（pipeline.conf和其他性能优化配置）、Input配置（选择插件，根据插件规范配置，如beats、file、redis）、Filter配置（可多个，如grok、mutate）、Output（如Elasticsearch、File）；横向扩展：横向扩展的多个Logstash相互独立，采用相同的pipeline配置，可以在多个Logstash前增加一个LoadBalance，以实现多个Logstash的负载均衡；

Filebeat：包含查找器（配置日志文件路径并查找，可多个）、采集器（读取日志文件新内容并发送到输出，一个文件一个）；

ELK

组件：包括Elasticsearch（搜集、分析、存储数据）、Logstash（日志的搜集、分析、过滤）、Kibana（Web汇总、分析、搜索）,新增了一个FileBeat（采集文件数据）；

架构：1. 计算节点（Logstash Agent） + 管理节点（Logstash Server、ES、Kibana）；2. 计算节点（Logstash Agent） + Kafka/Redis + 管理节点（Logstash Server、ES、Kibana）；3.计算节点（FileBeat） + 管理节点（Logstash Server、ES、Kibana）；

Docker

概念：对Linux容器的封装，将应用程序和所有依赖打包到一个文件，容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，没有进行硬件虚拟，比传统虚拟机（需要虚拟硬件）更轻便；包括镜像（特殊文件系统，包括文件、相关资源和配置参数，只读，不包括动态数据，构建后不可改）、容器（镜像的运行实例）、仓库（存储、注册、分发镜像，包括公有仓库Docker Hub和私有仓库，通过仓库名:标签定位一个版本的镜像）；

和虚拟机区别：启动快（秒级）、更轻量（资源少，共用内核，单系统能支持更多容器）、高可用（通过快速重新部署实现），但安全性（账户同宿主机）、隔离性（只是进程隔离）、可管理性（管理软件不成熟）弱于虚拟机；

核心组件：Docker Client（即客户端CLI工具,构建、运行和停止应用程序，和远程Docker_Host交互）、Docker Daemon（服务器组件，接受客户端请求，并根据请求类型创建job运行）、Docker Image（镜像，使用Dockerfile描述镜像的内容和创建步骤，docker build dockerfile构建镜像）、Docker Registry（仓库）、Docker Container（容器，镜像的运行实例）；

常用命令：docker images（列出本地已安装镜像）、docker rmi（删除镜像）、docker run（启动镜像）、docker ps（列出运行的容器）、docker start（启动容器）、docker rm（删除容器）、docker exec（宿主机发送指令给容器）、docker cp（拷贝容器内文件到宿主机）；

构建镜像：通常是基于一个已有基础镜像构建，两种方法：使用docker commit命令（相当于提交变更，基于当前容器提交变更为一个新镜像）、使用docker build命令和Dockerfile文件（更灵活强大，编写命令FROM基础镜像、ADD添加本地文件、RUN运行软件安装命令、CMD设置容器启动命令、EXPOSE设置对外暴露端口实现，每条指令顺序执行，构建的每一步及其对应指令都会独立运行，并且在输出最终镜像ID之前，Docker会提交每步的构建结果）；

基础镜像：基础镜像是一个包含rootfs的镜像，容器和OS没关系，但是需要OS镜像只是用于模拟Linux内核启动；

Docker实现原理：利用Linux的namespaces（通过命名空间进行资源隔离包括PID、IPC、NetWork）和cgroup（对进程进行系统资源分配和控制，限制资源使用）实现；

Kubernetes

作用：自动化容器操作平台，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩，可管理多种容器技术（Docker、Rocket）；

核心概念：

Master节点：k8s集群的管理节点，数据访问入口，包括Api Server（提供Rest接口）、Controller Manager（资源控制）、Scheduler（资源调度）；

Node节点：运行Pod的节点，包括kubelet(Pod容器管理，向Master注册和定期汇报)、kube-proxy（与Service通信、负载均衡、路由转发）、Docker（容器引擎可以是其他如Rocket）；

Pod：k8s管理的最小单元，包含多个容器，共享网络和IP端口；

Replication Controller：管理Pod副本，实现弹性伸缩、动态扩容和滚动升级的核心；

Service：包含多个Pod的逻辑集合（通过Label关联）和访问该集合的策略，是真实服务的抽象；

Label：Pod的key-value键值对标签，用于筛选资源对象（Replication Controller筛选完成副本控制、kube-proxy筛选完成service和pod的路由映射、scheduler筛选完成调度）；

IP地址：Node IP（Node节点的IP地址）、Pod IP（Pod的IP地址）、Cluster IP（Service的IP地址，不能通信无法ping），集群内3个IP的通信由k8s自己设计的路由实现；

kubectl：客户端CLI工具，常用命令：kubectl exec（执行命令）、kubectl delete（删除资源） 、kubectl describe pod/node（显示资源详情）、kubectl get pods（查看pod）；

Maven

打包类型：packaging包括pom（父项目）、maven-plugin（自定义插件工程）、jar（默认）、war；

依赖范围：compile（所有阶段使用）、provided（开发测试使用）、runtime（运行使用）、test（测试使用）、system（显式指定jar路径，不会从仓库找）、import（dependencyManagement继承）:

依赖关系：排除依赖exclusions、继承依赖parent、聚合依赖modules父子模块；

生命周期：3个独立生命周期clean清理项目（pre-clean、clean、post-clean）、default构建项目（validate、compile、test、package、integration-test、verify、install、Deploy）、site发布项目（pre-site、site、post-site、site-deploy）；命令会从生命周期初始阶段开始执行如mvn test从validate开始执行到test；每个阶段使用插件执行（clean、compiler、jar）；

仓库：本地仓库和远程仓库（分为中央仓库和私服，用于缓存中央仓库）；snapshot快照仓库和release发布仓库；