Kafka简要说明

关键特⾊:

[]可伸缩架构[/][]高吞吐量[/][]consumer⾃动负载均衡 [/][]支持集群多副本[/]

Topic中partition存储分布 

topic名称为:report_push  在kafka文件系统中,同一个topic下有多个不同partition,每个partition创建一个目录。

Partiton文件存储⽅方式 

[]每个partion(目录)相当于一个巨型⽂件被平均分配到多个⼤小相等的多个segment(段)文件中。但每个段segment file消息数量不⼀定相等,这种特性⽅便old segment file快速被删除。[/][]每个partiton只需要⽀持顺序读写就⾏了,segment文件生命周期由服务端配置参数决定。 [/]

 小结:           主要目的就是提⾼磁盘利用率和消息处理性能。

Partiton中segment⽂文件存储结构 

下⾯面介绍一下partion⽂文件存储中segment file组成结构。一个商业化消息队列的性能好坏,其文件系统存储结构设计是衡量⼀个消息队列服务程序最关 键指标之一,他也是消息队列中最核心且最能体现消息队列技术⽔平的部分。在本节中我们将⾛进segment file内部⼀探究竟。segment file组成:由2⼤大部分组成,分别为segment data file和segment index file,此2个⽂件⼀一对应,成对出现.segment中 index — data file对应关系 

index为稀疏索引结构,并不存储每条记录的元数据信息,⽽是与单条或多条消息大⼩比较,如果总消息⼤小大于该阀值才写一次index,默认阀值4096字节。

partiton中segment⽂件存储结构-index 00000000000000000000.index索引⽂件存储结构: 每次记录相应log文件记录的相对条数和物理偏移位置,共8bytes 4 byte 当前segment file offset - last seg file offset记录条数offset4 byte 对应segment file物理偏移地址 position......... part中segment文件存储结构-data file 

一个消息(message chunk)数据块可能包含多条消息,但同⼀个数据块中的消息只有⼀个offset(partiions第多少msg chunk),所以当一个消息块有多条数据处理完部分数据发生异常时,消费者重新去取数据,就会再次取得这个数据块,然后消费过的数据就会被重新消费。

数据库稀疏索引例⼦

稀疏索引只为数据⽂件的每个存储块设⼀个键-指针对,它⽐稠密索引节省了更多的存储空间,但查找给定值的记录需更多的时间。只有当数据文件是按照某个查 找键排序时,在该查找键上建⽴的稀疏索引才能被使用,而稠密索引则可以应⽤在任何的查找键。如图2所⽰示,稀疏索引只为每个存储块设一个键-指针对。键值 是每个数据块中第一个记录的对应值。

如何在partition中快速定位segment file 

同一个topic下有不同分区,每个分区下⾯会划分为多个(段)文件,只有一个当前文件在写,其他⽂文件只读。当写满一个文件(写满的意思是达到设定值)则切换⽂文件,新建一个当前文件用来写,老的当前⽂件切换为只读。文件的命名以起始偏移量来命名。 看一个例⼦子,假设report_push这个topic下的0-0分区可能有以下这些⽂文件:

其中00000000000000000000.index表⽰示最开始的文件,起始偏移量为0.第⼆个⽂文件 00000000000000368769.index的消息量起始偏移量为368769.同样,第三个⽂件00000000000000737337.index的起始偏移量为737337.以起始偏移量命名并排序这些 文件,那么当消费者要拉取某个消息起始偏移量位置的数据变的相当简单,只要根据 传上来的offset[b]⼆分查找[/b]文件列表,定位到具体文件,然后将绝对offset减去文件的起始节点转化为相对offset,即可开始传输数据。

例如,同样以上面的例⼦为例,假设消费者想抓取从第368969消息位置开始的数据,则根据368969⼆分查找,定位到00000000000000368769.log这个文件(368969在368769和737337之间),根据索引文件二分搜索可以确定读取数据最⼤大小，栗子：

如何在segment file查找msg chunk 

实际效果：

kafka的⽂文件系统结构—>总结

⾼效文件系统特点 ：

[]一个大文件分成多个⼩文件段。[/][]多个⼩⽂件段,容易定时清除或删除已经消费完文件,减少磁盘占用。[/][]index全部映射到memory直接操作,避免segment file被交换到磁盘增加IO操作次数。[/][]根据索引元数据信息,可以确定consumer每次批量拉取最大msg chunk数量。[/][]索引⽂文件元数据存储用的是相对前一个segment file的offset存储,节省空间⼤小。[/]

