N天学会Go语言

之前一直有了解 Go 语言，但没系统的学习，最近~~兴趣盎然~~生计所迫，得学一学了。整体来说 Go 语法很简洁，有其它语言基础的话学起来很快的。本文记录了一些学习笔记，加深理解。

基础语法

学语言，最重要的就是官方教程（https://go.dev/tour/list），建议不要一开始就跟着杂七杂八的教程学习。

变量

我们都知道 Go 语言是强类型的语言，所以定义变量的时候需要定义其类型，但像 C、Java，都是把类型放在前面：

// C

int i = 1;

// Java

int i = 1;

// Go

var i int = 1

咋一看有些别扭，但这有讲究的，比如符合英语系自然语言习惯，还有写起来就很方便，更突出变量名而不是类型（而且类型可以省略），官方博客有更多的介绍：Go's Declaration Syntax。还有，Go 和 Python一样，不需要写分号。

也还有简写的方式，因为定义变量的时候其实类型是确定的，编译器很容易推导，可以不用写类型。

var i int = 1

// 去掉类型

var i = 1

// 进一步简写

i := 1

看到var i = 1是不是有 JS 和 Java lombok/JDK10 的感觉，这样就很亲切了。

Methods are functions

一个函数定义：func add(x int, y int) int {}，参数类型，返回值类型一目了然，这里可以看出还是类型后置，这点其实后面 Python 3.5 加入类型提示（限制）也是这样：def add(x: int, y: int) -> int:。这里顺带提一下，Python、PHP 这些无类型声明的语言并不是真的无类型（动态类型，运行时检查），而且新版都增加了类型检查的语法，解决了重构等痛点问题。

方法和函数其实一样，只是接收方参数不一样。

type Vertex struct {

X, Y float64

}

// 方法

func (v Vertex) Abs() float64 {

return math.Sqrt(v.X*v.X + v.Y*v.Y)

}

func main() {

v := Vertex{3, 4}

fmt.Println(v.Abs())

}

// 函数

func Abs(v Vertex) float64 {

return math.Sqrt(v.X*v.X + v.Y*v.Y)

}

func main() {

v := Vertex{3, 4}

fmt.Println(Abs(v))

}

不过 Go 的函数没有 Python 的那么强大，没有默认参数、关键字参数等，虽然说 Go 讲究简洁，但这些语法糖还是很有用的，典型场景就是 Python requests 库：https://docs.python-requests.org/en/latest/api/#requests.request。

Defer

延迟调用，这个比较特殊，defer定义的操作会在方法 return 后执行，但比如传的参数就是定义时那样，官方例子修改下：

package main

import "fmt"

func main() {

var i = 0

defer fmt.Println(i)

i = 1

fmt.Println("hello")

}

输出

hello

这个有什么作用呢，其实类似 Java 中 try/catch 中的 finally，可以用于资源的清理（经典应用就是释放锁）。官方博客有介绍：Defer, Panic, and Recover。

Pointers

Go 的指针语法上来看，比 C 简单些，没有特殊的指针变量，&就是取地址，*就是取值（或者定义指针类型），也没有指针运算（其实也可以）。说到指针，又会牵扯到一个话题，传值还是传引用，简单来说 Go 传的是值，但并不代表改动不影响原数据，因为 map、slice等，可以理解本身数据结构就是指针，这些类型修改会影响原有数据，表现和其它语言一致。还有一个就是性能问题，本能的觉得传引用（指针）性能更高（其实还会带来 GC 等问题），比如字符串。

package main

import "fmt"

func main() {

s1 := "abc"

s2 := "abc"

s3 := s1

s4 := &s1

fmt.Println(s1, s2, s3, *s4)

fmt.Printf("%p %p %p %p", &s1, &s2, &s3, s4)

}

输出为：

1 2	abc abc abc abc 0xc00018a050 0xc00018a060 0xc00018a070 0xc00018a050

咋一看 s2, s3 都是一个新的内存地址，这不影响性能嘛。但再看看：

package main

import "fmt"

import "unsafe"

import "reflect"

func main() {

s1 := "abc"

s2 := "abc"

s3 := s1

s4 := &s1

fmt.Println(s1, s2, s3, *s4)

fmt.Printf("%p %p %p %p\n", &s1, &s2, &s3, s4)

fmt.Printf("%p %p %p %p\n",

(*reflect.StringHeader)(unsafe.Pointer(&s1)).Data,

(*reflect.StringHeader)(unsafe.Pointer(&s2)).Data,

(*reflect.StringHeader)(unsafe.Pointer(&s3)).Data,

(*reflect.StringHeader)(unsafe.Pointer(s4)).Data

)

s1 = "abcd"

fmt.Printf("%p %p %p %p\n",

(*reflect.StringHeader)(unsafe.Pointer(&s1)).Data,

(*reflect.StringHeader)(unsafe.Pointer(&s2)).Data,

(*reflect.StringHeader)(unsafe.Pointer(&s3)).Data,

(*reflect.StringHeader)(unsafe.Pointer(s4)).Data

)

}

输出：

