同時実行性の高いシナリオでは、システムのプレッシャーを軽減するために、要求をキューに入れるメカニズムが使用されます。この記事では、Goでの実装方法について説明します。
まず、httpリクエストの順次処理方法
まず、通常のリクエスト処理ロジックを見てみましょう。クライアントはリクエストを送信し、Webサーバーはリクエストを受信し、次にリクエストを処理し、最後にそのようなシーケンシャルロジックでクライアントに応答します。以下に示すように：
コードは次のように実装されます。
package main
import (
"fmt"
"net/http"
)
func main() {
myHandler := MyHandler{}
http.Handle("/", &myHandler)
http.ListenAndServe(":8080", nil)
}
type MyHandler struct {
}
func (h *MyHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("Hello Go"))
}
ブラウザにhttp：// localhost：8080 /と入力して、ページに「 HelloGo」ページを表示します。
通常の状況では、人々がWebシステムを開発するとき、彼らは一般的にこの方法で要求を処理します。次に、高い同時実行性でリクエストをキューに入れる方法を見てみましょう。
2.httpリクエストの非同期処理-キューイング処理
httpリクエストをキューに入れます。これを非同期処理とも呼びます。基本的な考え方は、受信した要求（つまり、要求と応答）と処理ロジックのコンテキストを作業単位にパッケージ化し、それをキューに入れて、作業単位が消費ワーカースレッドが処理するのを待つことです。ジョブが完了すると、処理が完了します。クライアントに返されます。プロセスは次のとおりです。
この実装には、作業実行ユニット、キュー、およびコンシューマーという3つの重要な要素があります。それぞれの責任と実装を1つずつ見ていきましょう。
作業単位
作業単位は、主に要求のコンテキスト情報（要求と応答）、要求の処理ロジック、および作業単位が実行されたかどうかのステータスをカプセル化します。
リクエストの処理ロジックは、実際には元の順次処理プロセスの特定の機能です。mvcモードの場合は、コントローラーの特定のアクションです。
Goで通信を実装する方法は、通常、チャネルを使用することです。したがって、ワークユニットにはチャネルがあります。ワークユニットが特定の処理ロジックを実行した後、メッセージがチャネルに書き込まれ、要求が完了してクライアントに返されることをメインコルーチンに通知します。
したがって、httpリクエストの処理ロジックは次のようになります。
func (h *MyHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
将w和r包装成工作单元job
将job入队
等待job执行完成
本次请求处理完毕
}
ワークユニットの特定の実装を見てみましょう。ここでは、それをジョブ構造として定義します。
type Job struct {
DoneChan chan struct{}
handleJob func(j FlowJob) error //具体的处理逻辑
}
Job结构体中有一个handleJob，其类型是一个函数，即处理请求的逻辑部分。DoneChan通道用来让该单元进行阻塞等待，并当handleJob执行完毕后发送消息通知的。
下面我们再看看该Job的相关行为：
// 消费者从队列中取出该job时 执行具体的处理逻辑
func (job *Job) Execute() error {
fmt.Println("job start to execute ")
return job.handleJob(job)
}
// 执行完Execute后，调用该函数以通知主线程中等待的job
func (job *Job) Done() {
job.DoneChan <- struct{}{}
close(job.DoneChan)
}
// 工作单元等待自己被消费
func (job *Job) WaitDone() {
select {
case <-job.DoneChan:
return
}
}
队列
队列主要是用来存储工作单元的。是处理请求的主协程和消费协程之间的纽带。队列具有列表、容量、当前元素个数等关键元素组成。如下：
type JobQueue struct {
mu sync.Mutex
noticeChan chan struct{}
queue *list.List
size int
capacity int
}
其行为主要有入队、出队、移除等操作。定义如下：
// 初始化队列
func NewJobQueue(cap int) *JobQueue {
return &JobQueue{
capacity: cap,
queue: list.New(),
noticeChan: make(chan struct{}, 1),
}
}
// 工作单元入队
func (q *JobQueue) PushJob(job *Job) {
q.mu.Lock()
defer q.mu.Unlock()
q.size++
if q.size > q.capacity {
q.RemoveLeastJob()
}
q.queue.PushBack(job)
q.noticeChan <- struct{}{}
}
// 工作单元出队
func (q *JobQueue) PopJob() *Job {
q.mu.Lock()
defer q.mu.Unlock()
if q.size == 0 {
return nil
}
q.size--
return q.queue.Remove(q.queue.Front()).(*Job)
}
// 移除队列中的最后一个元素。
// 一般在容量满时，有新job加入时，会移除等待最久的一个job
func (q *JobQueue) RemoveLeastJob() {
if q.queue.Len() != 0 {
back := q.queue.Back()
abandonJob := back.Value.(*Job)
abandonJob.Done()
q.queue.Remove(back)
}
}
// 消费线程监听队列的该通道，查看是否有新的job需要消费
func (q *JobQueue) waitJob() <-chan struct{} {
return q.noticeChan
}
这里我们主要解释一下入队的操作流程：
1 首先是队列的元素个数size++
2 判断size是否超过最大容量capacity
3 若超过最大容量，则将队列中最后一个元素移除。因为该元素等待时间最长，认为是超时的情况。
4 将新接收的工作单元放入到队尾。
5 往noticeChan通道中写入一个消息，以便通知消费协程处理Job。
由以上可知，noticeChan是队列和消费者协程之间的纽带。下面我们来看看消费者的实现。
消费者协程
消费者协程的职责是监听队列，并从队列中获取工作单元，执行工作单元的具体处理逻辑。在实际应用中，可以根据系统的承载能力启用多个消费协程。在本文中，为了方便讲解，我们只启用一个消费协程。
我们定义一个WorkerManager结构体，负责管理具体的消费协程。该WorkerManager有一个属性是工作队列，所有启动的消费协程都需要从该工作队列中获取工作单元。代码实现如下：
type WorkerManager struct {
jobQueue *JobQueue
}
func NewWorkerManager(jobQueue *JobQueue) *WorkerManager {
return &WorkerManager{
jobQueue: jobQueue,
}
}
func (m *WorkerManager) createWorker() error {
go func() {
fmt.Println("start the worker success")
var job FlowJob
for {
select {
case <-m.jobQueue.waitJob():
fmt.Println("get a job from job queue")
job = m.jobQueue.PopJob()
fmt.Println("start to execute job")
job.Execute()
fmt.Print("execute job done")
job.Done()
}
}
}()
return nil
}
在代码中我们可以看到，createWorker中的逻辑实际是一个for循环，然后通过select监听队列的noticeChan通道，当获取到工作单元时，就执行工作单元中的handleJob方法。执行完后，通过job.Done()方法通知在主协程中还等待的job。这样整个流程就形成了闭环。
完整代码
我们现在看下整体的处理流程，如下图：
现在我们写一个测试demo。在这里我们定义了一个全局的flowControl结构体，以作为队列和工作协程的管理。代码如下：
package main
import (
"container/list"
"fmt"
"net/http"
"sync"
)
func main() {
flowControl := NewFlowControl()
myHandler := MyHandler{
flowControl: flowControl,
}
http.Handle("/", &myHandler)
http.ListenAndServe(":8080", nil)
}
type MyHandler struct {
flowControl *FlowControl
}
func (h *MyHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
fmt.Println("recieve http request")
job := &Job{
DoneChan: make(chan struct{}, 1),
handleJob: func(job *Job) error {
w.Header().Set("Content-Type", "application/json")
w.Write([]byte("Hello World"))
return nil
},
}
h.flowControl.CommitJob(job)
fmt.Println("commit job to job queue success")
job.WaitDone()
}
type FlowControl struct {
jobQueue *JobQueue
wm *WorkerManager
}
func NewFlowControl() *FlowControl {
jobQueue := NewJobQueue(10)
fmt.Println("init job queue success")
m := NewWorkerManager(jobQueue)
m.createWorker()
fmt.Println("init worker success")
control := &FlowControl{
jobQueue: jobQueue,
wm: m,
}
fmt.Println("init flowcontrol success")
return control
}
func (c *FlowControl) CommitJob(job *Job) {
c.jobQueue.PushJob(job)
fmt.Println("commit job success")
}
完整的示例代码可以通过git获取：http异步处理
以前の記事は優先キューです。これは実際にはキューの高度な実装バージョンであり、優先度に従ってさまざまなキューにさまざまなリクエストを割り当てることができます。興味のある学生は以下を参照できます：実際の戦闘に行く|この記事では、単一キューから優先キューへの実装を理解することができます
要約する
要求されたコンテキスト情報を作業単位にカプセル化し、それをキューに入れ、メッセージチャネルを介してブロックして、コンシューマーが実行を完了するのを待ちます。同時に、キュー内のキューの容量を設定して、過剰な要求によってシステムに圧力がかかるという問題を解決します。