当下Hadoop已经成长为一个庞大的体系，貌似只要和海量数据相关的，没有哪个领域缺少Hadoop的身影，下面是一个Hadoop生态系统的图谱，详细的列举了在Hadoop这个生态系统中出现的各种数据工具。
这一切，都起源自Web数据爆炸时代的来临

[]数据抓取系统－Nutch[/][]海量数据怎么存，当然是用分布式文件系统-HDFS[/][]数据怎么用呢，分析，处理MapReduce框架，让你编写代码来实现对大数据的分析工作[/][]非结构化数据（日志）收集处理-fuse,WebDav,Chukwa,flume,scribe[/][]数据导入到HDFS中，至此RDBSM也可以加入HDFS的狂欢了-Hiho,sqoop[/][]MapReduce太麻烦，好吧，让你用熟悉的方式来操作Hadoop里的数据-Pig,Hive,Jaql[/][]让你的数据可见－drilldown，intellicus[/][]用高级语言管理你的任务流－oozie，cascading[/][]Hadoop当然也有自己的监控管理工具－Ambari,Hue,karmasphere,eclipse plugin,Cacti,ganglia[/][]数据序列化处理与任务调度-avro，zookeeper[/][]更多构建在Hadoop上层的服务 - Mahout，Elastic map Reduce[/][]OLTP存储系统-Hbase[/]

http://www.neevtech.com/blog/2013/03/18/hadoop-ecosystem-at-a-glance/ 

http://zh.hortonworks.com/blog/modern-retail-architectures-built-hadoop/

Hadoop在蓝汛

系统架构：

Cloudera和它的产品们

Apache Hadoop与CDH版本关系

CDH为什么更好？

[]安装升级更简单：[/]

                 yum ,tar, rpm, cloudera manager 四种安装方法 

[]更快获取新功能和修正新bug[/][]年度release，季度update[/][]Yum安装自动匹配合适的生态系统版本[/][]自动目录配置（logs，conf），以及hdfs和mapred用户创建[/][]详细的文档[/]

CDH3u3重大改善

CDH3u4重大改善

Cloudera Manager Cloudera Training

[]关于Training[/]

                分为Administrator和Development两门课程

[]关于认证考试[/][]关于证书[/]

运维事故

1、伤不起的内存现象1

系统上线第二天，Jobtracker不工作，web页面打不开

原因

一次提交Job数量太多，导致Jobtracker 内存溢出

解决

调大JT内存；限制Running Job数量

现象2

NN内存溢出，重启后发现50030页面显示fsimage损坏，调查发现SNN fsimage同样损坏了

原因

小文件太多导致NN/SNN内存溢出，导致fsimage文件损坏，但是重启后的NN可以正常服务。

原因

Cloudera google group去救，获得后门脚本

2、低效的MapReduce Job现象

MapReduce Job执行时间过长

原因

MR中用到了Spring，小文件导致Map方法效率低下，GZ文件读写效率低

解决

MR去Spring化；开启JVM重用；使用LZO作为输入和map输出结果；加大reduce并行copy线程数

压缩与MapReduce性能

[]前提：大量小文件[/][]输入147GB，文件数45047，平均3MB[/][]CPU 8 core；32GB内存；7200转磁盘；28台Slave机器[/]

 3、OMG，整个集群完蛋了现象

早上来发现所有DataNode都dead了，重启后10分钟，DN陆续又都dead了；调查发现节点有8%左右丢包率

原因

交换机模块故障；DN不能Hold住大量小文件

解决

升级3u2到3u4；设置DN内存到2GB

遇到无法跨越的问题解决办法

[]加入Hadoop官方Mail List[/][]加入Cloudera Google Group[/]

监控与告警

[]监控：ganglia[/][]设备告警、服务告警：nagios[/][]业务告警：自己实现[/]

Nagios告警：

业务监控：

为什么我们使用软件负载均衡​

[]海量并发下分散请求，减轻服务压力，分布式部署，容灾，解决单点问题，端口复用节约服务器资源[/][]硬件负载均衡成本较高，设备维护较为复杂，稳定性高[/][]nginx haproxy lvs(piranha)[/][]php+fastcgi,modjk+tomcat [/]

软件负责均衡原理

负载均衡分为七层和四层负载均衡,是由通信协议决定均衡模式，如SSL 443是TCP模式，http请求是应用层模式，然后按照一定的调度算法把请求调度到相应的节点