abc abc abc abc

0xc000010240 0xc000010250 0xc000010260 0xc000010240

%!p(uintptr=4966888) %!p(uintptr=4966888) %!p(uintptr=4966888) %!p(uintptr=4966888)

%!p(uintptr=4967058) %!p(uintptr=4966888) %!p(uintptr=4966888) %!p(uintptr=4967058)

可以看出 Go 对字符串等有两个优化：

1. 定义变量 literals（字面量）一致时（s1 和 s2），会指向同一个地址。

2. 变量传值时（s3 := s1）复制的是 string 这个数据结构。

struct String {

char *data;

int length;

};

data 指针指向的内容没有复制。因为要存储这个新的结构体，所以 &s3 是这个结构体的内存地址，而 s1，s3 结构体中 data 指向的地址是一样的。

指针这块细节可能理解不是太准确，但意思是语言层面已经做了很多优化，正常使用即可，不要过度优化到处使用指针。 Continue Reading...

2021年7月7日

Python import机制探究

最近遇到一个需求，需要动态加载一堆 Python 模块，但是这些 .py 是 pb 文件生成的，无法控制命名，导致导入的时候各种报错。

目录结构

├── main.py

└── temp_dir

├── __init__.py

├── basic

│ ├── __init__.py

│ └── package1.py

├── calendar

│ ├── __init__.py

│ └── package2.py

└── math

├── __init__.py

└── package3.py

package1.py 内容

from calendar import package2

from math import package3

print("import package1")

package2.py 内容

1	print("import package2")

package3.py 内容

1	print("import package3")

可以看见在 basic.package1 中导入了 package2、package3。我们在 main 文件中导入 basic 包。

import importlib

if __name__ == '__main__':

print(importlib.import_module("basic.package1"))

这样肯定不行，报错了：ModuleNotFoundError: No module named 'basic'

sys.path

Google 一下或者稍微了解 Python 的就会知道，Python 导入非系统库需要指定 PYTHONPATH，Python 启动时会读取此环境变量并加入到 sys.path 中。我们可以打印下：

['/mnt/c/Users/PycharmProjects/python-import-test',

'/usr/lib/python38.zip',

'/usr/lib/python3.8',

'/usr/local/lib/python3.8/dist-packages']

可以看到默认加载了当前项目目录、Python系统目录以及 dist-packages（通过 pip 安装的），我们把 temp_dir 目录加进去就行了。代码增加：

1 2	temp_dir = "%s/temp_dir" % os.path.dirname(__file__) sys.path.append(temp_dir)

但还是会报错：ImportError: cannot import name 'package2' from 'calendar' (/usr/lib/python3.8/calendar.py)，不过至少说明，加载路径是设置成功了，basic 包本身导入成功了，只是 from calendar import package2 执行失败了。

这个是一个经典错误，搞 Python 的都会遇到，那就是自己定义的包名不能和系统的重复，一般是改个名字或者加上命名空间，但是我们这个场景中，Python 文件是 pb 生成的，无法修改源文件，修改生成的文件也比较麻烦。也能解决，就是提高我们路径的优先级，改成 sys.path.insert(0, temp_dir) 加载完了再改回来。

BuiltinImporter

不过又有新的报错：ImportError: cannot import name 'package3' from 'math' (unknown location)，有输出 import package2，看着还是导入了系统的 math 库，没有导入自己的，还没有显示路径。这里匪夷所思，卡了很久，继续单步调试代码和查阅资料，发现 Python 其实是支持多种导入方式，甚至可以自定义。importlib._bootstrap._find_spec 中，是循环 sys.meta_path 中的 Importer 哪个找到算哪个。我们可以打印下 sys.meta_path：

1	[<class '_frozen_importlib.BuiltinImporter'>, <class '_frozen_importlib.FrozenImporter'>, <class '_frozen_importlib_external.PathFinder'>]

可以看见最前面有个 BuiltinImporter（具体是在 importlib._bootstrap._install 时注入的），唉，灵光一闪，math 就是一个内建库呀，这里结合源码猜测，C 的库（详见 sys.builtin_module_names）都是通过这个导入的。去掉这个就能导入成功了（记得加载完了还原回来）。

builtin = None

get_class_name = lambda _class: _class.__name__ if hasattr(_class, '__name__') else type(_class).__name__

for importer in sys.meta_path:

if get_class_name(importer) == 'BuiltinImporter':

builtin = importer

break

if builtin:

sys.meta_path.remove(builtin)

终于成功了：

import package2

import package3

import package1

sys.modules

不过，这里只是个 demo。实际情况比这个复杂，还是会报 ImportError: cannot import name 'package2' from 'calendar' (/usr/lib/python3.8/calendar.py)，这里很奇怪，已经保证了加载的优先级，但为什么还不行呢？没办法，扒一下源码，终于找到了一点端倪。importlib._bootstrap._find_and_load 方法中，会先在 sys.modules 里面找，如果有则直接返回，官方文档也有相应说明。

def _find_and_load(name, import_):

"""Find and load the module."""

with _ModuleLockManager(name):

