Go语言最大的特色就是从语言层面支持并发（Goroutine），Goroutine是Go中最基本的执行单元。事实上每一个Go程序至少有一个Goroutine：主Goroutine。当程序启动时，它会自动创建。

为了更好理解Goroutine，现讲一下线程和协程的概念

线程（Thread）：有时被称为轻量级进程(Lightweight Process，LWP），是程序执行流的最小单元。一个标准的线程由线程ID，当前指令指针(PC），寄存器集合和堆栈组成。另外，线程是进程中的一个实体，是被系统独立调度和分派的基本单位，线程自己不拥有系统资源，只拥有一点儿在运行中必不可少的资源，但它可与同属一个进程的其它线程共享进程所拥有的全部资源。

线程拥有自己独立的栈和共享的堆，共享堆，不共享栈，线程的切换一般也由操作系统调度。

协程（coroutine）：又称微线程与子例程（或者称为函数）一样，协程（coroutine）也是一种程序组件。相对子例程而言，协程更为一般和灵活，但在实践中使用没有子例程那样广泛。

和线程类似，共享堆，不共享栈，协程的切换一般由程序员在代码中显式控制。它避免了上下文切换的额外耗费，兼顾了多线程的优点，简化了高并发程序的复杂。

Goroutine和其他语言的协程（coroutine）在使用方式上类似，但从字面意义上来看不同（一个是Goroutine，一个是coroutine），再就是协程是一种协作任务控制机制，在最简单的意义上，协程不是并发的，而Goroutine支持并发的。因此Goroutine可以理解为一种Go语言的协程。同时它可以运行在一个或多个线程上。package main

import "fmt"

func main() {

messages := make(chan string)

go func() { messages <- "ping" }()

msg := <-messages
fmt.Println(msg)
}
先给个简单实例
func loop() {
for i := 0; i < ; i++ {
fmt.Printf("%d ", i)
}
}

func main() {
go loop() // 启动一个goroutine
loop()
}GO并发的实现原理

一、Go并发模型

Go实现了两种并发形式。第一种是大家普遍认知的：多线程共享内存。其实就是Java或者C++等语言中的多线程开发。另外一种是Go语言特有的，也是Go语言推荐的：CSP（communicating sequential processes）并发模型。

CSP并发模型是在1970年左右提出的概念，属于比较新的概念，不同于传统的多线程通过共享内存来通信，CSP讲究的是“以通信的方式来共享内存”。

请记住下面这句话：
DO NOT COMMUNICATE BY SHARING MEMORY; INSTEAD, SHARE MEMORY BY COMMUNICATING.
“不要以共享内存的方式来通信，相反，要通过通信来共享内存。”

普通的线程并发模型，就是像Java、C++、或者Python，他们线程间通信都是通过共享内存的方式来进行的。非常典型的方式就是，在访问共享数据（例如数组、Map、或者某个结构体或对象）的时候，通过锁来访问，因此，在很多时候，衍生出一种方便操作的数据结构，叫做“线程安全的数据结构”。例如Java提供的包”java.util.concurrent”中的数据结构。Go中也实现了传统的线程并发模型。

Go的CSP并发模型，是通过goroutine和channel来实现的。

goroutine 是Go语言中并发的执行单位。有点抽象，其实就是和传统概念上的”线程“类似，可以理解为”线程“。
channel是Go语言中各个并发结构体(goroutine)之前的通信机制。 通俗的讲，就是各个goroutine之间通信的”管道“，有点类似于Linux中的管道。

生成一个goroutine的方式非常的简单：Go一下，就生成了。
go f();通信机制channel也很方便，传数据用channel <- data，取数据用<-channel。

在通信过程中，传数据channel <- data和取数据<-channel必然会成对出现，因为这边传，那边取，两个goroutine之间才会实现通信。

而且不管传还是取，必阻塞，直到另外的goroutine传或者取为止。

示例如下：
package main

import "fmt"

func main() {

messages := make(chan string)

go func() { messages <- "ping" }()

msg := <-messages
fmt.Println(msg)
}注意 main()本身也是运行了一个goroutine。

messages:= make(chan int) 这样就声明了一个阻塞式的无缓冲的通道

chan 是关键字 代表我要创建一个通道。
 
GO并发模型的实现原理

我们先从线程讲起，无论语言层面何种并发模型，到了操作系统层面，一定是以线程的形态存在的。而操作系统根据资源访问权限的不同，体系架构可分为用户空间和内核空间；内核空间主要操作访问CPU资源、I/O资源、内存资源等硬件资源，为上层应用程序提供最基本的基础资源，用户空间呢就是上层应用程序的固定活动空间，用户空间不可以直接访问资源，必须通过“系统调用”、“库函数”或“Shell脚本”来调用内核空间提供的资源。

我们现在的计算机语言，可以狭义的认为是一种“软件”，它们中所谓的“线程”，往往是用户态的线程，和操作系统本身内核态的线程（简称KSE），还是有区别的。

线程模型的实现，可以分为以下几种方式：

用户级线程模型





 
如图所示，多个用户态的线程对应着一个内核线程，程序线程的创建、终止、切换或者同步等线程工作必须自身来完成。它可以做快速的上下文切换。缺点是不能有效利用多核CPU。
 
内核级线程模型





 
这种模型直接调用操作系统的内核线程，所有线程的创建、终止、切换、同步等操作，都由内核来完成。一个用户态的线程对应一个系统线程，它可以利用多核机制，但上下文切换需要消耗额外的资源。C++就是这种。
 
两级线程模型





 
这种模型是介于用户级线程模型和内核级线程模型之间的一种线程模型。这种模型的实现非常复杂，和内核级线程模型类似，一个进程中可以对应多个内核级线程，但是进程中的线程不和内核线程一一对应；这种线程模型会先创建多个内核级线程，然后用自身的用户级线程去对应创建的多个内核级线程，自身的用户级线程需要本身程序去调度，内核级的线程交给操作系统内核去调度。

M个用户线程对应N个系统线程，缺点增加了调度器的实现难度。

Go语言的线程模型就是一种特殊的两级线程模型（GPM调度模型）。
 
Go线程实现模型MPG
 
M指的是Machine，一个M直接关联了一个内核线程。由操作系统管理。
P指的是”processor”，代表了M所需的上下文环境，也是处理用户级代码逻辑的处理器。它负责衔接M和G的调度上下文，将等待执行的G与M对接。
G指的是Goroutine，其实本质上也是一种轻量级的线程。包括了调用栈，重要的调度信息，例如channel等。

P的数量由环境变量中的GOMAXPROCS决定，通常来说它是和核心数对应，例如在4Core的服务器上回启动4个线程。G会有很多个，每个P会将Goroutine从一个就绪的队列中做Pop操作，为了减小锁的竞争，通常情况下每个P会负责一个队列。

三者关系如下图所示：





 
以上这个图讲的是两个线程(内核线程)的情况。一个M会对应一个内核线程，一个M也会连接一个上下文P，一个上下文P相当于一个“处理器”，一个上下文连接一个或者多个Goroutine。为了运行goroutine，线程必须保存上下文。

上下文P(Processor)的数量在启动时设置为GOMAXPROCS环境变量的值或通过运行时函数GOMAXPROCS()。通常情况下，在程序执行期间不会更改。上下文数量固定意味着只有固定数量的线程在任何时候运行Go代码。我们可以使用它来调整Go进程到个人计算机的调用，例如4核PC在4个线程上运行Go代码。

图中P正在执行的Goroutine为蓝色的；处于待执行状态的Goroutine为灰色的，灰色的Goroutine形成了一个队列runqueues。

Go语言里，启动一个goroutine很容易：go function 就行，所以每有一个go语句被执行，runqueue队列就在其末尾加入一个goroutine，一旦上下文运行goroutine直到调度点，它会从其runqueue中弹出goroutine，设置堆栈和指令指针并开始运行goroutine。





 
抛弃P(Processor)

你可能会想，为什么一定需要一个上下文，我们能不能直接除去上下文，让Goroutine的runqueues挂到M上呢？答案是不行，需要上下文的目的，是让我们可以直接放开其他线程，当遇到内核线程阻塞的时候。

一个很简单的例子就是系统调用sysall，一个线程肯定不能同时执行代码和系统调用被阻塞，这个时候，此线程M需要放弃当前的上下文环境P，以便可以让其他的Goroutine被调度执行。





 
如上图左图所示，M0中的G0执行了syscall，然后就创建了一个M1(也有可能来自线程缓存)，（转向右图）然后M0丢弃了P，等待syscall的返回值，M1接受了P，将·继续执行Goroutine队列中的其他Goroutine。

当系统调用syscall结束后，M0会“偷”一个上下文，如果不成功，M0就把它的Gouroutine G0放到一个全局的runqueue中，将自己置于线程缓存中并进入休眠状态。全局runqueue是各个P在运行完自己的本地的Goroutine runqueue后用来拉取新goroutine的地方。P也会周期性的检查这个全局runqueue上的goroutine，否则，全局runqueue上的goroutines可能得不到执行而饿死。

均衡的分配工作

按照以上的说法，上下文P会定期的检查全局的goroutine 队列中的goroutine，以便自己在消费掉自身Goroutine队列的时候有事可做。假如全局goroutine队列中的goroutine也没了呢？就从其他运行的中的P的runqueue里偷。

每个P中的Goroutine不同导致他们运行的效率和时间也不同，在一个有很多P和M的环境中，不能让一个P跑完自身的Goroutine就没事可做了，因为或许其他的P有很长的goroutine队列要跑，得需要均衡。
该如何解决呢？

Go的做法倒也直接，从其他P中偷一半！





 
Goroutine 小结

优点：

1、开销小

POSIX的thread API虽然能够提供丰富的API，例如配置自己的CPU亲和性，申请资源等等，线程在得到了很多与进程相同的控制权的同时，开销也非常的大，在Goroutine中则不需这些额外的开销，所以一个Golang的程序中可以支持10w级别的Goroutine。

每个 goroutine (协程) 默认占用内存远比 Java 、C 的线程少（goroutine：2KB ，线程：8MB）

2、调度性能好

在Golang的程序中，操作系统级别的线程调度，通常不会做出合适的调度决策。例如在GC时，内存必须要达到一个一致的状态。在Goroutine机制里，Golang可以控制Goroutine的调度，从而在一个合适的时间进行GC。

在应用层模拟的线程，它避免了上下文切换的额外耗费，兼顾了多线程的优点。简化了高并发程序的复杂度。

缺点：

协程调度机制无法实现公平调度。
 
参考文档：https://segmentfault.com/a/1190000018150987 查看全部

package main



import "fmt"



func main() {

   

   messages := make(chan string)



   go func() { messages <- "ping" }()



   msg := <-messages

   fmt.Println(msg)

}

func loop() {

    for i := 0; i < ; i++ {

        fmt.Printf("%d ", i)

    }

}



func main() {

   go loop() // 启动一个goroutine

    loop()

}

go f();

package main



import "fmt"



func main() {

   

   messages := make(chan string)



   go func() { messages <- "ping" }()



   msg := <-messages

   fmt.Println(msg)

}

多字段搜索(Multifield Search)

查询很少是只拥有一个match查询子句的查询。我们经常需要对一个或者多个字段使用相同或者不同的查询字符串进行搜索，这意味着我们需要将多个查询子句和它们得到的相关度分值以一种有意义的方式进行合并。

也许我们正在寻找一本名为战争与和平的书，它的作者是Leo Tolstoy。也许我们正在使用"最少应该匹配(Minimum Should Match)"来搜索ES中的文档。另外我们也可能会寻找拥有名为John而姓为Smith的用户。

在本章中我们会讨论一些构建多字段搜索的工具，以及如何根据你的实际情况来决定使用哪种方案。

多个查询字符串(Multiple Query Strings)

处理字段查询最简单的方法是将搜索词条对应到特定的字段上。如果我们知道战争与和平是标题，而Leo Tolstoy是作者，那么我们可以简单地将每个条件当做一个match子句，然后通过bool查询将它们合并：
GET /_search
{
"query": {
"bool": {
"should": [
{ "match": { "title": "War and Peace" }},
{ "match": { "author": "Leo Tolstoy" }}
]
}
}
}bool查询采用了一种"匹配越多越好(More-matches-is-better)"的方法，因此每个match子句的分值会被累加来得到文档最终的_score。匹配两个子句的文档相比那些只匹配一个子句的文档的分值会高一些。

当然，你并不是只能使用match子句：bool查询可以包含任何其他类型的查询，包括其它的bool查询。我们可以添加一个子句来指定我们希望的译者：
GET /_search
{
"query": {
"bool": {
"should": [
{ "match": { "title": "War and Peace" }},
{ "match": { "author": "Leo Tolstoy" }},
{ "bool": {
"should": [
{ "match": { "translator": "Constance Garnett" }},
{ "match": { "translator": "Louise Maude" }}
]
}}
]
}
}
}我们为什么将译者的查询子句放在一个单独的bool查询中？所有的4个match查询都是should子句，那么为何不将译者的查询子句和标题及作者的查询子句放在同一层次上呢？

答案在于分值是如何计算的。bool查询会运行每个match查询，将它们的分值相加，然后乘以匹配的查询子句的数量，最后除以所有查询子句的数量。相同层次的每个子句都拥有相同的权重。在上述查询中，bool查询中包含的译者查询子句只占了总分值的三分之一。如果我们将译者查询子句放到和标题及作者相同的层次上，就会减少标题和作者子句的权重，让它们各自只占四分之一。

设置子句优先级

上述查询中每个子句占有三分之一的权重也许并不是我们需要的。相比译者字段，我们可能对标题和作者字段更有兴趣。我们对查询进行调整来让标题和作者相对更重要。

在所有可用措施中，我们可以采用的最简单的方法是boost参数。为了增加title和author字段的权重，我们可以给它们一个大于1的boost值：GET /_search
{
"query": {
"bool": {
"should": [
{ "match": {
"title": {
"query": "War and Peace",
"boost": 2
}}},
{ "match": {
"author": {
"query": "Leo Tolstoy",
"boost": 2
}}},
{ "bool": {
"should": [
{ "match": { "translator": "Constance Garnett" }},
{ "match": { "translator": "Louise Maude" }}
]
}}
]
}
}
}以上的title和k字段的boost值为2。 嵌套的bool查询自居的默认boost值为k。

通过试错(Trial and Error)的方式可以确定"最佳"的boost值：设置一个boost值，执行测试查询，重复这个过程。一个合理boost值的范围在1和10之间，也可能是15。比它更高的值的影响不会起到很大的作用，因为分值会被规范化(Normalized)。

单一查询字符串(Single Query String)

bool查询是多字段查询的中流砥柱。在很多场合下它都能很好地工作，特别是当你能够将不同的查询字符串映射到不同的字段时。

问题在于，现在的用户期望能够在一个地方输入所有的搜索词条，然后应用能够知道如何为他们得到正确的结果。所以当我们把含有多个字段的搜索表单称为高级搜索(Advanced Search)时，是有一些讽刺意味的。高级搜索虽然对用户而言会显得更"高级"，但是实际上它的实现方式更简单。

对于多词，多字段查询并没有一种万能的方法。要得到最佳的结果，你需要了解你的数据以及如何使用恰当的工具。

了解你的数据

当用户的唯一输入就是一个查询字符串时，你会经常碰到以下三种情况：

最佳字段(Best fields)

当搜索代表某些概念的单词时，例如"brown fox"，几个单词合在一起表达出来的意思比单独的单词更多。类似title和body的字段，尽管它们是相关联的，但是也是互相竞争着的。文档在相同的字段中应该有尽可能多的单词(译注：搜索的目标单词)，文档的分数应该来自拥有最佳匹配的字段。

多数字段(Most fields)

一个用来调优相关度的常用技术是将相同的数据索引到多个字段中，每个字段拥有自己的分析链(Analysis Chain)。

主要字段会含有单词的词干部分，同义词和消除了变音符号的单词。它用来尽可能多地匹配文档。

相同的文本可以被索引到其它的字段中来提供更加精确的匹配。一个字段或许会包含未被提取词干的单词，另一个字段是包含了变音符号的单词，第三个字段则使用shingle来提供关于单词邻近度(Word Proximity)的信息。

以上这些额外的字段扮演者signal的角色，用来增加每个匹配的文档的相关度分值。越多的字段被匹配则意味着文档的相关度越高。

跨字段(Cross fields)

对于一些实体，标识信息会在多个字段中出现，每个字段中只含有一部分信息：
 
Person：first_name 和 last_nameBook：title，author 和 descriptionAddress：street，city，country 和 postcode

此时，我们希望在任意字段中找到尽可能多的单词。我们需要在多个字段中进行查询，就好像这些字段是一个字段那样。

以上这些都是多词，多字段查询，但是每种都需要使用不同的策略。我们会在本章剩下的部分解释每种策略。 查看全部

GET /_search

{

  "query": {

    "bool": {

      "should": [

        { "match": { "title":  "War and Peace" }},

        { "match": { "author": "Leo Tolstoy"   }}

      ]

    }

  }

}

GET /_search

{

  "query": {

    "bool": {

      "should": [

        { "match": { "title":  "War and Peace" }},

        { "match": { "author": "Leo Tolstoy"   }},

        { "bool":  {

          "should": [

            { "match": { "translator": "Constance Garnett" }},

            { "match": { "translator": "Louise Maude"      }}

          ]

        }}

      ]

    }

  }

}

GET /_search

{

  "query": {

    "bool": {

      "should": [

        { "match": { 

            "title":  {

              "query": "War and Peace",

              "boost": 2

        }}},

        { "match": { 

            "author":  {

              "query": "Leo Tolstoy",

              "boost": 2

        }}},

        { "bool":  { 

            "should": [

              { "match": { "translator": "Constance Garnett" }},

              { "match": { "translator": "Louise Maude"      }}

            ]

        }}

      ]

    }

  }

}

一、term、terms查询（精确查询）
 
term query会去倒排索引中寻找确切的term，它并不知道分词器的存在，这种查询适合keyword、numeric、date等明确值的

term：查询某个字段里含有某个关键词的文档GET /customer/doc/_search/
{
"query": {
"term": {
"title": "blog"
}
}
}terms：查询某个字段里含有多个关键词的文档
GET /customer/doc/_search/
{
"query": {
"terms": {
"title": [ "blog","first"]
}
}
}
二、match查询（模糊查询）

match query 知道分词器的存在，会对field进行分词操作，然后再查询。GET /customer/doc/_search/
{
"query": {
"match": {
"title": "my ss" #它和term区别可以理解为term是精确查询，这边match模糊查询；match会对my ss分词为两个单词，然后term对认为这是一个单词
}
}
}match_all：查询所有文档
GET /customer/doc/_search/
{
"query": {
"match_all": {}
}
}multi_match：可以指定多个字段
GET /customer/doc/_search/
{
"query": {
"multi_match": {
"query" : "blog",
"fields": ["name","title"] #只要里面一个字段包含值 blog 既可以
}
}
}
 三、match_phrase：短语匹配查询

ES引擎首先分析查询字符串，从分析后的文本中构建短语查询，这意味着必须匹配短语中的所有分词，并且保证各个分词的相对位置不变

_source：当我们希望返回结果只是一部分字段时，可以加上_source
GET /customer/doc/_search/
{
"_source":["title"], #只返回title字段
"query": {
"match_all": {}
}
}
 四、排序

使用sort实现排序（类似sql）：desc 降序，asc升序

fuzzy实现模糊查询

value：查询的关键字

boost：查询的权值，默认值是1.0

min_similarity：设置匹配的最小相似度，默认值0.5，对于字符串，取值0-1(包括0和1)；对于数值，取值可能大于1；对于日期取值为1d,1m等，1d等于1天

prefix_length：指明区分词项的共同前缀长度，默认是0GET /customer/doc/_search/
{

"query": {
"fuzzy": {
"name": {
"value": "blg"
}
}
}
}

#返回：
{
"took": 8,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 1,
"max_score": 0.19178805,
"hits": [
{
"_index": "customer",
"_type": "doc",
"_id": "1",
"_score": 0.19178805,
"_source": {
"name": "blog",
"tags": [
"testing"
],
"title": "i am a doc"
}
}
]
}
} 查看全部

GET /customer/doc/_search/

{

  "query": {

    "term": {

      "title":   "blog"

    }

  }

}

GET /customer/doc/_search/

{

  "query": {

    "terms": {

      "title":  [ "blog","first"]

    }

  }

}

GET /customer/doc/_search/

{

  "query": {

    "match": {

      "title":  "my ss"   #它和term区别可以理解为term是精确查询，这边match模糊查询；match会对my ss分词为两个单词，然后term对认为这是一个单词

    }

  }

}

GET /customer/doc/_search/

{

  "query": {

    "match_all": {}

  }

}

GET /customer/doc/_search/

{

  "query": {

    "multi_match": {

      "query" : "blog",

      "fields":  ["name","title"]   #只要里面一个字段包含值 blog 既可以

    }

  }

}

GET /customer/doc/_search/

{

  "_source":["title"],  #只返回title字段

  "query": {

    "match_all": {}

  }

}

GET /customer/doc/_search/

{

   

  "query": {

    "fuzzy": {

      "name": {

        "value": "blg"

      }

    }

  } 

}



#返回：

{

  "took": 8,

  "timed_out": false,

  "_shards": {

    "total": 5,

    "successful": 5,

    "skipped": 0,

    "failed": 0

  },

  "hits": {

    "total": 1,

    "max_score": 0.19178805,

    "hits": [

      {

        "_index": "customer",

        "_type": "doc",

        "_id": "1",

        "_score": 0.19178805,

        "_source": {

          "name": "blog",

          "tags": [

            "testing"

          ],

          "title": "i am a doc"

        }

      }

    ]

  }

}

《美团机器学习》读书打卡 - 第一部分通用流程总结脑图如下：

向量空间（Vector Space Model）提供比较多术语查询的一种方式，单个分数代表文档与查询的匹配程度，为了做到这点，这个模型将文档和查询都以向量的形式表示：

一个向量实际上就是包含很多数字的一个一维数组，例如：
[1,2,5,22,3,8]在向量空间模型里，向量里的每个数字都代表一个术语的权重，和TF/IDF计算方式类似。

尽管 TF/IDF 是向量空间模型计算术语权重的默认方式，但不是唯一的方式，ElasticSearch还有其他模型（如：Okapi-BM25）。TF/IDF是默认的因为它是个经检验过的简单、高效算法，可以提供高质量的搜索结果。

如果我们有查询“happy hippopotamus”，常见词 happy 的权重较低，不常见词 hippopotamus 权重较高，假设 happy的权重是2，hippopotamus 的权重是5，我们可以将这个二维向量——[2,5]——在坐标系下作条直线，线起于(0,0)点终于(2,5)点：





 
现在，假想我们有三个文档：
 
I am happy in summer.After Christmas I'm a hippopotamus.The happy hippopotamus helped Harry.

我们可以为每个文档都创建一个包括每个查询术语（happy 和 hippopotamus）权重的向量，然后将这些向量置入同一个坐标系中： 
文档 1：（happy，____________）——[2,0]文档 2：（_____，hippopotamus）——[0,5]文档 3：（happy，hippopotamus）——[2,5]

向量之间是可以比较的，只需要测量查询向量和文档向量之间的角度就可以得到每个文档的相关度，文档1与查询之间的角度最大，所以相关度低；文档2与查询间的角度较小，所以更相关；文档3与查询的角度正好吻合，完全匹配。

在实际中，只有二维向量（两个术语的查询）可以在平面上表示，幸运的是，线性代数——作为数学中处理向量的一个分支——为我们提供了计算两个多维向量间角度工具，这意味着我们可以使用如上同样的方式来解释多个术语的查询。

关于比较两个向量的更多信息可以在 余弦近似度（cosine similarity） 中看到

现在我们讨论了分数计算的基本理论，我们可以继续了解Lucene是如何实现分数计算的。 查看全部

[1,2,5,22,3,8]