[]在统一接入层进行请求调度均衡[/][]按照服务器性能调度请求，权值调整[/][]业务层逻辑解耦，按照URL分发[/][]IP层，按照网段分发[/][]容灾 [/][]自适应性调度（nginx+fasctcgi,modjk+apache）[/]

注意事项：

[]服务是否长连接 [/][]是否会话黏贴 [/][]32位系统和64位系统网络中断问题[/][]安全相关  [/][]维护成本 [/][]节点生存检测 [/][]算法选择[/][]避免跨IDC 跨网段 跨楼层[/]

负责均衡软件特点

LVS特点：

[]抗负载能力强，使用IP负载均衡技术，只做分发，所以LVS本身并没有多少流量产生；[/][]稳定性、可靠性好，自身有完美的热备方案；（如：LVS+Keepalived）[/][]应用范围比较广，可以对所有应用做负载均衡；[/][]不支持正则处理，不能做动静分离。 [/]

常用四种算法：

[]rr：轮叫，轮流分配到后端服务器；[/][]wrr：权重轮叫，根据后端服务器负载情况来分配；[/][]lc：最小连接，分配已建立连接最少的服务器上；[/][]wlc：权重最小连接，根据后端服务器处理能力来分配。[/]

可以采用ipvsadm –p（persistence）来保持session，默认是300/s 。
 
Nginx特点：

[]工作在7层，可以对做正则规则处理；（如：针对域名、目录进行分流）[/][]配置简单，能ping通就能进行负载功能，可以通过端口检测后端服务器状态，不支持url检测；[/][]抗高并发，采用epoll网络模型处理客户请求；[/][]支持HTTP、TCP和EMail，应用范围比较少；[/][]nginx主要是HTTP和反向代理服务器，低系统资源消耗。[/]

常用四种算法：

[]RR:（默认）轮询，轮流分配到后端服务器；[/][]weight:根据后端服务器性能分配；[/][]ip_hash:每个请求按访问ip的hash结果进行分配，并发小时合适，解决session问题；[/][]fair:（扩展策略），默认不被编译nginx内核，根据后端服务器响应时间判断负载情况，选择最轻的进行处理。 [/]

 
Haproxy特点：

[]支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；[/][]配置简单，支持url检测后端服务器状态；[/][]仅做负载均衡软件使用，在高并发情况下，处理速度高于nginx；[/][]TCP层多用于Mysql从（读）服务器负载均衡。 [/]

常用四种算法：

[]roundrobin：轮询，轮流分配到后端服务器；[/][]static-rr：根据后端服务器性能分配；[/][]leastconn：最小连接者优先处理；[/][]source：根据请求源IP，与Nginx的IP_Hash类似。[/]

为什么要解决session会话

负载均衡环境下，每个用户都有可能不固定的访问后端服务器，在有些应用情况下，是必须要求在一定时间内同一用户访问的所有请求都分配给后端同一台服务器去处理，例如：电子商务网站，用户注册页面等，一刷新页面，就会分配到后端的另一台服务器上，那刚才的页面上的信息也都没了，这种情况下，分配同一台服务器处理请求是至关重要的！

Web应用服务器对比

主流应用服务器：

[]Apache后台服务器（主要处理php及一些功能请求 如：中文url）[/][]Nginx前端服务器（利用它占用系统资源少得优势来处理静态页面 大量请求）[/][]Lighttpd 图片服务器[/]

总体来说，随着nginx功能得完善将使他成为今后web server的主流。
三种服务器对比：

测试维度

测试维度主要思路是开发-->交付-->运维这个思路来做的，从开发版本迭代到最少产品交付给运维部署上线。开发版本出来之后，开发内部build完成之后，协同测试后把程序交付给应用管理系统和数据服务，最后交付完成集成之后交由运维部署。

测试指标

测试指标主要是珍对容器服务的功能生态系统周期测试。是否支持团队协作、微服务器架构、容器化、持续交付、云平台等方面来考虑容器平台的可用迭代完整性。

参测产品

厂商功能对比

1、DevOps

2、微服务

3、容器化

4、持续交付

5、混合云

总结

不管是哪家厂商都不重要，重要的是可以满足客户现有环境和需求。当然如果厂商支持的功能越多和越全面，适配的概率和可用性会更高，最后考虑的才是产品质量，只有更好的适配度和满足度，才会进一步商务洽谈下去。

模块、包、字符串操作15分钟视频： 

西山居大牛卫峥带你进入Python世界，视频分享旨在把多年编程经验分享给大家，各种编程语言的语法知识，使用方法，应用场景，框架使用，尽量使用最少的时间 精简的话语 讲给你听。