分类 默认分类 下的文章

原文:https://blog.csdn.net/Rose1645/article/details/80696144

1.概述

Kafka版本[0.10.1.1],已默认将消费的 offset 迁入到了 Kafka 一个名为 __consumer_offsetsopic中。其实,早在 0.8.2.2 版本,已支持存入消费的 offsetopic中,只是那时候默认是将消费的 offset 存放在 Zookeeper 集群中。那现在,官方默认将消费的offset存储在 Kafkaopic中,同时,也保留了存储在 Zookeeper 的接口,通过 offsets.storage 属性来进行设置。

2.内容

其实,官方这样推荐,也是有其道理的。之前版本,Kafka其实存在一个比较大的隐患,就是利用 Zookeeper 来存储记录每个消费者/组的消费进度。虽然,在使用过程当中,JVM帮助我们完成了一些优化,但是消费者需要频繁的去与 Zookeeper 进行交互,而利用ZKClientAPI操作Zookeeper频繁的Write其本身就是一个比较低效的Action,对于后期水平扩展也是一个比较头疼的问题。如果期间 Zookeeper 集群发生变化,那 Kafka 集群的吞吐量也跟着受影响。

在此之后,官方其实很早就提出了迁移到 Kafka 的概念,只是,之前是一直默认存储在 Zookeeper集群中,需要手动的设置,如果,对 Kafka 的使用不是很熟悉的话,一般我们就接受了默认的存储(即:存在 ZK 中)。在新版 Kafka 以及之后的版本,Kafka 消费的offset都会默认存放在 Kafka 集群中的一个叫 __consumer_offsetsopic中。

当然,其实她实现的原理也让我们很熟悉,利用 Kafka 自身的 Topic,以消费的GroupTopic,以及Partition做为组合 Key。所有的消费offset都提交写入到上述的Topic中。因为这部分消息是非常重要,以至于是不能容忍丢数据的,所以消息的 acking 级别设置为了 -1,生产者等到所有的 ISR 都收到消息后才会得到 ack(数据安全性极好,当然,其速度会有所影响)。所以 Kafka 又在内存中维护了一个关于 GroupTopicPartition 的三元组来维护最新的 offset 信息,消费者获取最新的offset的时候会直接从内存中获取。这也说明offset的提交是以消费者为单位的。通过消费组、主题、与分区就能确定是哪个消费组中的消费者提交的offset的了。

kafka 提供三种语义的传递:

  • 至少一次
  • 至多一次
  • 精确一次

  首先在 producer 端保证12的语义是非常简单的,至少一次只需要同步确认即可(确认方式分为只需要 leader 确认以及所有副本都确认,第二种更加具有容错性),至多一次最简单只需要异步不断的发送即可,效率也比较高。目前在 producer 端还不能保证精确一次,在未来有可能实现,实现方式如下:在同步确认的基础上为每一条消息加一个主键,如果发现主键曾经接受过,则丢弃

  在 consumer 端,大家都知道可以控制 offset,所以可以控制消费,其实 offset 只有在重启的时候才会用到。在机器正常运行时我们用的是 position,我们实时消费的位置也是 position 而不是 offset。我们可以得到每一条消息的 position。如果我们在处理消息之前就将当前消息的 position 保存到 zk 上即 offset,这就是只多一次消费,因为我们可能保存成功后,消息还没有消费机器就挂了,当机器再打开时此消息就丢失了;或者我们可以先消费消息然后保存 positionzk 上即 offset,此时我们就是至少一次,因为我们可能在消费完消息后offset 没有保存成功。而精确一次的做法就是让 position的保存和消息的消费成为原子性操作,比如将消息和 position 同时保存到 hdfs 上 ,此时保存的 position 就称为 offset,当机器重启后,从 hdfs重新读入offset,这就是精确一次。

consumer可以先读取消息,然后将offset写入日志文件中,然后再处理消息。这存在一种可能就是在存储offset后还没处理消息就crash了,新的consumer继续从这个offset处理,那么就会有些消息永远不会被处理,这就是上面说的“最多一次”。
consumer可以先读取消息,处理消息,最后记录offset,当然如果在记录offset之前就crash了,新的consumer会重复的消费一些消息,这就是上面说的“最少一次”。

精确一次”可以通过将提交分为两个阶段来解决:保存了offset后提交一次,消息处理成功之后再提交一次。但是还有个更简单的做法:将消息的offset和消息被处理后的结果保存在一起。比如用Hadoop ETL处理消息时,将处理后的结果和offset同时保存在HDFS中,这样就能保证消息和offser同时被处理了。
    项目中由于消息可被重复消费、因此采用最少一次这种方式。从kafka集群中获取消息之后,存入数据库后再手动提交offset。这样能保证不会遗漏需要消费的消息。如果要保证精确一次的话可能比较麻烦,就得把offset存入数据库,保证业务逻辑的处理与offset的原子性(同一个事务中)。