module = sys.modules.get(name, _NEEDS_LOADING)

if module is _NEEDS_LOADING:

return _find_and_load_unlocked(name, import_)

所以还得排除已加载的情况

for exclude in ["calendar", "math"]:

if exclude in sys.modules:

del sys.modules[exclude]

最终到此才彻底解决，完整 demo 代码：https://github.com/iyaozhen/python-import-test

参考资料

https://docs.python.org/3/library/importlib.html

妙用Hook来研究Python的Import机制，https://www.51cto.com/article/527713.html

Python3.7源码剖析之import，https://zhuanlan.zhihu.com/p/361720373

2021年4月2日

工作5年，后3年都重复着前2年？写在离职百度之际（QA篇）

最近各种原因换了个工作，回想起来校招（实习）就进百度了，一晃5年多了。最近又宣传“十四五”，也想着自己确实得好好总结下这五年，而且市面上做 QA 的比较少，希望能对新同学有些帮助。

重新review下工作

做程序员这一块，可能都会遇到第一个瓶颈，工作前2两年成长很快（特别是 QA，都是现学），但后面就慢了，感觉重复着之前的工作。这里以“捕鼠器案例”为引子（杨震原字节内部分享，来源王梦秋百度的内部分享），重新捋一下 QA 的工作：

工作第1年

刚工作接到的任务一般比较简单、直接，比如导师可能叫你去放一下捕鼠器。这个时候你一般看看文档，多观察下，就知道捕鼠器是用来捕老鼠的，你只要不给它挂在墙上就行。甚至前人已经放过捕鼠器了，你只要依样画葫芦隔一段距离放一下就行了。

这个时候你就要稍微总结下了，放捕鼠器为什么有时没捕到老鼠，你可以会观察录像，看别人的捕鼠器怎么做的，这个时候稍作改进就会效果明显。具体的到QA的工作，你现在已经非常熟悉这块的业务，每次小功能的测试都游刃有余，而且通过学习你还会了 API/UI 自动化测试，效率也变高了。

工作第2年

由于表现还不错，你已经晋升为 T4 了。这个时候你会发现只放好老鼠夹子效果还是不好，具体到工作可能会发现线上还是有很多问题。你一想，捕鼠器是干啥，消灭老鼠，但消灭老鼠，不仅仅只有捕鼠器一种方法，或者说一种方法不够。

当一个人从完成任务到解决问题，能够再问一步，这个问题关联的问题是什么，进而去提出新的问题，这就是关键的突破点。

你可能会发现老鼠药更管用。类比测试工作上来说，你引入了更多的测试方法：diff 测试、性能测试、稳定性测试、兼容性测试、安全测试、ET测试等，工作开始变的顺风顺水。

工作第3-5年

这个时候你测试环节已经做的很不错了，能负责一个系统或者业务方向的测试了，一般的话也晋升为 T5（高级测试工程师）之列了。但这个时候就开始重复之前的工作了，项目不停迭代、新功能测也测不完。而且随着需求积累，回归测试也很多了，因此对于 QA 来说这种重复的感觉比 RD、FE 更强烈。

这个时候还得回到原点来，捕老鼠是为了什么？为了保护粮食。那 QA 找 Bug 是为了什么？是为了“质量”。

（图来源百度王梦秋分享 PPT）

这个时候介绍一个在百度内部非常重要的概念：全流程质量保障。作为 QA（Quality Assurance，质量保障），自己把自己定位成测试是不行的。

全流程质量保障

可能每个公司的项目流程都不一样，但都会包含以下几部分，当你跳出“测试”来看，就会发现能做的事情还有很多： Continue Reading...

2021年3月29日

Python使用logging为Flask增加logid

我们为了问题定位，常见做法是在日志中加入 logid，用于关联一个请求的上下文。这就涉及两个问题：1. logid 这个“全局”变量如何保存传递。2. 如何让打印日志的时候自动带上 logid（毕竟不能每个打日志的地方都手动传入）

logid保存与传递

传统做法就是讲 logid 保存在 threading.local 里面，一个线程里都是一样的值。在 before_app_request 就生成好，logid并放进去。

import threading

from blueprint.hooks import hooks

thread_local = threading.local()

app = Flask()

app.thread_local = thread_local

import uuid

from flask import Blueprint

from flask import current_app as app

hooks = Blueprint('hooks', __name__)

@hooks.before_app_request

def before_request():

"""

处理请求之前的钩子

:return:

"""

# 生成logid

app.thread_local.logid = uuid.uuid1().time

因为需要一个数字的 logid 所以简单使用 uuid.uuid1().time 一般并发完全够了，不会重复且趋势递增（看logid就能知道请求的早晚）。

打印日志自动带上logid

这个就是 Python 日志库自带的功能了，可以使用 Filter 来实现这个需求。

import logging

# https://docs.python.org/3/library/logging.html#logrecord-attributes

log_format = "%(asctime)s %(levelname)s [%(threadName)s-%(thread)d] %(logid)s %(filename)s:%(lineno)d %(message)s"

file_handler = logging.FileHandler(file_name)

