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

1.概述

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

2.内容

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

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

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

kafka 提供三种语义的传递：

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

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

　　在 consumer 端，大家都知道可以控制 offset，所以可以控制消费，其实 offset 只有在重启的时候才会用到。在机器正常运行时我们用的是 position，我们实时消费的位置也是 position 而不是 offset。我们可以得到每一条消息的 position。如果我们在处理消息之前就将当前消息的 position 保存到 zk 上即 offset，这就是只多一次消费，因为我们可能保存成功后，消息还没有消费机器就挂了，当机器再打开时此消息就丢失了；或者我们可以先消费消息然后保存 position 到 zk 上即 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

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

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

现在明显是lag为12,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

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

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

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

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