问题描述 使用 Pandas 的 read_excel 方法读取一个 16 万行的 Excel 文件报 AssertionError 错误： "/Users/XXX/excel_test/venv/lib/python3.7/site-packages/xlrd/xlsx.py", line 637, in do_row assert 0 <= self.rowx < X12_MAX_ROWS AssertionError 背后原理 Excel 文件有两种默认格式，在 Excel 2007 以前，使用扩展名为 .xls 格式的文件，这种文件格式是一种特定的二进制格式，最多支持 65,536 行（在 Excel 97 之前支持的最大行数是 16,384），256 列表格。从 Excel 2007 版开始，默认采用了基于 XML 的新的文件格式 .xlsx，支持的表格行数达到了 1,048,576，列数达到了 16,384。需要注意的是，将 .xlsx 格式的文件转换为 .xls 格式的文件时，65,536 行和 256 列之后的数据都会被丢弃。 版本 最大行数 最大列数 文件格式 Excel 97 之前 16,384 256 .xls Excel 97 到 Excel 2003 65,536 256 .xls Excel 2007 及以后版本 1,048,576 16,384 .xlsx Pandas 读取 Excel 文件的引擎是 xlrd，xlrd 在读取 Excel 文件时，xlrd/xlsx.py 文件的 637 行会对行号做断言，判断行号是否在 0 - 1,048,576（Excel支持的最大行数） 的范围内。这段代码是这样的： ...

问题描述 在使用 docker build 打包镜像时，遇到了需要使用代理访问网络的需求。使用如下的 Dockerfile 来模拟这个场景： FROM golang:1.12 RUN curl www.google.com --max-time 3 国内一般网络环境下，curl www.google.com 是无法正常返回的，加入 –max-time 让 curl 的耗时不要太长。 配置 http_proxy 变量 首先需要在环境变量中设置 http_proxy 和 https_proxy，使得访问网络的命令（这里使用 curl 来代表）能够通过环境变量中配置的代理服务器访问 www.google.com。 docker build 命令虽然是在 docker 所在的宿主机上执行的，看上去像是直接使用了宿主机的网络环境，但实际上 docker build 也是启动了一个 container 进行构建，所以在构建过程中的所有命令都是在 container 中执行的，http_proxy 和 https_proxy 的配置也应该是在 container 中进行的。可以使用 ENV 来配置 container 中的环境变量。 代理服务器启动在宿主机的 1087 端口上，修改 dockerfile 文件： FROM golang:1.12 ENV http_proxy "http://127.0.0.1:1087" ENV HTTP_PROXY "http://127.0.0.1:1087" ENV https_proxy "http://127.0.0.1:1087" ENV HTTPS_PROXY "http://127.0.0.1:1087" RUN curl www.google.com --max-time 3 重新执行 docker build 会发现 curl 依旧无法访问 www.google.com，从报错信息上可以看到 127.0.0.1 上的 1087 端口上并没有服务。 ...

关于 count 函数的使用一直存在争议，尤其是在 MySQL 中，作为流行度越来越高的 PostgreSQL 是否也有类似的问题呢，我们通过实践来理解一下 PostgreSQL 中 count 函数的行为。 构建测试数据库 创建测试数据库，并创建测试表。测试表中有自增 ID、创建时间、内容三个字段，自增 ID 字段是主键。 create database performance_test; create table test_tbl (id serial primary key, created_at timestamp, content varchar(512)); 生成测试数据 使用 generate_series 函数生成自增 ID，使用 now() 函数生成 created_at 列，对于 content 列，使用了 repeat(md5(random()::text), 10) 生成 10 个 32 位长度的 md5 字符串。使用下列语句，插入 1000w 条记录用于测试。 performance_test=# insert into test_tbl select generate_series(1,10000000),now(),repeat(md5(random()::text),10); INSERT 0 10000000 Time: 212184.223 ms (03:32.184) 由 count 语句引发的思考 默认情况下 PostgreSQL 不开启 SQL 执行时间的显示，所以需要手动开启一下，方便后面的测试对比。 \timing on count(*) 和 count(1) 的性能区别是经常被讨论的问题，分别使用 count(*) 和 count(1) 执行一次查询。 ...

现象 刚签发的 JWT，在下一个请求使用时候会失效，请求会报 422 错误。 { "msg": "The token is not yet valid (nbf)" } 如果隔几秒再请求（例如使用 Chrome 开发者工具中的 Replay XHR），就会成功。 nbf 字段的原理 查看上面的报错信息，会发现有一个 nbf，nbf 是 JWT 协议中的一个字段，是 Not Before 的缩写，表示 JWT Token 在这个时间之前是无效的，一般来讲会设置成签发的时间。这里产生了一个猜想，多服务器环境时候，服务器之间时间如果不一致，一台服务器签发的 token 如果立刻被发往另一台服务器验证，就很容易产生 nbf 字段验证不通过的问题。其实 JWT 协议已经考虑到了这类问题，所以协议中在 nbf 这一节专门提到了可以使用一个 small leeway 来解决这个问题。 4.1.5. “nbf” (Not Before) Claim The “nbf” (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. The processing of the “nbf” claim requires that the current date/time MUST be after or equal to the not-before date/time listed in the “nbf” claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL. ...

在基于 Kubernetes 部署，使用 Gunicorn 运行的 Python Web 应用中，上传大文件时出现了一系列的错误，现在将解决问题的思路记录如下。 文件上传过程 上传文件流程 上传的文件首先到达 Kubernetes 所在的宿主机。 宿主机上的 Nginx 通过 Proxy 转发给 Kubernetes 集群中的 Ingress Controller，Ingress controller 也是使用 Nginx 实现的。 Ingress Controller 中的 Nginx 通过 Proxy 转发给 Gunicorn。 Gunicorn 会启动若干个 Worker 处理请求，所以 Gunicorn 会再转发给 Worker。 Worker 就是最终的 Python Web App 错误 413 的解决 首先碰到的是 413 Request Entity Too Large 错误，在上传过程中连接被中断（基本上每次都是相同的上传百分比被中断），请求返回 413，首先考虑到 Nginx 对于请求体的大小有限制，查看 Nginx 文档，发现 client_max_body_size 参数控制请求体的大小，默认的设置是 1mb。 client_max_body_size: Sets the maximum allowed size of the client request body, specified in the “Content-Length” request header field. If the size in a request exceeds the configured value, the 413 (Request Entity Too Large) error is returned to the client. Please be aware that browsers cannot correctly display this error. Setting size to 0 disables checking of client request body size. ...