最近将 golang 的项目打包放到 docker 环境 运行的时候发现 有很多 ssl x509 的 错误,大概估计了下应该是 https 证书的问题,然后

 docker run -v "/etc/ssl/certs/:/etc/ssl/certs/" 

将宿主机的证书目录映射过去,问题解决。

ps,google 出来的 绝大部分人的解决方法都是设置 TLSClientConfig 来跳过 https 证书验证。这显然是直接能够解决问题的,但是这实际上是避开了解决问题的方法。

元旦回来看下下面的文章,对这个问题也有所解释,有兴趣可以看下:

https://juejin.im/entry/5c29e65951882565986a2484?utm_source=gold_browser_extension

原文:https://mp.weixin.qq.com/s/cgylXJAiwi1BNkdadfcbZg

简介

网络数据包截获分析工具。支持针对网络层、协议、主机、网络或端口的过滤。并提供and、or、not等逻辑语句帮助去除无用的信息。

tcpdump - dump traffic on a network

例子

不指定任何参数

监听第一块网卡上经过的数据包。主机上可能有不止一块网卡,所以经常需要指定网卡。

tcpdump

监听特定网卡

tcpdump -i en0

监听特定主机

例子:监听本机跟主机182.254.38.55之间往来的通信包。
    tcpdump host 182.254.38.55 //出、入的包都会被监听。

特定来源、目标地址的通信

特定来源

tcpdump src host hostname

特定目标地址

tcpdump dst host hostname

如果不指定src跟dst,那么来源 或者目标 是hostname的通信都会被监听

tcpdump host hostname

特定端口

tcpdump port 3000

监听TCP/UDP

服务器上不同服务分别用了TCP、UDP作为传输层,假如只想监听TCP的数据包

tcpdump tcp

来源主机+端口+TCP

监听来自主机123.207.116.169在端口22上的TCP数据包
tcpdump tcp port 22 and src host 123.207.116.169

监听特定主机之间的通信

tcpdump ip host 210.27.48.1 and 210.27.48.2
210.27.48.1除了和210.27.48.2之外的主机之间的通信
tcpdump ip host 210.27.48.1 and ! 210.27.48.2

稍微详细点的例子

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

(1)tcp: ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第一个参数的位置,用来过滤数据报的类型

(2)-i eth1 : 只抓经过接口eth1的包

(3)-t : 不显示时间戳

(4)-s 0 : 抓取数据包时默认抓取长度为68字节。加上-S 0 后可以抓到完整的数据包

(5)-c 100 : 只抓取100个数据包

(6)dst port ! 22 : 不抓取目标端口是22的数据包

(7)src net 192.168.1.0/24 : 数据包的源网络地址为192.168.1.0/24

(8)-w ./target.cap : 保存成cap文件,方便用ethereal(即wireshark)分析

限制抓包的数量

如下,抓到1000个包后,自动退出

tcpdump -c 1000

保存到本地

备注:tcpdump默认会将输出写到缓冲区,只有缓冲区内容达到一定的大小,或者tcpdump退出时,才会将输出写到本地磁盘
tcpdump -n -vvv -c 1000 -w /tmp/tcpdump_save.cap

也可以加上-U强制立即写到本地磁盘(一般不建议,性能相对较差)

实战例子

先看下面一个比较常见的部署方式,在服务器上部署了nodejs server,监听3000端口。nginx反向代理监听80端口,并将请求转发给nodejs server(127.0.0.1:3000)。

浏览器 -> nginx反向代理 -> nodejs server

问题:假设用户(183.14.132.117)访问浏览器,发现请求没有返回,该怎么排查呢?

步骤一:查看请求是否到达nodejs server -> 可通过日志查看。

步骤二:查看nginx是否将请求转发给nodejs server

tcpdump port 8383 

这时你会发现没有任何输出,即使nodejs server已经收到了请求。因为nginx转发到的地址是127.0.0.1,用的不是默认的interface,此时需要显示指定interface

tcpdump port 8383 -i lo

备注:配置nginx,让nginx带上请求侧的host,不然nodejs server无法获取 src host,也就是说,下面的监听是无效的,因为此时对于nodejs server来说,src host 都是 127.0.0.1

tcpdump port 8383 -i lo and src host 183.14.132.117

步骤三:查看请求是否达到服务器

tcpdump -n tcp port 8383 -i lo and src host 183.14.132.117

原文:http://www.alloyteam.com/2013/12/js-calculate-the-number-of-bytes-occupied-by-a-string/

最近项目有个需求要用js计算一串字符串写入到localStorage里所占的内存,众所周知的,js是使用Unicode编码的。而Unicode的实现有N种,其中用的最多的就是UTF-8和UTF-16。因此本文只对这两种编码进行讨论。