logger = logging.getLogger()

logid_filter = ContextFilter()

file_handler.addFilter(logid_filter)

file_handler.setFormatter(logging.Formatter(log_format))

logger.addHandler(file_handler)

class ContextFilter(logging.Filter):

"""

logging Filter

"""

def filter(self, record):

"""

threading local 获取logid

:param record:

:return:

"""

log_id = thread_local.logid if hasattr(thread_local, 'logid') else '-'

record.logid = log_id

return True

log_format 中我们用了很多系统自带的占位符，但 %(logid)s 默认没有的。每条日志打印输出前都会过 Filter，利用此特征我们就可以把 record.logid 赋值上，最终打印出来的时候就有 logid 了。

虽然最终实现了，但因为是通用化方案，所以有些复杂了。其实官方教程中介绍了一种更加简单的方式：injecting-request-information，看来没事还得多看看官方文档。

2021年3月19日

iTerm2进阶使用技巧

iTerm2 的优点这里不做赘述了，第一次使用的话可以先看看官网的介绍：features、Highlights for New Users。本文主要是结合实际使用场景，介绍一些进阶使用技巧（基本的 Oh My Zsh、rzsz 等配置就不重复说明了）。

跳板机自动登录

现在很多公司登录服务器都需要先登录到一个跳板机然后再登录到目标机器，每次输入密码（一般还是动态的）很麻烦。一般的教程推荐使用 expext 解决这个问题，这里介绍一个更简单、直接的办法。

首先，要先解决登录到跳板机的连接复用问题，这个输入 ssh 本身的范畴，一般教程都是说在 ~/.ssh/config 增加下面的配置：

host *

ControlMaster auto

ControlPath ~/.ssh/master-%r@%h:%p

但这样有个问题，iTerm2 第一次登录的 tab 关闭后，就失效了，再登录就又要密码了。其实再增加一个配置即可。

1 2	ControlPersist yes ServerAliveInterval 60

之前的设置只是实现了连接复用，但 tab 关闭 ssh 进程结束后，连接也被销毁了，ControlPersist 项的意思是进程结束后连接还保持，再有相同的（ControlPath配置）连接，还能继续使用此连接。

再者，每次输入 ssh xxx 很麻烦（而且跳板机登录后还得输入 ssh xxx），当然你可以配置 alias+expext 但也不是太方便，特别是 Windows 转过来的。对此，iTerm2 本身也提供了很强大的 Profiles 功能，能一键登录目标机器（还可以设置快捷键）。

有些自己的常用机器，还可以复制一下这份基础的 relay 配置。

再加一行（Send text at start处）。

还可以把机器打个标签，然后页面上就能分组，方便选择。

还有一个，有时候会发现，有些机器一会儿没操作就会被断开 ssh，一方面可以设置 ServerAliveInterval，但作用不大，因为实际连接服务器的是 relay 跳板机。iTerm2 其实没有可以显式设置这个功能的地方，有些同学可能找到个这个配置： Continue Reading...

2020年3月28日

Python进/线程池使用

在 Python 中，进程/线程是个非常重要的概念，特别是 Python 还有 GIL（同一时刻只有一个线程在执行 Python bytecode）限制，使得 Python 线程并不那么好用。但 GIL 更多的是影响 CPU 密集型任务，实际业务场景更多的是 IO 密集型任务，多线程还是适用绝大多数场景。不过话又说回来，很多时候不太好判断是 IO 密集型多还是 CPU 密集型多，需要在多进程、多线程环境下分别验证。

但多线程和多进程手写起来还是有点差别，好在 multiprocessing.Pool 提供了统一的接口，可以无缝切换：

# 进程池

from multiprocessing import Pool

# dummy（假）的进程，线程池

from multiprocessing.dummy import Pool as ThreadPool

下面介绍下 Pool 类如何使用。

首先是构造函数：

class multiprocessing.Pool([processes[, initializer[, initargs[, maxtasksperchild]]]])

接收 processes initializer initargs maxtasksperchild 4个参数：

processes，就是池里有多少个进程，可以不传，默认 CPU 个数，可以按需多设置几倍

initializer、initargs，如果设置了参数，则会在每个进程初始化的时候调用 initializer(*initargs)。这个非常有用，比如可以在初始化的时候建立连接，连接重用。

maxtasksperchild，用于设置每个子进程执行多少个任务后重启。虽然很简单粗暴，但这是防止内存溢出、资源未释放等问题的常见手段，类似 PHP-FPM 的 pm.max_requests 参数。线程池无此参数。

def _send_request(sql):

"""

发送单个请求

:param request:

:return:

"""

# 取出绑定的数据库连接

db_conn = _send_request.db_conn

db_conn.execute(sql)

def _initializer(func):

"""

线程初始化工作

:param func:

:return:

"""

# 绑定建立的数据库连接到请求函数的属性上

func.db_conn = mysql.connector.connect()

pool = ThreadPool(10, initializer=_initializer, initargs=(_send_request))

result = pool.map(func=_send_request, request_list)

pool.close()

pool.join()

