
背景：

- gin框架，中间件
- 博客开放好玩的 API

需求：

- 接口限流
- 按账户/IP/Token限流
- 定时加载配置

todo:

- 分布式限流

# time/rate 原理

time/rate 是go提供的官方限流工具

原理: 令牌桶，以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务

我首先想到的方案初始化定时任务，每隔多长时间往桶里放一令牌。但是相比之下，time/rate的实现方式就是更优雅了

关键变量:

- 令牌放入桶的速度 limit 每秒产生多少token
- 桶的容量 burst 

已知变量：

- 最后一次消耗令牌的时间 last

简化公式：

当前可用令牌数，tokens（当前可用令牌数） := (now (当前时间) - last(上一次消耗令牌的时间) ).Seconds() * limit(令牌/每秒)

完整代码是：

```go
// advance calculates and returns an updated state for lim resulting from the passage of time.
// lim is not changed.
func (lim *Limiter) advance(now time.Time) (newNow time.Time, newLast time.Time, newTokens float64) {
	last := lim.last
	if now.Before(last) {
		last = now
	}

	// Avoid making delta overflow below when last is very old.
  // 这里限制令牌数不超过burst，lim.tokens 是上一次结余
	maxElapsed := lim.limit.durationFromTokens(float64(lim.burst) - lim.tokens)
	elapsed := now.Sub(last)
	if elapsed > maxElapsed {
		elapsed = maxElapsed
	}

	// Calculate the new number of tokens, due to time that passed.
	delta := lim.limit.tokensFromDuration(elapsed)
	tokens := lim.tokens + delta // 上一次结余 + 时间增量
	if burst := float64(lim.burst); tokens > burst {
		tokens = burst
	}

	return now, last, tokens
}
```

比起定时器来说是不是很优雅？这里有个比较绕的点：limit 的单位，n/s, 每秒多少个令牌

```go
// Every converts a minimum time interval between events to a Limit.
func Every(interval time.Duration) Limit {
	if interval <= 0 {
		return Inf
	}
	return 1 / Limit(interval.Seconds())
}
```

计算可用tokens的公式就更好理解了，用  tokens（当前可用令牌数） := (now (当前时间) - last(上一次消耗令牌的时间) ).Seconds() * limit(令牌/每秒)

# time/rate 改造

time/rate 只是给出了最基础的实现，绝大部分的需求

- 接口 > IP/user 多层限流
- 动态加载配置
- 在响应中给出剩余请求次数，下一次重置时间

其实 time/rate 的成本是非常低的，所以我们只需要多层map结构就可以满足, 每次初始化一个 rate.Limiter 就可以满足

```go
type ApiKeyRateLimit interface {
	Load()
	GetLimiter(api, key string) (limiter *Limiter, ok bool)
}

// API - UserId - rate.Limiter
type ApiKeyRateLimitImpl struct {
	hub map[string]map[string]*rate.Limiter
}
```

动态加载配置，可以使用etcd订阅配置，我实现的是定时从数据库里捞配置

```go

type ApiAccountRateLimit struct {
	ctx context.Context
	lim rate.ApiKeyRateLimit
}

func NewApiAccountRateLimit(ctx context.Context, limit rate.ApiKeyRateLimit) *ApiAccountRateLimit {
	r := &ApiAccountRateLimit{
		ctx: ctx,
		lim: limit,
	}
	go r.load()
	return r
}

func (h *ApiAccountRateLimit) Hook() gin.HandlerFunc {
	return func(ctx *gin.Context) {
		path := ctx.Request.URL.Path
		acctId, ok := ctx.Get(consts.OpenapiAccountId)
		if !ok {
			ctx.JSON(http.StatusOK, gin.H{"code": http.StatusUnauthorized, "message": http.StatusText(http.StatusUnauthorized)})
			ctx.Abort()
			return
		}
		limiter, ok := h.lim.GetLimiter(path, acctId.(string))
		if !ok {
			ctx.JSON(http.StatusOK, gin.H{"code": http.StatusUnauthorized, "message": http.StatusText(http.StatusUnauthorized)})
			ctx.Abort()
		}
    // 响应头：X-RateLimit-* 这里time/rat没有放出Advance，需要改一下
		_, _, tokens := limiter.Advance(time.Now())
		burst := limiter.Burst()
		ctx.Header("X-RateLimit-Limit", strconv.Itoa(burst))
		ctx.Header("X-RateLimit-Remaining", strconv.Itoa(int(tokens)))
    
		if !limiter.Allow() {
			ctx.JSON(http.StatusOK, gin.H{"code": http.StatusTooManyRequests, "message": http.StatusText(http.StatusTooManyRequests)})
			ctx.Abort()
			return
		}
		ctx.Next()
	}
}

// 定时加载配置
func (h *ApiAccountRateLimit) load() {
	ticker := time.NewTicker(5 * time.Minute)
	for {
		select {
		case <-h.ctx.Done():
			logger.Errorf("quit: RateLimit load config")
		case <-ticker.C:
			h.lim.Load()
		}
	}
}
```

