
**特点：**

- 中国各大城市，不包括自治州地区，支持的城市地区:  [https://www.douyacun.com/static/中国城市adcode.json](https://www.douyacun.com/static/中国城市adcode.json)
- 预报纬度： 小时预报，7天天气预报，生活指数，空气质量，日升日落时间，尾号限行
- [数据来源于中国天气网](http://www.weather.com.cn/)，长期稳定维护
- 天气数据每小时更新
- 接口支持jsonp调用

**请求限制:**


# 文档

**请求方法**:

- GET

**接口地址:**

- https://www.douyacun.com/api/openapi/weather

**测试Token:**

- eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJBY2NvdW50SWQiOiJlZWQ4ZmQ1ODBmYTRmNjkyIn0.d7qF_mjdXMC0R5M6f04Lnh6x61kaU4lqHT0Axt9xUOY
- 此token仅用于测试使用，限流 1次/s，大家共享此token

**测试url：**

`https://www.douyacun.com/api/openapi/weather?province=%E4%B8%8A%E6%B5%B7&city=%E4%B8%8A%E6%B5%B7&weather_type=forecast_hour|forecast_day|alarm|limit|rise|observe|index|air&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJBY2NvdW50SWQiOiJlZWQ4ZmQ1ODBmYTRmNjkyIn0.d7qF_mjdXMC0R5M6f04Lnh6x61kaU4lqHT0Axt9xUOY`

**限流**

- 开通接口权限 <a name="token"></a>
    - 关注微信公众号，私信说明 **开通天气API**，自动创建并回复token
- QPS 默认 5/s, 最大并发10/s, 10万次/天
- QPS 可以增加到 10/s，最大并发20/s, 100万次/天，够用了。。。。
- 更大频次需要支付流量费用，100元长期支持，不限频次次

![douyacun1](https://www.douyacun.com/static/image/douyacun%E5%BE%AE%E4%BF%A1%E5%85%AC%E4%BC%97%E5%8F%B7.png)


**参数:**

| 参数名       | 是否必选 | 类型   | 参数说明                                                     |                             备注                             |
| ------------ | -------- | ------ | ------------------------------------------------------------ | :----------------------------------------------------------: |
| province     | 否       | string | 省份                                                         |                             北京                             |
| city         | 否       | string | 城市                                                         |                             北京                             |
| adCode       | 否       | string | 城市AdCode                                                   | [城市code](https://www.douyacun.com/static/%E4%B8%AD%E5%9B%BD%E5%9F%8E%E5%B8%82adcode.json) |
| ip           | 否       | string | ip地址定位                                                   |                        60.207.131.25                         |
| callback     | 否       | string | jsonp调用参数                                                |                                                              |
| token        | 是       | string | [token申请](#token)                                          |                                                              |
| weather_type | 是       | string | forecast_hour\|forecast_day\|alarm\|limit\|rise\|observe\|life_index\|air |                           `|` 分割                           |

**备注:**

- 如果不传参数将会使用 IP 定位城市

- 参数优先级：province,city > adcode > ip 
- weather_type
    - `forecast_hour` 小时预报
    - `forecast_day` 7天天气预报
    - `alarm` 报警
    - `limit` 限行
    - `rise` 日出日落时间
    - `observer` 今日天气
    - `life_index` 生活指数
    - `air` 空气质量

**响应JSON**

```json
{
    "code": 0, // 0 成功
    "data": {
       // air 空气质量
        "air": {
            "aqi": 55, // 空气质量
            "aqi_level": 2,// 空气质量等级
            "aqi_name": "良",// 空气质量等级
            "pm10": "59",// Pm10 总悬浮颗粒物是指漂浮在空气中的固态和液态颗粒物的总称，[1]其粒径范围约为0.1-100 微米
            "pm2.5": "21",// pm2.5 细颗粒物指环境空气中空气动力学当量直径小于等于 2.5微米的颗粒物
            "co": "1",// 一氧化碳
            "no2": "11",// 二氧化氮
            "so2": "13",// 二氧化硫
            "update_time": "20210425120000"
        },
        // alarm 报警
        "alarm": [
            {
                "detail": "哈尔滨市人民政府森林（草原）防灭火指挥部、市气象局和市林业和草原局4月24日13:00联合发布全市森林（草原）火险黄色预警信号：预计24下午至26日，我市以晴或多云天气为主，气温逐步回升，最高气温15到19℃，平均风力4到5级，阵风7级左右，森林草原火险等级为3级。请各区、县（市）人民政府森林草原防灭火指挥部及各有关单位和人员立即按照“预警响应方案”进入三级森林草原防灭火工作状态，做好森林草原防灭火各项措施的落实和扑火准备工作。（预警信息来源：国家预警信息发布中心）",// 报警详情
                "info": "202104241300509532森林（草原）火险黄色",// 报警信息
                "level_code": "00",// 报警级别
                "level_name": "黄色",// 报警级别
                "type_code": "00",
                "type_name": "森林（草原）火险"// 报警类别
            }
        ],
        // 7天预报
        "forecast_day": [
            {
                "day_weather": "阴", // 天气状况
                "day_weather_code": "02",
                "day_weather_short": "阴",
                "day_wind_direction": "北风",// 白天风向
                "day_wind_direction_code": "8",
                "day_wind_power": "4",// 风力
                "day_wind_power_code": "1",
                "max_degree": "7",// 最高温度
                "min_degree": "2",// 最低温度
                "night_weather": "晴",// 白天天气
                "night_weather_code": "00",
                "night_weather_short": "晴",
                "night_wind_direction": "西北风", // 夜晚风向 
                "night_wind_direction_code": "01",
                "night_wind_power": "3",// 夜晚风力
                "night_wind_power_code": "0",
                "time": "2021-04-24" // 日期
            },,,,,,,,,
        ],
        // 小时预报
        "forecast_hour": [
            {
                "degree": "12",// 温度
                "weather": "晴",// 天气
                "weather_code": "00",// 天气代码
                "weather_short": "晴",
                "wind_direction": "北风",// 风向
                "wind_power": "3",// 风力
                "update_time": "2021-04-25 12:00:00"
            },,,,,,,,,,,
        ],
        // 尾号限行
        "limit": {
            "tail_number": "" // 尾号限行
        },
        // 当前天气 
        "observe": {
            "degree": "13",// 温度
            "humidity": "28",// 湿度
            "precipitation": "0",// 降水量
            "pressure": "1010",// 气压
            "weather": "晴",// 天气
            "weather_code": "00",
            "weather_short": "晴",
            "wind_direction": "8",// 风向
            "wind_power": "3"// 风力
        },
        "life_index": {
            "airconditioner": {
                "detail": "您将感到很舒适，一般不需要开启空调。",
                "info": "较少开启",
                "name": "空调开启"
            },
            "allergy": {
                "detail": "天气条件较易诱发过敏，宜穿长衣长裤，远离过敏源，适当佩戴眼镜和口罩。",
                "info": "较易发",
                "name": "过敏"
            },
            "carwash": {
                "detail": "适宜洗车，未来持续两天无雨天气较好，适合擦洗汽车，蓝天白云、风和日丽将伴您的车子连日洁净。",
                "info": "适宜",
                "name": "洗车"
            },
            "chill": {
                "detail": "温度未达到风寒所需的低温，稍作防寒准备即可。",
                "info": "无",
                "name": "风寒"
            },
            "clothes": {
                "detail": "建议着厚外套加毛衣等服装。年老体弱者宜着大衣、呢外套加羊毛衫。",
                "info": "较冷",
                "name": "穿衣"
            },
            "cold": {
                "detail": "昼夜温差较大，较易发生感冒，请适当增减衣服。体质较弱的朋友请注意防护。",
                "info": "较易发",
                "name": "感冒"
            },
            "comfort": {
                "detail": "白天天气晴好，但仍会使您感觉偏冷，不很舒适，请注意适时添加衣物，以防感冒。",
                "info": "较不舒适",
                "name": "舒适度"
            },
            "diffusion": {
                "detail": "气象条件对空气污染物稀释、扩散和清除无明显影响。",
                "info": "中",
                "name": "空气污染扩散条件"
            },
            "dry": {
                "detail": "天气较好，路面比较干燥，路况较好。",
                "info": "干燥",
                "name": "路况"
            },
            "drying": {
                "detail": "天气不错，适宜晾晒。赶紧把久未见阳光的衣物搬出来吸收一下太阳的味道吧！",
                "info": "适宜",
                "name": "晾晒"
            },
            "fish": {
                "detail": "较适合垂钓，但风力稍大，会对垂钓产生一定的影响。",
                "info": "较适宜",
                "name": "钓鱼"
            },
            "heatstroke": {
                "detail": "天气舒适，令人神清气爽的一天，不用担心中暑的困扰。",
                "info": "无中暑风险",
                "name": "中暑"
            },
            "makeup": {
                "detail": "温湿适宜，最好使用SPF20以上防晒霜打底，建议使用中性保湿型化妆品。",
                "info": "防晒",
                "name": "化妆"
            },
            "mood": {
                "detail": "天气较好，空气温润，和风飘飘，美好的天气会带来一天接踵而来的好心情。",
                "info": "好",
                "name": "心情"
            },
            "morning": {
                "detail": "天气不错，空气清新。",
                "info": "适宜",
                "name": "晨练"
            },
            "sports": {
                "detail": "天气较好，无雨水困扰，较适宜进行各种运动，但因气温较低，在户外运动请注意增减衣物。",
                "info": "较适宜",
                "name": "运动"
            },
            "sunglasses": {
                "detail": "白天天气晴朗，太阳辐射较强，建议佩戴透射比1级且标注UV380-UV400的遮阳镜",
                "info": "必要",
                "name": "太阳镜"
            },
            "sunscreen": {
                "detail": "紫外辐射极强，应特别加强防护，建议涂擦SPF20以上，PA++的防晒护肤品，并随时补涂。",
                "info": "极强",
                "name": "防晒"
            },
            "tourism": {
                "detail": "天气较好，温度适宜，是个好天气哦。这样的天气适宜旅游，您可以尽情地享受大自然的风光。",
                "info": "适宜",
                "name": "旅游"
            },
            "traffic": {
                "detail": "天气较好，路面干燥，交通气象条件良好，车辆可以正常行驶。",
                "info": "良好",
                "name": "交通"
            },
            "ultraviolet": {
                "detail": "紫外线辐射极强，建议涂擦SPF20以上、PA++的防晒护肤品，尽量避免暴露于日光下。",
                "info": "很强",
                "name": "紫外线强度"
            },
            "umbrella": {
                "detail": "天气较好，您在出门的时候无须带雨伞。",
                "info": "不带伞",
                "name": "雨伞"
            }
        }
    },
    "message": "success"
}
```











数据来源于中国天气网, 每小时更新一次

中国城市天气接口：小时预报,7天天气预报,尾号限行,生活指数,空气质量,日升日落时间


面试题:

```go
package main

func main() {
	m := make(map[string]*student)
	stus := []*student{
		&student{Name: "zhou", Age: 24},
		&student{Name: "li", Age: 23},
		&student{Name: "wang", Age: 22},
	}
	l := sync.RWMutex{}
	wg := sync.WaitGroup{}
	for _, stu := range stus {
		wg.Add(1)
		go func() {
			defer wg.Done()
			l.Lock()
			local := stu
			// fmt.Println(local)
			m[local.Name] = local
			l.Unlock()
		}()
		//fmt.Println("111")
	}
	wg.Wait()
	fmt.Printf("%+v", m)
}
```

第一次测试输出：

```
map[wang:0xc00000c060]
```

第二次，main gouroutine 是不是和 其他的gouroutine并行, 在 循环中 下打印  `fmt.Println("111")`， 在 goroutine中 打印 stu 看看啥情况，多次运行都是：

```
111
111
111
{zhou 24}
{wang 22}
{wang 22}
map[wang:0xc0000a6020]
```

第一次的输出还是可以想到 闭包指针引用外部变量，那这第二次开始怀疑人生了。我又试了试注释掉 `fmt.Println(local)`

```
第一次:
111
111
111
map[wang:0xc00000c060 zhou:0xc00000c060]

第二次:
111
111
111
map[li:0xc00000c060 zhou:0xc00000c060]
```

见鬼了...



这个问题平常开发也是经常会犯错误的，不过goland可以给出提示出来

1. 闭包引用外部变量是 指针引用，参数传值是值复制

2. main gourouine 和 其他goroutine 都是并发运行的

3. 标准输出阻塞的，所以我们每次打印内容以后导致和想象的结果不一样了

    

1. 闭包指针引用外部变量 2. 标准输出会阻塞

go面试题：闭包函数指针引用 & 标准输出阻塞


背景：

- 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收集主机数据


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消费者、消费者组和消费者位移？
- 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 使用姿势

概述

- 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）定时删除历史数据

关键字