这里有一个 hack 技巧，将初始化的数据库连接，绑定在了请求函数上，这样调用请求函数发送请求时，就不用重新建立连接，直接使用即可。

我们一般使用线程池有两个场景，一是关注执行结果，比如我们并行去 redis mysql 各个地方请求数据，然后整合这些数据，二是不关注执行结果，比如新开一个线程打印一个请求的审计日志，不阻塞主进程返回数据。这里主要是介绍下 apply 和 apply_async 的区别，其它的都类似。

apply(func[, args[, kwds]])，主要是传一个执行函数和参数，阻塞并得到返回结果。

apply_async(func[, args[, kwds[, callback]]])，也是主要传执行函数和参数，但返回的是一个 multiprocessing.pool.AsyncResult 对象，AsyncResult 主要有 get([timeout])、wait([timeout])、ready()、successful() 4 个方法，都很好理解，用的比较多的是 get 方法，给定超时时间内获取执行的结果，如果超时抛出 multiprocessing.TimeoutError 异常。如果 timeout 是 None，则一直就等待，行为就和 apply 一致了，实际上 apply 也是调用的 apply_async get：

apply_async 还有一个有用的参数 callback，相对于异步回调了，一般用于上述的场景二。下面是一些示例：

#!/usr/bin/env python

# -*- coding: utf-8 -*

from multiprocessing.dummy import Pool

import time

callback_start_time = 0

def f_sleep(x):

time.sleep(3)

return x*x

def callback_func(result):

print 'callback result:%s use:%s' % (result, current_time_millis() - callback_start_time)

def current_time_millis():

"""

当前时间戳 ms

:return:

"""

return int(round(time.time() * 1000))

if __name__ == '__main__':

pool = Pool(processes=10)

t1 = current_time_millis()

result = pool.apply(f_sleep, (10,))

t2 = current_time_millis()

print 'apply result:%s use:%s' % (result, t2 - t1)

result = pool.apply_async(f_sleep, (10,))

t3 = current_time_millis()

print 'apply_async result:%s use:%s' % (result, t3 - t2)

result = result.get(timeout=4)

t4 = current_time_millis()

print 'apply_async result2:%s use:%s' % (result, t4 - t3)

callback_start_time = current_time_millis()

result = pool.apply_async(f_sleep, (10,), callback=callback_func)

time.sleep(4) # 看回调结果

运行结果：

apply result:100 use:3001

apply_async result:<multiprocessing.pool.ApplyResult object at 0x10876dc50> use:0

apply_async result2:100 use:3041

callback result:100 use:3002

注意代码的最后一行，这里不仅仅是为了看回调结果，还因为回调是回调到主进程执行，如果主进（线）程已经退出了，那就处理不到回调了，实际使用需要注意运行环境。

最后，multiprocessing 模块的 pool 功能只是其中很小的一部分，但比较实用，后面有新的心得再介绍其它功能。

参考资料：

https://docs.python.org/2.7/library/multiprocessing.html#module-multiprocessing.pool

2019年11月24日

Python Requests Session set-cookie不生效的坑

我们知道 Python Requests库中的 Session 模块有连接池和会话管理的功能，比如请求一个登录接口后，会自动处理 response 中的 set-cookie，下次再请求时会自动把 cookie 带上。但最近出现了一个诡异的事情，cookie 没有自动带上，导致请求 403。

一开始怀疑是登录接口错误了，没有 set-cookie，但抓包发现 response header 中有 set-cookie，打印请求的 response.cookies 也有需要的 cookie。又怀疑是 set-cookie 的格式不对或者其它问题，但用浏览器实际跑了下流程，发现系统一切正常，那基本就是 requests 库的问题了。

没办法，只能 debug 了，单步调试了几轮，基本了解了 requests 的处理方式，首先把请求参数转变为 Request 对象，然后对使用 prepare_request 对 Request 进行预处理，其中有一步 merge_cookies 的操作（还有各种其它处理），把传入的 cookies 和 self.cookies merge 到 RequestsCookieJar 对象上去，这一步也没啥问题，merged_cookies 变量也是对的。后续将预处理过的请求，通过内置的 http adapter 发送出去。http adapter 底层是通过 urllib3.poolmanager 获取到 urllib3.connectionpool 连接（这里是连接池的核心部分），再通过 conn.urlopen 实际发送请求。虽然跟踪了解到了整个请求逻辑，但最终发出的请求还是没有带上需要的 cookie。

问题定位一度陷入僵局，只能再回顾上面的流程，cookie 肯定就是在 merged_cookies 和 conn.urlopen 之间没的，再仔细观察发现，conn.urlopen 请求参数里面压根没有 cookie 字段。

# https://github.com/psf/requests/blob/master/requests/adapters.py#L439

resp = conn.urlopen(

method=request.method,

url=url,

body=request.body,

headers=request.headers,

redirect=False,

assert_same_host=False,

preload_content=False,

decode_content=False,

retries=self.max_retries,

timeout=timeout

)