下面这个定义摘自维基百科(http://zh.wikipedia.org/zh-cn/UTF-8),做了部分删减。

UTF-8(8-bit Unicode Transformation Format)是一种针对Unicode的可变长度字符编码,可以表示Unicode标准中的任何字符,且其编码中的第一个字节仍与ASCII相容,使用一至四个字节为每个字符编码

其编码规则如下:

  1. 字符代码在000000 – 00007F之间的,用一个字节编码;
  2. 000080 – 0007FF之间的字符用两个字节;
  3. 000800 – 00D7FF 和 00E000 – 00FFFF之间的用三个字节,注: Unicode在范围 D800-DFFF 中不存在任何字符;
  4. 010000 – 10FFFF之间的用4个字节。

而UTF-16 则是定长的字符编码,大部分字符使用两个字节编码,字符代码超出 65535 的使用四个字节,如下:

  1. 000000 – 00FFFF 两个字节;
  2. 010000 – 10FFFF 四个字节。

一开始认为既然页面用的是UTF-8编码,那么存入localStorage的字符串,应该也是用UTF-8编码的。但后来测试发现,明明计算出的size是不到5MB,存入localStorage却抛异常了。想了想,页面的编码是可以改的。如果localStorage按照页面的编码存字符串,不就乱套了?浏览器应该都是使用UTF-16编码的。用UTF-16编码计算出5MB的字符串,果然顺利写进去了。超过则失败了。
好了,附上代码实现。计算规则就是上面写的,为了计算速度,把两个for循环分开写了。

/**
 * 计算字符串所占的内存字节数,默认使用UTF-8的编码方式计算,也可制定为UTF-16
 * UTF-8 是一种可变长度的 Unicode 编码格式,使用一至四个字节为每个字符编码
 * 
 * 000000 - 00007F(128个代码)      0zzzzzzz(00-7F)                             一个字节
 * 000080 - 0007FF(1920个代码)     110yyyyy(C0-DF) 10zzzzzz(80-BF)             两个字节
 * 000800 - 00D7FF 
   00E000 - 00FFFF(61440个代码)    1110xxxx(E0-EF) 10yyyyyy 10zzzzzz           三个字节
 * 010000 - 10FFFF(1048576个代码)  11110www(F0-F7) 10xxxxxx 10yyyyyy 10zzzzzz  四个字节
 * 
 * 注: Unicode在范围 D800-DFFF 中不存在任何字符
 * {@link http://zh.wikipedia.org/wiki/UTF-8}
 * 
 * UTF-16 大部分使用两个字节编码,编码超出 65535 的使用四个字节
 * 000000 - 00FFFF  两个字节
 * 010000 - 10FFFF  四个字节
 * 
 * {@link http://zh.wikipedia.org/wiki/UTF-16}
 * @param  {String} str 
 * @param  {String} charset utf-8, utf-16
 * @return {Number}
 */
var sizeof = function(str, charset){
    var total = 0,
        charCode,
        i,
        len;
    charset = charset ? charset.toLowerCase() : '';
    if(charset === 'utf-16' || charset === 'utf16'){
        for(i = 0, len = str.length; i < len; i++){
            charCode = str.charCodeAt(i);
            if(charCode <= 0xffff){
                total += 2;
            }else{
                total += 4;
            }
        }
    }else{
        for(i = 0, len = str.length; i < len; i++){
            charCode = str.charCodeAt(i);
            if(charCode <= 0x007f) {
                total += 1;
            }else if(charCode <= 0x07ff){
                total += 2;
            }else if(charCode <= 0xffff){
                total += 3;
            }else{
                total += 4;
            }
        }
    }
    return total;
}

前提条件:

相关所有消费服务必须停止。

执行如下命令即可:

首先查看指定消费组信息下面使用的topic offset 情况:

bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group you_consumer_group_name --describe

20180910114108959.png

注意看current-offsetlog-end-offset还有 lag ,分别为当前偏移量,结束的偏移量,落后的偏移量。

现在的情况是有90条信息已经消费完毕了。只要看lag为0。如果还有未消费的会显示如下信息:

20180910114655982.png

现在明显是lag12,current-offset =91,log-end-offset=103 ,告诉我们有12条未消费,

current-offset 当前已经消费到偏移量为91,可以理解为已经消费91条。

log-end-offset可以理解为总共103条记录。

lag可以理解为未消费记录条数。

如果想控制当前offset,需要注意的是这里面的消息可能消费过后,超过配置文件(server.properties)里面的属性-> log.retention.hours = 168 ,这个属性代表消息保留时间为多少小时。默认为168小时,也就是一周时间。所以你只能控制到近期保留的消息偏移量 (我这里举例设置从80偏移量开始)-> 可以执行如下命令:

bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group you_consumer_group_name --topic you_topic_name --execute --reset-offsets --to-offset 80

20180910123508387.png

执行如上命令类似如下结果说明设置成功了。我们继续使用第一条命令查看验证一下:

bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group you_consumer_group_name --describe

20180910123648634.png

OK,很明显手动调节偏移量成功了。

作者:ZouChengli
来源:CSDN
原文:https://blog.csdn.net/ZouChengli/article/details/82587404
版权声明:本文为博主原创文章,转载请附上博文链接!