构造请求日志分析系统

请求日志记录哪些数据

• time_local : 请求的时间
• remote_addr : 客户端的 IP 地址
• request_method : 请求方法
• request_schema : 请求协议，常见的 http 和 https
• request_host : 请求的域名
• request_path : 请求的 path 路径
• request_query : 请求的 query 参数
• request_size : 请求的大小
• referer : 请求来源地址，假设你在 a.com 网站下贴了 b.com 的链接，那么当用户从 a.com 点击访问 b.com 的时候，referer 记录的就是 a.com ，这个是浏览器的行为
• user_agent : 客户端浏览器相关信息
• status : 请求的响应状态
• request_time : 请求的耗时
• bytes_sent : 响应的大小

很多时候我们会使用负载网关去代理转发请求给实际的后端服务，这时候请求日志还会包括以下数据：

Elasticsearch 自定义打分 Function score query

Elasticsearch 会为 query 的每个文档计算一个相关度得分 score ，并默认按照 score 从高到低的顺序返回搜索结果。 在很多场景下，我们不仅需要搜索到匹配的结果，还需要能够按照某种方式对搜索结果重新打分排序。例如：

Logstash 入门

Logstash 是什么

Logstash 就是一个开源的数据流工具，它会做三件事：

1. 从数据源拉取数据
2. 对数据进行过滤、转换等处理
3. 将处理后的数据写入目标地

例如：

• 监听某个目录下的日志文件，读取文件内容，处理数据，写入 influxdb 。
• 从 kafka 中消费消息，处理数据，写入 elasticsearch 。

为什么要用 Logstash ？

方便省事。

又拍图片管家亿级图像之搜图系统的两代演进及底层原理

前言

又拍图片管家当前服务了千万级用户，管理了百亿级图片。当用户的图库变得越来越庞大时，业务上急切的需要一种方案能够快速定位图像，即直接输入图像，然后根据输入的图像内容来找到图库中的原图及相似图，而以图搜图服务就是为了解决这个问题。

以图搜图系统工程实践

之前写过一篇概述: 以图搜图系统概述 。

以图搜图系统需要解决的主要问题是：

• 提取图像特征向量（用特征向量去表示一幅图像）
• 特征向量的相似度计算（寻找内容相似的图像）

对应的工程实践，具体为：

以图搜图系统概述

以图搜图指的是根据图像内容搜索出相似内容的图像。

构建一个以图搜图系统需要解决两个最关键的问题：首先，提取图像特征；其次，特征数据搜索引擎，即特征数据构建成数据库并提供相似性搜索的功能。

GitHub Actions 指南

GitHub Actions 使你可以直接在你的 GitHub 库中创建自定义的工作流，工作流指的就是自动化的流程，比如构建、测试、打包、发布、部署等等，也就是说你可以直接进行 CI（持续集成）和 CD （持续部署）。

给库加上酷炫的小徽章 & ava、codecov、travis 示例

GitHub 很多开源库都会有几个酷炫的小徽章，比如：

使用 Makefile 构建指令集

make 是一个历史悠久的构建工具，通过配置 Makefile 文件就可以很方便的使用你自己自定义的各种指令集，且与具体的编程语言无关。 例如配置如下的 Makefile :

实现 memcached 客户端：TCP、连接池、一致性哈希、自定义协议。

废话不多说，文本将带你实现一个简单的 memcached 客户端。

集群：一致性哈希

memcached 本身并不支持集群，为了使用集群，我们可以自己在客户端实现路由分发，将相同的 key 路由到同一台 memcached 上去即可。 路由算法有很多，这里我们使用一致性哈希算法。