查阅资料发现，urllib3 的作者说，连接池只处理底层连接，cookie 跟踪等事情应该上层来做。大胆猜测，那 cookie 应该是放在 header 里了，往前捣看看 request.headers 是怎么变动的（此时里面的 Cookie 字段确实不正确）。

再走查代码发现 prepare_request 里面是调用了 PreparedRequest.prepare，其中有一步 prepare_cookies，主要是调用了 cookielib.CookieJar.add_cookie_header 最终将 cookie 放到了 self.headers['Cookie']。但里面有个 request.has_header("Cookie") 的判断，header 中没有 Cookie 字段才会放，不知道为什么这么考虑（最新版 3.8 还是这样），估计是 merge cookie 比较麻烦，但问题确实就出在这里，这次请求之前，Requests Session 已经直接通过 headers['Cookie'] 设置了 cookie。复现代码（修改自官方示例）：

import requests

s = requests.Session()

s.headers.update({

'Cookie': 'k=v'

})

s.get('https://httpbin.org/cookies/set/sessioncookie/123456789')

r = s.get('https://httpbin.org/cookies')

print(r.text)

# 预期：{"cookies":{"k":"v"},"cookies":{"sessioncookie":"123456789"}}

# 实际：{"cookies":{"k":"v"}}，未包含sessioncookie

虽然找到了问题的原因，但又不好解决，总不能不让直接操作 headers['Cookie'] 吧，先不说无法限制使用者，而且之前的代码已经这样做了，改动量非常之大。不过好在，现在自己用的框架是在 Requests Session 上封装了一层，操作 header 都是调用的统一的 update_headers 方法：

def update_headers(self, headers):

"""

更新当前会话的header

:param headers: header字典

"""

self.headers.update(headers)

对 headers['Cookie'] 的操作拦截一下，变成对 cookies 的操作：

def update_headers(self, headers):

"""

更新当前会话的header

:param headers: header字典

"""

for header_key, header_value in headers.items:

if header_key == 'Cookie' or header_key == 'cookie':

c = Cookie.SimpleCookie()

c.load(header_value)

cookies = {}

for key, morsel in c.items():

cookies[key] = morsel.value

requests.utils.add_dict_to_cookiejar(self.cookies, cookies)

del headers[header_key]

self.headers.update(headers)

这样即不用改之前的调用方代码，也防止了后人掉坑。

参考资料

https://requests.readthedocs.io/en/master/user/advanced/#session-objects

https://stackoverflow.com/questions/2422922/python-urllib3-and-how-to-handle-cookie-support

https://urllib3.readthedocs.io/en/latest/reference/index.html#module-urllib3.poolmanager

https://urllib3.readthedocs.io/en/latest/reference/index.html#urllib3.connectionpool.HTTPConnectionPool.urlopen

https://docs.python.org/2/library/cookie.html

2019年9月26日

Filebeat核心配置详解

Filebeat简介

现在 ELK（Elasticsearch、Logstash 和 Kibana）日志分析系统非常火，但相关的介绍忽略了重要的一环：日志采集。虽然 Logstash 也能采集日志，但比较重、资源占用高，显然不适合线上和业务部署，所以一开始搞了个 logstash-forwarder 后来整合为 Filebeat。慢慢还发展成了一个 Beats 系列，支持采集各种各样的元数据。

Filebeat原理

说到实时查看日志，最常用得莫过于 tail -f 命令，基于此可以自己实现一个简单的日志采集工具，https://github.com/iyaozhen/filebeat.py/blob/master/filebeat.py#L237

但这太简陋了，无法保证不丢不重。我们看看 Filebeat 是怎么实现的，官方说明：https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-overview.html

简单来说 Filebeat 有两大部分，inputs 和 harvesters，inputs 负责找文件（类似 find 命令）和管理 harvesters，一个 harvester 则和一个文件一一对应，一行行读然后发送给 output（类似tail -f）。

当然还有很多细节问题，我们结合配置文件一一详解。

Log input配置详解

官方配置说明：https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-log.html

先看一个基本例子（下面所述基于7.x版本，6.x版本也基本适用）

filebeat.inputs:

- type: log

paths:

- /var/log/system.log

- /var/log/wifi.log

- type: log

paths:

- "/var/log/apache2/*"

fields:

apache: true

fields_under_root: true

inputs 可以配置多块（block），就是相同类型的放一块，这个也很好理解。paths 可以配置多个文件，文件路径和文件名都支持通配。

ignore_older 和 scan_frequency

这就有两个细节问题了，一是路径下的历史文件可能很多，比如配置了按天分割，显然旧文件我们一般是不需要的。二是扫描频率如何控制，通配设置复杂的话频繁扫文件也是很大的开销。

问题一则是通过 ignore_older 参数解决，意思就是多久前的旧文件就不管了。比如设置为 1h，表示文件时间在 1h 之前的日志都不会被 input 模块搜集，直到有新日志产生。