# 推荐阅读

- go time/rate 限流 https://www.douyacun.com/article/f8f4e2bb806a6176e9c61dcaa0a4a6cc
- Go可用性(三) 限流2: 令牌桶的实现 rate/limt https://lailin.xyz/post/go-training-week6-3-token-bucket-2.html



1. 接口限流 2. 按账户/ip/token限流 3. 定时加载配置

go time/rate 接口-账户/IP 限流


- kafka 多线程处理单个消费者消息
- kafka 单线程处理单个消费者消息
- kafka 增加分区数量

# kafka 多线程处理单个消费者消息

写php的时候经常拿redis来当做消息队列，然后启动多个进程处理队列中的消息，失败的消息记录写入失败队列中。所以在处理kafka consumer group时首先会想到这种方式来处理消息。只是如果kafka也按照这种方式来的话，保证消息不丢失的语义将会是一件麻烦事。

位移: kafka partition 只会维护一个数字，即处理的最后一条消息。

如果我们启用多线程来处理同一个消费者的消息的话，考虑一下这种情况:

4个线程处理，分别拿到了 位移 5,6,7,8 的消息

- 拿到8的线程成功处理了消息。但是5，6，7的线程处理失败了，此时我们还需要一个队列来处理失败的消息。就像上面处理redis队列一样
- 还是拿到8的线程成功处理了消息，提交了位移，5的线程最后处理完消息，最后提交commit，此时6，7，8的消息会被重复消费

所以我们多线程处理单个消费者消息是需要解决这处理失败，消息重复消费这2个问题，不符合kafka消息交付语义。实现链路长，代码复杂

**那么为什么还是需要多线程消费？**

答：考虑需要使用消息队列场景，比如：视频、图片处理

- 处理周期长，超过web请求设定的超时时间
- 异步处理，业务需求更关注处理结果，对时间有一定包容度
- 服务降级，比如文章阅读统计但是还参杂算法推荐，运营活动，但是不要影响阅读量统计的逻辑。毕竟吞吐量要求比较高

