小菜鸟

阿富汗

阿富汗比较惨，经历了多个国家多轮的洗礼

北邻土库曼斯坦、乌兹别克斯坦、塔吉克斯坦，西接伊朗，南部和东部连巴基斯坦，东北部凸出的狭长地带与中国接壤 [8] ，国土面积64.75万平方千米，首都喀布尔

地图

第一轮：英国

巴基斯坦与阿富汗原本是英国的殖民地，英国划定了一条“杜兰线”，作为两国的界限，同时也将普什图人一分为二

1919年，阿富汗和英国爆发战争来进行独立，但是由于那条线导致了后期的种族冲突

第二轮：苏联

苏联-阿富汗战争，是1979年12月末苏联入侵阿富汗导致的长达10年的战争，瞬间占领了城镇，但是后续九年被山地游击战拖垮了

第三轮：美国

以美国为首的联军在2001年10月7日起对“基地”组织和塔利班的一场战争，该战争是美国对9·11事件的报复，一直拖到了21年，征战20年

阿富汗矿藏资源较为丰富，但未得到充分开发。截至2021年9月，阿富汗伊斯兰共和国已探明的资源主要有天然气、煤、盐、铬、铁、铜、云母及绿宝石等。位于首都喀布尔南部的埃纳克铜矿已探明矿石总储量约7亿吨，铜金属总量达1133万吨。据估计可能是世界第三大铜矿带。阿富汗还可能拥有全球第五大铁矿脉，煤储量约7300万吨

如果可以和中国合作，直接从阿富汗走铁路将矿产资源输送到中国，将可以解决国内的很大的资源进口缺口。且阿富汗还有很多的稀土矿，中国想要减少国内的稀土出口，阿富汗的稀土是一个不错的选择

Nginx 防盗链配置：通过 Referer 验证保护资源

防盗链是防止其他网站非法引用本网站资源（如图片、视频、CSS）的技术手段，Nginx 通过valid_referers指令检查请求的Referer头，识别非法来源并拒绝访问，从而节省带宽、保护知识产权。本文详细讲解 Nginx 防盗链的配置方法、参数含义及实战案例。

防盗链原理：基于 Referer 头验证

• Referer 头：客户端请求资源时，HTTP 协议会在请求头中包含Referer字段，记录请求的来源页面 URL（如https://example.com/page.html引用了https://yourdomain.com/image.jpg，则Referer为https://example.com/page.html）。
• 防盗链逻辑：Nginx 通过valid_referers定义 “合法来源”，若请求的Referer不在合法列表中，则判定为盗链，返回 403 Forbidden。

基础配置示例

server {
    listen 80;
    server_name yourdomain.com;
    root /var/www;

    # 对图片、视频等静态资源启用防盗链
    location ~* \.(jpg|jpeg|png|gif|mp4|css|js)$ {
        # 定义合法的Referer来源
        valid_referers 
            none  # 允许无Referer的请求（如直接在浏览器输入URL访问）
            blocked  # 允许Referer被防火墙或代理隐藏的请求
            server_names  # 允许来自本域名的请求（yourdomain.com及其子域名）
            *.yourdomain.com  # 允许指定域名及其子域名
            *.trusted-site.com;  # 允许信任的第三方网站

        # 若Referer不合法，则返回403
        if ($invalid_referer) {
            return 403;
            # 可选：返回自定义图片（如“盗链必究”提示图）
            # rewrite ^/ /forbidden.png last;
        }
    }
}

valid_referers参数详解

valid_referers用于定义 “合法来源”，支持多种格式：

Elasticsearch 事务日志（Translog）：数据安全与持久化的核心保障

Elasticsearch 基于 Lucene 构建，而 Lucene 采用 “延迟写” 策略（数据先存内存，再批量刷盘）提升性能，但存在内存数据丢失风险。事务日志（Translog） 作为 Elasticsearch 的核心组件，通过记录所有未持久化的操作，确保在节点故障时数据可恢复，是数据安全的关键保障。

事务日志的核心作用

1. 数据恢复：记录所有未写入磁盘的索引操作（新增、更新、删除），节点重启后可通过 Translog 恢复内存中丢失的数据。
2. 持久化辅助：配合 Lucene 的段（Segment）机制，平衡写入性能与数据安全性。
3. 原子性保障：确保每个操作要么完全成功（写入 Translog 并同步到段），要么失败时可回滚。

数据写入与 Translog 交互流程

数据从写入到持久化的完整流程如下，Translog 贯穿始终：

初始写入：内存缓冲 + Translog 记录

• 文档写入时，先进入 Memory Buffer（内存缓冲区，JVM 堆内存）。
• 同时，操作被追加到 Translog（磁盘文件），确保即使节点崩溃，操作也不会丢失。
• 此时状态：数据不可搜索（未进入倒排索引），但已通过 Translog 持久化，安全性得到保障。

准实时可见：Refresh 操作

默认每隔 index.refresh_interval（1 秒）触发 Refresh：

Elasticsearch 二次评分（Rescore）：优化顶部结果相关性

在 Elasticsearch 中，当基础查询返回的顶部文档相关性不够理想时，可通过二次评分（Rescore） 机制对前 N 个文档重新计算得分，进一步优化排序。这种方式既能保证查询效率（仅处理顶部文档），又能提升关键结果的准确性，适用于需要精细调整排序的场景（如搜索引擎结果页 Top 10 优化）。

二次评分的核心原理

二次评分的工作流程如下：

1. 基础查询：执行初始查询（如 match、bool），获取匹配文档并按得分排序。
2. 筛选顶部文档：从每个分片的结果中选取前 window_size 个文档（默认取 from + size 个）。
3. 重新评分：对这些顶部文档应用二次评分查询（如 function_score、script_score），计算新得分。
4. 合并结果：根据配置的评分模式（如求和、相乘）合并原始得分与二次评分，得到最终排序。

基础语法与示例

基本结构

GET index/_search
{
  "query": {  // 1. 基础查询
    "match": { "title": "elasticsearch" }
  },
  "rescore": {  // 2. 二次评分配置
    "window_size": 50,  // 每个分片取前50个文档进行二次评分
    "query": {
      "rescore_query": {  // 二次评分查询
        "function_score": {
          "script_score": {
            "script": "doc['publishTime'].value / 1000000"  // 以发布时间作为加分项
          }
        }
      },
      "query_weight": 0.8,  // 原始得分权重
      "rescore_query_weight": 0.2  // 二次评分权重
    }
  },
  "size": 10  // 最终返回10条结果
}

得分计算逻辑

最终得分由原始查询得分和二次评分按权重合并：

Elasticsearch 中的查询（Query）与过滤（Filter）：核心区别与应用场景

在 Elasticsearch 中，查询（Query）和过滤（Filter）是两种核心的数据筛选机制，虽然都能实现结果筛选，但在用途、性能和实现方式上有本质区别。理解二者的差异是优化查询性能和相关性的关键。

核心区别

查询（Query）：注重相关性

查询操作不仅会筛选出符合条件的文档，还会根据文档与查询条件的匹配程度计算相关性得分（_score），得分越高，文档与查询的相关性越强。

常用查询类型

• 全文查询：match、match_phrase（用于文本字段，会分词）。
• 术语查询：term、terms（用于精确匹配，如关键词、数字）。
• 复合查询：bool、dis_max（组合多个查询条件）。

示例：匹配 “elasticsearch 教程” 并计算得分

GET books/_search
{
  "query": {
    "match": {
      "title": "elasticsearch 教程"  // 全文匹配，计算得分
    }
  }
}