问题二则是通过 scan_frequency 参数控制，表示多久扫描一次是否有新文件产生。比如设置 10s（默认），一个新文件产生 10s 后会被发现，或者一个旧文件（上面 ignore_older）新产生了一行日志 10s 才发现这个文件。有人说我需要实时性，是不是这个值设置的越小越好，其实是错误的，前面我们介绍了 Filebeat 架构，input 模块只是负责发现新文件，新文件是相对已经被 harvester 获取的文件，第一次发现之后就已经在被 harvester 一行行实时读取了，所以这里基本上只影响日志切分时的实时性（这种场景下的短暂延迟是可以接受的）。

close_* 和 clean_*

那么被 harvester 获取的文件就一直拿着不放吗？文件重命名或者被删除后怎么办呢？这里重点介绍这两组配置。 Continue Reading...

2019年4月27日

Nginx+Tomcat偶现502分析

问题

业务为了负载均衡，前面放了个 Nginx，但最近 502 报警有点频繁，影响了 SLA，因此对这个问题做了较深入的研究。

502 Bad Gateway

简单来说就是 Nginx 找不到一个可用的 upstream，可能的原因有：

压根是配置错误
连接 upstream server 发生错误/超时
upstream server 到了处理瓶颈

还有一个重点是轮询了 upstream server 后任然没有一个可用的。但是不管什么原因，都能在 Nginx 的 error log 中找到报错详情。

upstream prematurely closed connection

在 Nginx 中找到错误日志（开了 debug）：

[debug] 46093#46093: *606728052 http upstream process header

[debug] 46093#46093: *606728052 malloc: 00007FB65E3834E0:4096

[debug] 46093#46093: *606728052 posix_memalign: 00007FB65C783D60:4096 @16

[debug] 46093#46093: *606728052 recv: eof:1, avail:1

[debug] 46093#46093: *606728052 recv: fd:65 0 of 4096

[error] 46093#46093: *606728052 upstream prematurely closed connection while reading response header from upstream, client: xxx

[debug] 46093#46093: *606728052 http next upstream, 2

[debug] 46093#46093: *606728052 free keepalive peer

[debug] 46093#46093: *606728052 free rr peer 4 4

[debug] 46093#46093: *606728052 free rr peer failed: 00007FB65C704F50 1

[debug] 46093#46093: *606728052 finalize http upstream request: 502

看了下 Nginx 代码，发现是 c->recv(); 读到的内容为 0，日志中也有显示 recv: fd:65 0 of 4096，说明没有获取到 response

同时也查了 Tomcat access 日志，请求还没到 Tomcat。看情况就像日志里面说的，连接被断掉了。

一开始怀疑是网络原因导致连接断掉了，但出现较频繁，期间内网也无网络故障，应该和网络无关。

再看日志发现报错前后有很多 keepalive 信息，尝试关掉 keepalive，502 就没了，但这会对性能有一定影响，感觉有点因噎废食了，还得继续研究。

keepalive

HTTP 持久连接（HTTP persistent connection，也称作 HTTP keep-alive 或 HTTP connection reuse）是使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，而不是为每一个新的请求/应答打开新的连接的方法。

一般 Nginx 会配置 keepalive 以提高性能：

upstream servers_test {

server 127.0.0.1:5001 max_fails=1 fail_timeout=10s weight=1;

server 127.0.0.1:5002 max_fails=1 fail_timeout=10s weight=1;

keepalive 10;

}

Syntax: keepalive connections;

Activates the cache for connections to upstream servers.

The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are preserved in the cache of each worker process. When this number is exceeded, the least recently used connections are closed.

可以配置每个 worker 对 upstream servers 最大长连接数量。同时这个长连接受 keepalive_requests（默认100）和 keepalive_timeout（默认60s）配置的影响。

但 keepalive 也有缺陷，会加重 webserver 的负担，因为需要绑定一定数量的线程或者进程来维持长链接。注意 keepalive 并没有连接复用（即同一时间窗口不能处理多个请求，这个在 HTTP/2 中才实现），仅节省了新建/关闭连接的开销，类似连接池了。所以 webserver 一般都有类似 nginx 的 keepalive_requests、keepalive_timeout 配置，让空闲的连接断掉。

查看了 upstream(tomcat) 配置的 timeout 是20s，lighttpd 的 requests 是16，timeout 是 5s，都远小于 nginx 的配置。

原因就清楚了，upstream servers 先断了 keepalive 的长连接，但 nginx 仍使用了这个已经断掉的连接。

至于 nginx 为什么不主动检测一下连接是否可用呢？猜测应该是性能原因，一直检查连接池中的连接是否可用没必要，keepalive 协议本身也没业务心跳啥的。PS：商业版的 ngx_http_upstream_hc_module 可以主动监测（世界加钱可及）。

proxy_next_upstream

那么 Nginx 如何保证高可用呢？答案是重试。这就涉及另一个重要配置 proxy_next_upstream，在什么情况下进行重试，默认为 error timeout。按理说我们这个场景应该会重试，但没有重试。这是因为 Nginx 较新版本（1.9.13）多了个 non_idempotent 配置，默认 POST, LOCK, PATCH 等请求不重试，因为这些操作是非幂等操作，会对服务端数据造成影响（比如发消息接口，重试可能会重复发消息）。日志中也发现 502 的全都是 POST 请求。