java 实现代码可以看  [胡夕老师的多线程实践](https://www.cnblogs.com/huxi2b/p/13668061.html) 

go实现代码

```go

type Consume struct {
	ctx     context.Context
	encoder encode.Encoder
	// sem 信号量，限制并发数
	sem chan struct{}
}

// n: goroutine 并发数量
func NewPdfConvertConsume(ctx context.Context, encoder encode.Encoder, n int) *Consume {
	return &Consume{
		ctx:     ctx,
		encoder: encoder,
		sem:     make(chan struct{}, n),
	}
}

func (*Consume) Setup(sarama.ConsumerGroupSession) error {
	return nil
}

func (*Consume) Cleanup(sarama.ConsumerGroupSession) error {
	return nil
}

func (p *Consume) ConsumeClaim(session sarama.ConsumerGroupSession, claim sarama.ConsumerGroupClaim) error {
	for m := range claim.Messages() {
		p.sem <- struct{}{}
		go func(msg sarama.ConsumerMessage) {
			defer func() {
				<-p.sem
			}()
			data := &action.Context{}
			logger.Debugf("consumer msg: %s", string(msg.Value))
			if err := p.encoder.Decode(data, msg.Value); err != nil {
				logger.Wrapf(err, "msg decoder failed")
			} else {
        // todo 业务逻辑
			}
		}(*m)
		session.MarkMessage(m, "")
	}
	return nil
}

```

# kafka 单线程处理单个消费者的消息

- 可以保证kafka的消息交付语义的，实现方式简单易维护
- 需要更多的TCP连接

- 线程自己处理消息可能会造成超时导致rebalance

如果消息处理时间较长，可以调整参数 或者 细化处理步骤保证消息处理速度 来避免频繁的rebalance

**参数调优**:

`heartbeat.interval.ms` : 心跳间隔，用来保持consumer的会话，并且在有consumer加入或者离开group时帮助进行rebalance，这个值必须要小于 `session.timeout.ms`, 在超过`session.timeout.ms` 时间内如果没有收到hearbeat消息，就会将该consumer移出 consumer group, 一般设置 `session.timeout.ms `的 1/3

`session.timeout.ms` ： session会话过期时间

`max.poll.interval.ms` : 最大poll数据间隔，默认值是3s, 如果超过这个时间还是没有发起poll请求，即使heartbeat依旧在发，还是会把consumer 移出 consumer group



# kafka 增加分区数

```
./kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic demo --partitions 6
```



1.kafka 多线程处理单个消费者消息 2. kafka 单线程处理单个消费者消息 3. kafka 增加分区数量

kafka 多线程单消费者 vs 单线程单消费者

prometheus/jmx_exporter 收集jmx指标，grafana 监控 kafka

分享 kafka prometheus 监控方案: jmx 监控指标 grafana dashboard


![image-20210223212719619](/images/blog/1/prometheus/assert/image-20210223212719619.png)

prometheus提供了node_exporter来收集主机数据

node_exporter下载地址: [https://github.com/prometheus/node_exporter/releases](https://github.com/prometheus/node_exporter/releases)

supervisor维护进程运行

```ini
[program:node_exporter]
command=/data/node_exporter/node_exporter-1.1.1.linux-amd64/node_exporter
autostart=true
autorestart=true
user=root
numprocs=1
redirect_stderr=true
stdout_logfile=/data/node_exporter/logs/access.log
```

grafana dashboard: [https://grafana.com/grafana/dashboards/8919](https://grafana.com/grafana/dashboards/8919)



prometheus收集主机数据


概述：

- kafka消费者、消费者组和消费者位移？
- kafka幂等性以及避免重复消费？
- go kafka consumer 封装

背景：和producer同样的用途，统计博客网页浏览数据

# kafka消费者、消费者组和消费者位移？

kafka consumer 从 broker 中 pull 数据，producer push 数据到 broker 中。

优点：consumer可以承受能力的范围内控制消费速度，而且可以批量获取消息块

缺点：如果broker中没有数据，consumer会有轮询broker接口，这里kafka提供了参数来阻塞fetch请求直到有数据可以消费

**消费者组的特性：**

1. 一个消费者组可以有一个或者多个消费者
2. topic的一个partition只能有一个消费者组中的一个消费者消费，要想实现分布式消费，必须要有多个patition

**消费者位移：**

kafka面临的问题，如何让broker 和 consumer 就被消费的数据保持一致性

- broker发送消息给consumer之后立即标记为consumed。如果 consumer 崩溃或者请求超时或者其他原因，就会导致消息丢失
- 增加确认机制，消息发送标记消息为sent，consumer消费成功后标记消息为consumed。
    - 如果consumer消费成功了，但是在发送确认之前崩溃了，broker需要再次发送消息，就会导致消息重复消费。
    - 性能问题：broker需要为每个消息保存多个状态，状态的变动需要加锁
    - 如果消息一直得不到确认该如何处理

kafka的是如何实现消息确认机制的：

每一个 partition 在任意给定的时间内只能被每个订阅了这个 topic 的 consumer 组中的一个 consumer 消费，只需要保存这个consumer下一条要消费的消息的位移即可

- 同一个消费者组的消费者 不会并发消费 同一个partition，不需要加锁
- 不需要保存多个状态，消费者确认要消费到了哪一条，只想下一条即可。
- 如果consumer消费逻辑出现bug，可以在 bug 修复后通过回退到之前的 offset 来再次消费这些数据 （重要）, go 可以指定出初始位移`conf.Consumer.Offsets.Initial`来再次消费



# kafka幂等性以及避免重复消费

正常情况下producer push一条消息到broker，然后consumer从broker pull消息然后消费，这只是理想状态的情况下。我们需要考虑的是发生异常的情况kafka如何做到保证消息是不丢失，不重复消费的。

- producer 发布消息的持久性保证
- consumer 消费消息的保证，只被消费一次

**如果一个 producer 在试图发送消息的时候发生了网络故障， 则不确定网络错误发生在消息提交之前还是之后，broker到底有没有收到这条消息并持久化**？

答：如果我们想要确保消息可以重传，但绝不丢失。kafka 0.11.0.0 之前的版本就是重发机制，之后的版本增加了幂等性，会为每条消息分配序列号来避免在broker log中产生重复消息。同时kafka提供了事务机制，多条消息写入log要么都成功要么都失败。

kafka所有的副本都有相同的 log 和相同的 offset。consumer 负责控制它在 log 中的位置，理想状态下consumer永远不会崩溃，没问题。**如果consumer崩溃了，这个topic partition必须要有另一个进程来接管，此时该从哪个offset开始接管？**

1. consumer先读取消息，然后将它的位置保存在log中，在处理相应的消息，如果异常发生在位置保存后，即使有其他进程接管，这条消息可能也会丢失了
2. consumer先读取消息，处理消息，最后保存它的位置，如果异常是在消息处理完成后，还没有保存消息时。消息可能会被重复处理。

答：2种解决方案，步骤就是先读取，在消费，最后更新位移，这样可以保证消息不丢失，可能会造成消息重复消费

- 简单的方案：幂等性保证，使用offset作为唯一键，数据和offset一起写库，如果offset不存在就先建，否则更新。
- 复杂的方案：2步提交，消费完成写库，状态为待提交，更新kafka log offset，更新库的状态为已提交，此方案会复杂化问题，推荐幂等性保证，简单有效。

重点：consumer消费数据时，要做一次幂等性消费，避免重复消费数据



# kafka 消费者 & 分区

Kafka 消费者从属于消费者群组。一个群组里的消费者订阅的是同一个主题，每个消费者 接收主题一部分分区的消息。

- 假设主题 T1 有 4 个分区，我们创建了消费者 C1，它是群组 G1 里唯一的消费者，我们用 它订阅主题 T1。消费者 C1 将收到主题 T1 全部 4 个分区的消息
- 如果在群组 G1 里新增一个消费者 C2，那么每个消费者将分别从两个分区接收消息。假设消费者 C1 接收分区 0 和分区 2 的消息，那么消费者 C2 节会接收分区 1 和分区 3 的消息
- 如果群组 G1 有 4 个消费者，那么每个消费者可以分配到一个分区
- 如果群组添加更多的消费者，超过主题的分区数量，那么有一部分消费者就会被 闲置，不会接收到任何消息

**再均衡**：分区的所有权从一个消费者转移到另一个消费者

消费者通过向consumer-group 协调器的broker发送心跳来维持他们和群组的从属关系以及它们对分区的所有权关系，只要消费者以正常的时间间隔发送心跳，就被认为是活跃的，说明还在正常读取分区的消息，

如果消费者发生崩溃，consumer-group协调器broker，在确认了该consumer死亡后会出发再均衡。

`max.poll.interval.ms` 控制发送心跳的间隔时间

`session.timeout.ms` 控制失联多久判定为死亡

# go kafka consumer 

封装一下go consumer支持

- 优雅关闭consumer
- 记录consumer异常，同producer一样Consumer.Return channel设置为true以后必须有相应的读取，否则会阻塞
- kafka崩溃恢复，可重新加入consumer group，恢复消费

```go
type ConsumerGroup interface {
	Consume(topic []string, handler sarama.ConsumerGroupHandler)
}

type consumerGroup struct {
	ctx     context.Context
	client  sarama.ConsumerGroup
	groupId string
}

func NewConsumerGroup(ctx context.Context, groupId string) ConsumerGroup {
	conf := sarama.NewConfig()
	conf.Version = sarama.V0_11_0_2
	conf.Consumer.Return.Errors = true
	client, err := sarama.NewConsumerGroup(config.Kafka.Broker(), groupId, conf)
	if err != nil {
		panic(errors.Wrap(err, "kafka new consumer client err"))
	}
	// Track errors
	go func() {
		for err := range client.Errors() {
			logger.Wrapf(err, "kafka %s consume err", groupId)
		}
	}()
	go func() {
		for {
			select {
			// 主进程退出，通知consumer关闭
			case <-ctx.Done():
				_ = client.Close()
				//logger.Infof("quit: kafka consumer %s", groupId)
				return
			}
		}
	}()
	return &consumerGroup{
		ctx:     ctx,
		client:  client,
		groupId: groupId,
	}
}

func (c *consumerGroup) Consume(topic []string, handler sarama.ConsumerGroupHandler) {
	go func() {
		defer c.client.Close()
		for {
			err := c.client.Consume(c.ctx, topic, handler)
			if err != nil {
				switch err {
				case sarama.ErrClosedClient, sarama.ErrClosedConsumerGroup:
					// 退出
					logger.Infof("quit: kafka consumer %s", c.groupId)
					return
				case sarama.ErrOutOfBrokers:
					logger.Errorf("kafka 崩溃了~")
				default:
					logger.Errorf("kafka exception: %s", err.Error())
				}
				time.Sleep(1 * time.Second)
			}
		}
	}()
}
```
---

go kafka consumer group 使用姿势


prometheus 是go语言编程的，可以直接下载对应系统的二进制文件运行即可。

**预编译二进制安装**

下载地址: 

- prometheus [https://prometheus.io/download/](https://prometheus.io/download/)
  - centos 下载 `.linux-amd64.tar.gz` 即可
- grafana https://grafana.com/grafana/download

prometheus安装:

```shell
tar -zxvf prometheus-2.25.0.linux-amd64.tar.gz
./prometheus
```

grafana安装：

```shell
wget https://dl.grafana.com/oss/release/grafana-7.4.2-1.x86_64.rpm
sudo yum install grafana-7.4.2-1.x86_64.rpm
```

**docker安装prometheus/grafana**

`docker-compose.md`

```yml
version: '3.2'
services:
  prometheus:
    image: prom/prometheus
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    networks:
      - prometheus_network
  grafana:
    image: grafana/grafana
    container_name: grafana
    ports:
      - 3000:3000
    networks:
      - prometheus_network
networks:
  prometheus_network:
    driver: bridge
```

`prometheus.yml`

```yml
# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.
    static_configs:
    - targets: ['docker.for.mac.host.internal:9003']
```

docker 调用宿主机服务，使用 `docker.for.mac.host.internal` 作为host

**grafana设置prometheus datasource**

![image-20210219173605639](/images/blog/1/prometheus/assert/prometheus-grafana-datasource.png)



Prometheus Grafana 安装配置

概述

- kafka 库
- producer config 配置
- sync vs async
- 压缩方式

背景：博客文章想统计访问数据，每日pv/uv/ip数据

分析：

- 网页浏览数据，主要以写为主
- 时效性、事务持久要求不高
- 数据量大

kafka特别适合这种场景，高吞吐量，较低的端到端延迟，强大的持久性。

# go kafka 库

- [github.com/Shopify/sarama](https://pkg.go.dev/github.com/Shopify/sarama)  使用人数较多，我公司也是用的这个库
- [github.com/confluentinc/confluent-kafka-go](https://github.com/confluentinc/confluent-kafka-go) 我没有做过实验，有兴趣的朋友自己尝试一下

```
go get github.com/Shopify/sarama
```

# sync vs async

同步异步的区别, 如果因为实时性要求没那么高的话，推荐使用async，总结一下原因：kafka面临的2大难题之一，**持久化要面临磁盘大量的I/O操作**，如此频繁的写，即便是顺序写、有pagecache可以缓冲、有mmap减少一次内核态的复制，磁盘也是难以承受。

kafka的处理也是很简单，加缓存，本来1毫秒100次写，broker缓存10次一写（数据块），这样可以减轻10倍的I/O压力。

所以这里也是同样的思想，kafka加了一层缓存，我们producer也可以在加一层缓存，又可以减轻n倍的I/O压力。所以在实时性要求不高的前提下，推荐使用async

async有4个配套参数

```go
conf := sarama.NewConfig()
conf.Producer.Flush.Messages = 10                      // 缓存条数
conf.Producer.Flush.Frequency = 500 * time.Millisecond // 缓存时间

Flush struct {
  // 达到多少字节时，触发一次broker请求
  Bytes int
  // 达到多少条消息时，触发一次broker请求
  Messages int 
  // producer缓存消息的时间, 默认缓存500毫秒 => queue.buffering.max.ms
  Frequency time.Duration 
  // producer缓存队列里最大缓存的消息数量 => queue.buffering.max.messages
  MaxMessages int
}
```

完整的prodcuer用法

```go
type Produce struct {
	AsyncProducer sarama.AsyncProducer
}

func NewProducer(ctx context.Context) *Produce {
	conf := sarama.NewConfig()
	conf.Producer.RequiredAcks = sarama.WaitForAll
	conf.Producer.Return.Errors = true                     // 接收producer的error，下面细说用法
	conf.Producer.Compression = sarama.CompressionLZ4      // 压缩方式，如果kafka版本大于1.2，推荐使用zstd压缩
	conf.Producer.Flush.Messages = 10                      // 缓存条数
	conf.Producer.Flush.Frequency = 500 * time.Millisecond // 缓存时间

	producer, err := sarama.NewAsyncProducer(config.Kafka.Broker(), conf)
	if err != nil {
		panic(errors.Wrapf(err, "failed to open kafka producer: "))
	}
	pd := &Produce{AsyncProducer: producer}
	// 接受结束信号
	go func() {
		for {
			select {
			case err := <-producer.Errors():
				logger.Errorf("kafka producer send error %s", err.Err.Error())
			case <-ctx.Done(): // 接收主进程结束信号，持久化缓存数据，防止丢失，关闭producer连接
				_ = producer.Close()
				logger.Infof("quit: kafka producer")
				return
			}
		}
	}()
	return pd
}

func (p *Produce) Send(topic string, value []byte) {
	p.AsyncProducer.Input() <- &sarama.ProducerMessage{
		Topic: topic,
		Value: sarama.ByteEncoder(value),
	}
}
```

- `conf.Producer.Return`: 这里是go语言的专属用法，有2个channel，**重点：**如果 `conf.Producer.Return.Errors = true` 设置为了true，就必须有相应读取channel，否则会阻塞producer写消息，success channel/error channel默认capacity只有256字节 <a name="producer_return"></a>
    - `success`: 写消息成功channel 
    -  `errors`:  错误channel
- `conf.Producer.RequiredAcks` 对应java producer的 `request.required.acks`
    - `sarama.NoResponse` - `0`:   producer不等待来自broker同步完成的确认继续发送下一条（批）消息。延迟最低/消息持久化保证性最低（当服务器发生故障时某些数据会丢失，如leader已死，但producer并不知情，发出去的信息broker就收不到）。
    - `sarama.WaitForLocal` - `1`: producer在leader已成功收到的数据并得到确认后发送下一条message，没有确认其他副本是否收到。持久化保证较好（被写入死亡leader但尚未复制将失去了唯一的消息）
    - `sarama.WaitForAll` - `2`（默认）:  producer在leader以及follower副本确认接收到数据后才算一次发送完成。 

- `conf.Producer.Compression` : kafka 消息压缩了，综合考量来说，如果kafka版本大于2.1可以使用zstd，小于2.1版本可以使用lz4, 无论是cpu占用还是压缩比例的角度上看

| 算法           | cpu  | 压缩比（带宽同理） | producer吞吐量(压缩快慢) | consumer吞吐量(解压缩快慢) |
| -------------- | ---- | ------------------ | ------------------------ | -------------------------- |
| Gzip           | 1    | 3                  | 4                        | 3                          |
| Snappy         | 4    | 4                  | 2                        | 2                          |
| LZ4            | 3    | 2                  | 1                        | 1                          |
| ZSTD (2.1版本) | 2    | 1                  | 3                        | 4                          |

# issue

1. go kafka producer在写消息时，写了1，2条就阻塞了？ 

答：[conf.Producer.Return配置姿势不对？](#producer_return) 

`conf.Producer.Return`: 这里是go语言的专属用法，有2个channel，**重点：**如果 `conf.Producer.Return.Errors = true` 设置为了true，就必须有相应读取channel，否则会阻塞producer写消息，success channel/error channel默认capacity只有256字节 <a name="producer_return"></a>

- `success`: 写消息成功channel 
-  `errors`:  错误channel



go kafka producer在写消息时，写了1，2条就阻塞了？

go kafka producer 实践与落地


数据量大的话：mysql是通过partition分区表支持按日期来分区，es通过index名称来达到分区的策略

es可以通过put mapping来创建，但是每天都要新的index，mysql需要写脚本自动来添加partition。es提供了template来完成，当POST doc时，如果不存在会匹配template初始化mapping

**创建template**

支持通配符匹配，如果匹配到多个，按照order优先排序使用

```
PUT _template/tracking_template
{
  "order": 0,
  "index_patterns": [
    "spider_*"
  ],
  "settings": {},
  "mappings": {
    "properties": {
      "date": {
        "type": "date"
      },
      "spider": {
        "type": "keyword"
      }
    }
  },
  "aliases": {}
}
```

**查看索引模版**

```curl
GET _template                							// 查看所有模板
GET _template/spider_*          					// 查看与通配符相匹配的模板
GET _template/spider_2020,spider_2021   	// 查看多个模板
GET _template/spider_template  						// 查看指定模板
```

**删除索引模版**

```curl
DELETE _template/spider_template
```

使用es存储log日志来分析数据，需要按日期来分割数据（douyacun_log-2021-02）定时删除历史数据

es使用template自动初始化mapping


## react天气组件

 [![npm](https://img.shields.io/npm/v/react-tencent-weather)](https://www.npmjs.com/package/react-tencent-weather) [![npm](https://img.shields.io/npm/dm/react-tencent-weather)](https://www.npmjs.com/package/react-tencent-weather) [![npm](https://img.shields.io/npm/l/react-tencent-weather)](https://www.npmjs.com/package/react-tencent-weather) ![echarts supported](https://img.shields.io/badge/echarts-%5E3.0.0%20%7C%7C%20%5E4.0.0-blue.svg) ![react supported](https://img.shields.io/badge/React-%5E16.8.0-blue.svg)

体验地址: [https://www.douyacun.com](https://www.douyacun.com)

文档：[https://www.douyacun.com/article/b9093956c565e471f45c035b5870ed0c](https://www.douyacun.com/article/b9093956c565e471f45c035b5870ed0c)

特点：

1. 使用腾讯天气接口: `https://wis.qq.com/weather/common?source=pc&weather_type=forecast_1h|forecast_24h|alarm|limit|tips|rise|observe|index&province=${province}&city=${city}&county=`
2. 支持：逐小时预报/7日天气预报/生活指数
3. 支持IP定位，使用[免费IP定位接口](https://www.douyacun.com/article/a57b58a343f051cf1fb9761a31d37693)
4. 支持服务端渲染

![react腾讯天气组件](/images/blog/1/react/assert/image-20210107225932253.png)
![react腾讯天气组件](/images/blog/1/react/assert/image-20210107230116155.png)


## install

```bash
npm install react_tencent_weather --save
```

运行demo:

```bash
git clone https://github.com/douyacun/react-tencent-weather.git

npm install

npm start
```

本地浏览器打开 [http://127.0.0.1:3000](http://127.0.0.1:3000)

## usage

客户端使用

```react
import React from 'react';
import ReactDOM from 'react-dom';
import Weather from 'react-tencent-weather';

ReactDOM.render(
    <div><Weather province="上海" city="上海" /></div>,
    document.getElementById('root')
)
```

服务端渲染

```react
import React from 'react';
import ReactDOM from 'react-dom';
import Weather from 'react-tencent-weather/lib/ssr/index.js';
import 'react-tencent-weather/lib/ssr/index.css';

ReactDOM.render(
    <div><Weather province="上海" city="上海" /></div>,
    document.getElementById('root')
)
```

## component props

- `province`: (optional, string)

省份，默认上海

- `city`: (optional, string)

城市，默认上海

- `showDays` : (optional, bool)

是否显示 7日天气预报

- `showHours`: (optional, bool)

是否显示 逐小时预报

- `showLiving`: (optional, bool)

是否显示 生活指数

- `showTomorrow`:  (optional, bool)

是否显示明日预报

# LICENSE

MIT@[douyacun](https://github.com/douyacun)

关注我的微信公众号

![douyacun](/images/blog/1/react/assert/douyacun_qrcode.jpg)


博客右边框空荡荡的，需要一个天气组件来支撑一下，就写了这个天气组件～

react天气组件: 腾讯天气


**敬请周知**：

1. 添加友情链接的2种方式
    1. **注册并且在此文章底部评论以后** 会自动添加（推荐） :
        1. 恁叫啥 -> 站点名称 eg: Douyacun
        2. 站点 -> 博客的地址 eg: https://www.douyacun.com
    2. 发个邮件到 douyacun@gmail.com ，写明站点名称/站点连接
2. 小技巧：
    1. `command + alt + u` 查看源码必须包含有站点名称和站点链接
    2. `<a>` 标签里面不要 `alt="nofollow"`
    3. 确保你的站点已经添加了友情链接 `<a href="https://www.douyacun.com" target="_blank">Douyacun</a>` 
    4. `robots.txt` 不要 `Disallow`
3. 目前仅有20个坑位

![douyacun入驻](/images/blog/1/敬请周知/assert/douyacun入驻.png)