要完全解决这个问题就需要对 proxy_next_upstream 配置簇深入看看，我们先做个测试。 Continue Reading...

2019年4月4日

Windows 10生产力提升之WSL实践

Mac 和 Windows 哪个更好，估计还能再吵几年。抛开部分硬件上的差距，Windows 用作开发上确实有点不顺手，毕竟大部分后端程序都是运行在 Linux 服务器上，macOS 占有先天优势。之前都是通过在 Windows 上起虚拟机来解决这个问题，如今 Windows 10 推出的 WSL（Windows Subsystem for Linux），成为了新的选择。 WSL 的官方介绍：

The Windows Subsystem for Linux lets developers run GNU/Linux environment - including most command-line tools, utilities, and applications - directly on Windows, unmodified, without the overhead of a virtual machine

简单来说就是不需要修改，无需虚拟机，就可以在 Windows 上直接使用 Linux 环境（grep, sed, awkd等），运行 Linux 程序（vim, MySQL, Apache等）。这就很舒服了，小孩子才做选择，大人全都要，实际如何我们来实践一番。

安装

首先是按照，非常简单，开启子系统功能后在应用商场选择一个发行版的 Linux 安装就行。官方指南：https://docs.microsoft.com/en-us/windows/wsl/install-win10

启动之后就可以使用了，你可以根据自己使用习惯，做一些初始化的设置（oh-my-zsh啥的）这里就不细说了。WSL 默认是通过安装的应用进入的（直接运行 bash.exe 也行），但大家还是喜欢通过 Xshell 等工具进入了，这就需要做一些配置。WSL 和 Windows 本机是端口共用的（这点特别注意，防止程序端口冲突了），直接通过 127.0.0.1 就能连接上，剩下的就和直接使用 Linux 差不多了。

但是，等你重启电脑，再使用 Xshell 连接时发现连不上了，没有 sshd 进程了，每次都需要打开 WSL 程序然后再运行 sudo service ssh start 有点麻烦。这就是 WSL 不一样的地方了，WSL 不是真正的一个系统，没有开机启动这一说，把 sshd 设置成开机启动也没有用。既然不能加入到 WSL 的启动项，那就加入到 Windows 的启动项中：编写 run_wsl.vbs 脚本，用来在 bash.exe 中启动 sshd，然后将脚本放到系统启动目录里面（WIN+R 运行 shell:Common Startup 或者 shell:startup）就行了。

1 2	set ws=wscript.createobject("wscript.shell") ws.run "C:\Windows\System32\bash.exe -c 'sudo /usr/sbin/service ssh restart'",0

不过需要注意 sudo 需要输入密码，还得把密码关了。WSL 中运行 sudo visudo 增加一行：ubuntu ALL=(root) NOPASSWD: ALL，表示 ubuntu （换成自己的）这个用户使用 sudo 运行任何命令时都不用输入密码。当然安装之后可能会遇到一些其它问题，主要是一些安全软件和 WSL 不兼容，比如卡巴斯基会让 WSL 无法联网，腾讯的 TGP 会影响绑定端口，遇到了只能暂时关掉相关软件，相信之后这些问题会越来越少。

使用 Redis

之前在 Windows 上使用 Redis 比较麻烦，有一个 Windows 版的 Redis 但已经很久没有更新了，还有就是选择虚拟机。现在直接在 WSL 里面编译安装（make & make install）就行了。写好配置文件，sudo redis-server /etc/redis/redis.conf 运行即可。不过有些同学可能会像我之前把 Redis 注册为 systemd 服务，但发现会报错：System has not been booted with systemd as init system (PID 1). Can't operate 说的也比较明白，系统不是通过 systemd 启动的。其实 WSL 不是一个真正的系统，应该说是一个容器，类似 Docker（这么一说感觉微软野心好大）。

（图片来源：https://docs.microsoft.com/zh-cn/archive/blogs/wsl/windows-subsystem-for-linux-overview）在 WSL 中运行的程序是真正的 Linux 二进制文件，不是移植版，不过当程序由用户态切换到内核态时lxss.sys和lxcore.sys驱动将会将 Linux 的系统调用翻译为 NT APIs 来模拟 Linux 内核。简单来说 WSL 是将 LInux 底层 API 用 NT 实现了一遍（所以 WSL 中没有 Linux kernel 代码），而且有些操作还是 Linux 独有的，比如fork()，可想而知这里面工作量有多大，任重而道远。言归正传，Redis 已经在 WSL 中启动了，我们试试在 Windows 上能不能连上：

完美，就和 Windows 本地装的 Redis 一样。

与IDE集成

虽然说大部分语言都是跨平台的，但是还是有很多差别，比如 Python 的 epoll 只能在 Linux 下使用。在 Windows 上开发不是很方便，没有智能提示，还需要上传到服务器运行、调试。有了 WSL，现在可以在 Windows 上开发，然后直接在 WSL 里面运行。 Continue Reading...

本 Blog 不支持评论，如有疑问或建议请联系我，以完善内容，期望帮助到更多的同学