創(chuàng)建 PayPal 的目的是使金融服務(wù)民主化，并使個(gè)人和企業(yè)能夠加入并在全球經(jīng)濟(jì)中蓬勃發(fā)展。這項(xiàng)工作的核心是 PayPal 的支付平臺(tái)，該平臺(tái)使用專有技術(shù)和第三方技術(shù)的組合來(lái)高效、安全地促進(jìn)全球數(shù)百萬(wàn)商家和消費(fèi)者之間的交易。隨著支付平臺(tái)變得越來(lái)越大、越來(lái)越復(fù)雜，PayPal 尋求對(duì)其系統(tǒng)進(jìn)行現(xiàn)代化改造并縮短新應(yīng)用程序的上市時(shí)間。
創(chuàng)新互聯(lián)主要從事做網(wǎng)站、成都做網(wǎng)站、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)浮梁,10余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):13518219792
Go 在生成干凈、高效的代碼方面的有著極高的價(jià)值。這些代碼可以隨著軟件部署的擴(kuò)展而輕松擴(kuò)展，這使得該語(yǔ)言非常適合支持 PayPal 的目標(biāo)。
支付處理平臺(tái)的核心是 PayPal 用 C++ 開(kāi)發(fā)的專有 NoSQL 數(shù)據(jù)庫(kù)。然而，代碼的復(fù)雜性大大降低了開(kāi)發(fā)人員發(fā)展平臺(tái)的能力。Go 的簡(jiǎn)單代碼布局、goroutine（輕量級(jí)執(zhí)行線程）和通道（用作連接并發(fā) goroutine 的管道）使 Go 成為 NoSQL 開(kāi)發(fā)團(tuán)隊(duì)簡(jiǎn)化和現(xiàn)代化平臺(tái)的自然選擇。
作為概念驗(yàn)證，一個(gè)開(kāi)發(fā)團(tuán)隊(duì)花了六個(gè)月的時(shí)間學(xué)習(xí) Go 并在 Go 中從頭開(kāi)始重新實(shí)現(xiàn) NoSQL 系統(tǒng)，在此期間，他們還提供了有關(guān)如何在 PayPal 更廣泛地實(shí)施 Go 的見(jiàn)解。截至今天，已遷移 30% 的集群以使用新的 NoSQL 數(shù)據(jù)庫(kù)。
隨著 PayPal 的平臺(tái)變得越來(lái)越復(fù)雜，Go 提供了一種輕松簡(jiǎn)化大規(guī)模創(chuàng)建和運(yùn)行軟件的復(fù)雜性的方法。該語(yǔ)言為 PayPal 提供了出色的庫(kù)和快速工具，以及并發(fā)、垃圾收集和類型安全。
借助 Go，PayPal 使其開(kāi)發(fā)人員能夠?qū)⒏鄷r(shí)間從 C++ 和 Java 開(kāi)發(fā)的噪音中解放出來(lái)，從而能夠花更多時(shí)間查看代碼和進(jìn)行戰(zhàn)略性思考。
在這個(gè)新改寫(xiě)的 NoSQL 系統(tǒng)取得成功后，PayPal 內(nèi)更多的平臺(tái)和內(nèi)容團(tuán)隊(duì)開(kāi)始采用 Go。Natarajan 目前的團(tuán)隊(duì)負(fù)責(zé) PayPal 的構(gòu)建、測(cè)試和發(fā)布管道——所有這些都是在 Go 中構(gòu)建的。該公司擁有一個(gè)大型構(gòu)建和測(cè)試農(nóng)場(chǎng)，它使用 Go 基礎(chǔ)設(shè)施進(jìn)行完全管理，以支持整個(gè)公司的開(kāi)發(fā)人員的構(gòu)建即服務(wù)（和測(cè)試即服務(wù)）。
憑借 PayPal 所需的分布式計(jì)算能力，Go 是刷新系統(tǒng)的正確語(yǔ)言。PayPal 需要并發(fā)和并行的編程，為高性能和高度可移植性而編譯，并為開(kāi)發(fā)人員帶來(lái)模塊化、可組合的開(kāi)源架構(gòu)的好處——Go 已經(jīng)提供了所有這些以及更多幫助 PayPal 對(duì)其系統(tǒng)進(jìn)行現(xiàn)代化改造。
安全性和可支持性是 PayPal 的關(guān)鍵問(wèn)題，該公司的運(yùn)營(yíng)管道越來(lái)越多地由 Go 主導(dǎo)，因?yàn)樵撜Z(yǔ)言的簡(jiǎn)潔性和模塊化幫助他們實(shí)現(xiàn)了這些目標(biāo)。PayPal 對(duì) Go 的部署為開(kāi)發(fā)人員提供了一個(gè)創(chuàng)意平臺(tái)，使他們能夠?yàn)?PayPal 的全球市場(chǎng)大規(guī)模生產(chǎn)簡(jiǎn)單、高效和可靠的軟件。
隨著 PayPal 繼續(xù)使用 Go 對(duì)其軟件定義網(wǎng)絡(luò) (SDN) 基礎(chǔ)設(shè)施進(jìn)行現(xiàn)代化改造，除了更易于維護(hù)的代碼外，他們還看到了性能優(yōu)勢(shì)。例如，Go 現(xiàn)在為路由器、負(fù)載平衡和越來(lái)越多的生產(chǎn)系統(tǒng)提供動(dòng)力。
作為一家全球性企業(yè)，PayPal 需要其開(kāi)發(fā)團(tuán)隊(duì)有效管理兩種規(guī)模：生產(chǎn)規(guī)模，尤其是與許多其他服務(wù)器（如云服務(wù)）交互的并發(fā)系統(tǒng)；和開(kāi)發(fā)規(guī)模，尤其是由許多程序員協(xié)同開(kāi)發(fā)的大型代碼庫(kù)（如開(kāi)源開(kāi)發(fā)）
PayPal 利用 Go 來(lái)解決這些規(guī)模問(wèn)題。該公司的開(kāi)發(fā)人員受益于 Go 將解釋型動(dòng)態(tài)類型語(yǔ)言的編程易用性與靜態(tài)類型編譯語(yǔ)言的效率和安全性相結(jié)合的能力。隨著 PayPal 對(duì)其系統(tǒng)進(jìn)行現(xiàn)代化改造，對(duì)網(wǎng)絡(luò)和多核計(jì)算的支持至關(guān)重要。Go 不僅提供了這種支持，而且提供的速度很快——在單臺(tái)計(jì)算機(jī)上編譯一個(gè)大型可執(zhí)行文件最多需要幾秒鐘。
PayPal 目前有 100 多名 Go 開(kāi)發(fā)人員，未來(lái)選擇采用 Go 的開(kāi)發(fā)人員將更容易獲得該語(yǔ)言的批準(zhǔn)，這要?dú)w功于公司已經(jīng)在生產(chǎn)中的許多成功實(shí)現(xiàn)。
最重要的是，PayPal 開(kāi)發(fā)人員使用 Go 提高了他們的生產(chǎn)力。Go 的并發(fā)機(jī)制使得編寫(xiě)充分利用 PayPal 的多核和聯(lián)網(wǎng)機(jī)器的程序變得很容易。使用 Go 的開(kāi)發(fā)人員還受益于它可以快速編譯為機(jī)器代碼的事實(shí)，并且他們的應(yīng)用程序獲得了垃圾收集的便利和運(yùn)行時(shí)反射的強(qiáng)大功能。
今天 PayPal 的第一類語(yǔ)言是 Java 和 Node，Go 主要用作基礎(chǔ)設(shè)施語(yǔ)言。雖然 Go 可能永遠(yuǎn)不會(huì)在某些應(yīng)用程序中取代 Node.js，但 Natarajan 正在推動(dòng)讓 Go 成為 PayPal 的第一類語(yǔ)言。
通過(guò)他的努力，PayPal 還在評(píng)估遷移到 Google Kubernetes Engine (GKE) 以加快其新產(chǎn)品的上市時(shí)間。GKE 是一個(gè)用于部署容器化應(yīng)用程序的托管、生產(chǎn)就緒環(huán)境，并帶來(lái)了 Google 在開(kāi)發(fā)人員生產(chǎn)力、自動(dòng)化操作和開(kāi)源靈活性方面的最新創(chuàng)新。
對(duì)于 PayPal 而言，部署到 GKE 將使 PayPal 更容易部署、更新和管理其應(yīng)用程序和服務(wù)，從而實(shí)現(xiàn)快速開(kāi)發(fā)和迭代。此外，PayPal 會(huì)發(fā)現(xiàn)更容易運(yùn)行機(jī)器學(xué)習(xí)、通用 GPU、高性能計(jì)算和其他受益于 GKE 支持的專用硬件加速器的工作負(fù)載。
對(duì) PayPal 來(lái)說(shuō)最重要的是，Go 開(kāi)發(fā)和 GKE 的結(jié)合使公司能夠輕松擴(kuò)展以滿足需求，因?yàn)?Kubernetes 自動(dòng)擴(kuò)展將使 PayPal 能夠處理用戶對(duì)服務(wù)不斷增長(zhǎng)的需求——在最重要的時(shí)候保持它們可用，然后在安靜的時(shí)間來(lái)省錢。
云和安全管理服務(wù)專家新鈦云服 張春翻譯
這種方法有幾個(gè)缺點(diǎn)。首先，它可以對(duì)程序員隱藏錯(cuò)誤處理路徑，特別是在捕獲異常不是強(qiáng)制性的情況下，例如在 Python 中。即使在具有必須處理的 Java 風(fēng)格的檢查異常的語(yǔ)言中，如果在與原始調(diào)用不同的級(jí)別上處理錯(cuò)誤，也并不總是很明顯錯(cuò)誤是從哪里引發(fā)的。
我們都見(jiàn)過(guò)長(zhǎng)長(zhǎng)的代碼塊包裝在一個(gè) try-catch 塊中。在這種情況下，catch 塊實(shí)際上充當(dāng) goto 語(yǔ)句，這通常被認(rèn)為是有害的（奇怪的是，C 中的關(guān)鍵字被認(rèn)為可以接受的少數(shù)用例之一是錯(cuò)誤后清理，因?yàn)樵撜Z(yǔ)言沒(méi)有 Golang- 樣式延遲語(yǔ)句）。
如果你確實(shí)從源頭捕獲異常，你會(huì)得到一個(gè)不太優(yōu)雅的 Go 錯(cuò)誤模式版本。這可能會(huì)解決混淆代碼的問(wèn)題，但會(huì)遇到另一個(gè)問(wèn)題：性能。在諸如 Java 之類的語(yǔ)言中，拋出異?？赡鼙群瘮?shù)的常規(guī)返回慢數(shù)百倍。
Java 中最大的性能成本是由打印異常的堆棧跟蹤造成的，這是昂貴的，因?yàn)檫\(yùn)行的程序必須檢查編譯它的源代碼 。僅僅進(jìn)入一個(gè) try 塊也不是空閑的，因?yàn)樾枰４?CPU 內(nèi)存寄存器的先前狀態(tài)，因?yàn)樗鼈兛赡苄枰趻伋霎惓５那闆r下恢復(fù)。
如果您將異常視為通常不會(huì)發(fā)生的異常情況，那么異常的缺點(diǎn)并不重要。這可能是傳統(tǒng)的單體應(yīng)用程序的情況，其中大部分代碼庫(kù)不必進(jìn)行網(wǎng)絡(luò)調(diào)用——一個(gè)操作格式良好的數(shù)據(jù)的函數(shù)不太可能遇到錯(cuò)誤（除了錯(cuò)誤的情況）。一旦您在代碼中添加 I/O，無(wú)錯(cuò)誤代碼的夢(mèng)想就會(huì)破滅：您可以忽略錯(cuò)誤，但不能假裝它們不存在！
try {
doSometing()
} catch (IOException e) {
// ignore it
}
與大多數(shù)其他編程語(yǔ)言不同，Golang 接受錯(cuò)誤是不可避免的。 如果在單體架構(gòu)時(shí)代還不是這樣，那么在今天的模塊化后端服務(wù)中，服務(wù)通常和外部 API 調(diào)用、數(shù)據(jù)庫(kù)讀取和寫(xiě)入以及與其他服務(wù)通信 。
以上所有方法都可能失敗，解析或驗(yàn)證從它們接收到的數(shù)據(jù)（通常在無(wú)模式 JSON 中）也可能失敗。Golang 使可以從這些調(diào)用返回的錯(cuò)誤顯式化，與普通返回值的等級(jí)相同。從函數(shù)調(diào)用返回多個(gè)值的能力支持這一點(diǎn)，這在大多數(shù)語(yǔ)言中通常是不可能的。Golang 的錯(cuò)誤處理系統(tǒng)不僅僅是一種語(yǔ)言怪癖，它是一種將錯(cuò)誤視為替代返回值的完全不同的方式！
重復(fù) if err != nil
對(duì) Go 錯(cuò)誤處理的一個(gè)常見(jiàn)批評(píng)是被迫重復(fù)以下代碼塊：
res, err := doSomething()
if err != nil {
// Handle error
}
對(duì)于新用戶來(lái)說(shuō)，這可能會(huì)覺(jué)得沒(méi)用而且浪費(fèi)行數(shù)：在其他語(yǔ)言中需要 3 行的函數(shù)很可能會(huì)增長(zhǎng)到 12 行 ：
這么多行代碼！這么低效！如果您認(rèn)為上述內(nèi)容不優(yōu)雅或浪費(fèi)代碼，您可能忽略了我們檢查代碼中的錯(cuò)誤的全部原因：我們需要能夠以不同的方式處理它們！對(duì) API 或數(shù)據(jù)庫(kù)的調(diào)用可能會(huì)被重試。
有時(shí)事件的順序很重要：調(diào)用外部 API 之前發(fā)生的錯(cuò)誤可能不是什么大問(wèn)題（因?yàn)閿?shù)據(jù)從未通過(guò)發(fā)送），而 API 調(diào)用和寫(xiě)入本地?cái)?shù)據(jù)庫(kù)之間的錯(cuò)誤可能需要立即注意，因?yàn)?這可能意味著系統(tǒng)最終處于不一致的狀態(tài)。即使我們只想將錯(cuò)誤傳播給調(diào)用者，我們也可能希望用失敗的解釋來(lái)包裝它們，或者為每個(gè)錯(cuò)誤返回一個(gè)自定義錯(cuò)誤類型。
并非所有錯(cuò)誤都是相同的，并且向調(diào)用者返回適當(dāng)?shù)腻e(cuò)誤是 API 設(shè)計(jì)的重要部分，無(wú)論是對(duì)于內(nèi)部包還是 REST API 。
不必?fù)?dān)心在你的代碼中重復(fù) if err != nil ——這就是 Go 中的代碼應(yīng)該看起來(lái)的樣子。
自定義錯(cuò)誤類型和錯(cuò)誤包裝
從導(dǎo)出的方法返回錯(cuò)誤時(shí)，請(qǐng)考慮指定自定義錯(cuò)誤類型，而不是單獨(dú)使用錯(cuò)誤字符串。字符串在意外代碼中是可以的，但在導(dǎo)出的函數(shù)中，它們成為函數(shù)公共 API 的一部分。更改錯(cuò)誤字符串將是一項(xiàng)重大更改——如果沒(méi)有明確的錯(cuò)誤類型，需要檢查返回錯(cuò)誤類型的單元測(cè)試將不得不依賴原始字符串值！事實(shí)上，基于字符串的錯(cuò)誤也使得在私有方法中測(cè)試不同的錯(cuò)誤案例變得困難，因此您也應(yīng)該考慮在包中使用它們。回到錯(cuò)誤與異常的爭(zhēng)論，返回錯(cuò)誤也使代碼比拋出異常更容易測(cè)試，因?yàn)殄e(cuò)誤只是要檢查的返回值。不需要測(cè)試框架或在測(cè)試中捕獲異常 。
可以在 database/sql 包中找到簡(jiǎn)單自定義錯(cuò)誤類型的一個(gè)很好的示例。它定義了一個(gè)導(dǎo)出常量列表，表示包可以返回的錯(cuò)誤類型，最著名的是 sql.ErrNoRows。雖然從 API 設(shè)計(jì)的角度來(lái)看，這種特定的錯(cuò)誤類型有點(diǎn)問(wèn)題（您可能會(huì)爭(zhēng)辯說(shuō) API 應(yīng)該返回一個(gè)空結(jié)構(gòu)而不是錯(cuò)誤），但任何需要檢查空行的應(yīng)用程序都可以導(dǎo)入該常量并在代碼中使用它不必?fù)?dān)心錯(cuò)誤消息本身會(huì)改變和破壞代碼。
對(duì)于更復(fù)雜的錯(cuò)誤處理，您可以通過(guò)實(shí)現(xiàn)返回錯(cuò)誤字符串的 Error() 方法來(lái)定義自定義錯(cuò)誤類型。自定義錯(cuò)誤可以包括元數(shù)據(jù)，例如錯(cuò)誤代碼或原始請(qǐng)求參數(shù)。如果您想表示錯(cuò)誤類別，它們很有用。DigitalOcean 的本教程展示了如何使用自定義錯(cuò)誤類型來(lái)表示可以重試的一類臨時(shí)錯(cuò)誤。
通常，錯(cuò)誤會(huì)通過(guò)將低級(jí)錯(cuò)誤與更高級(jí)別的解釋包裝起來(lái)，從而在程序的調(diào)用堆棧中傳播。例如，數(shù)據(jù)庫(kù)錯(cuò)誤可能會(huì)以下列格式記錄在 API 調(diào)用處理程序中：調(diào)用 CreateUser 端點(diǎn)時(shí)出錯(cuò)：查詢數(shù)據(jù)庫(kù)時(shí)出錯(cuò)：pq：檢測(cè)到死鎖。這很有用，因?yàn)樗梢詭椭覀兏欏e(cuò)誤在系統(tǒng)中傳播的過(guò)程，向我們展示根本原因（數(shù)據(jù)庫(kù)事務(wù)引擎中的死鎖）以及它對(duì)更廣泛系統(tǒng)的影響（調(diào)用者無(wú)法創(chuàng)建新用戶）。
自 Go 1.13 以來(lái)，此模式具有特殊的語(yǔ)言支持，并帶有錯(cuò)誤包裝。通過(guò)在創(chuàng)建字符串錯(cuò)誤時(shí)使用 %w 動(dòng)詞，可以使用 Unwrap() 方法訪問(wèn)底層錯(cuò)誤。除了比較錯(cuò)誤相等性的函數(shù) errors.Is() 和 errors.As() 外，程序還可以獲取包裝錯(cuò)誤的原始類型或標(biāo)識(shí)。這在某些情況下可能很有用，盡管我認(rèn)為在確定如何處理所述錯(cuò)誤時(shí)最好使用頂級(jí)錯(cuò)誤的類型。
Panics
不要 panic()！長(zhǎng)時(shí)間運(yùn)行的應(yīng)用程序應(yīng)該優(yōu)雅地處理錯(cuò)誤而不是panic。即使在無(wú)法恢復(fù)的情況下（例如在啟動(dòng)時(shí)驗(yàn)證配置），最好記錄一個(gè)錯(cuò)誤并優(yōu)雅地退出。panic比錯(cuò)誤消息更難診斷，并且可能會(huì)跳過(guò)被推遲的重要關(guān)閉代碼。
Logging
我還想簡(jiǎn)要介紹一下日志記錄，因?yàn)樗翘幚礤e(cuò)誤的關(guān)鍵部分。通常你能做的最好的事情就是記錄收到的錯(cuò)誤并繼續(xù)下一個(gè)請(qǐng)求。
除非您正在構(gòu)建簡(jiǎn)單的命令行工具或個(gè)人項(xiàng)目，否則您的應(yīng)用程序應(yīng)該使用結(jié)構(gòu)化的日志庫(kù)，該庫(kù)可以為日志添加時(shí)間戳，并提供對(duì)日志級(jí)別的控制。最后一部分特別重要，因?yàn)樗鼘⒃试S您突出顯示應(yīng)用程序記錄的所有錯(cuò)誤和警告。通過(guò)幫助將它們與信息級(jí)日志分開(kāi)，這將為您節(jié)省無(wú)數(shù)時(shí)間。
微服務(wù)架構(gòu)還應(yīng)該在日志行中包含服務(wù)的名稱以及機(jī)器實(shí)例的名稱。默認(rèn)情況下記錄這些時(shí)，程序代碼不必?fù)?dān)心包含它們。您也可以在日志的結(jié)構(gòu)化部分中記錄其他字段，例如收到的錯(cuò)誤（如果您不想將其嵌入日志消息本身）或有問(wèn)題的請(qǐng)求或響應(yīng)。只需確保您的日志沒(méi)有泄露任何敏感數(shù)據(jù)，例如密碼、API 密鑰或用戶的個(gè)人數(shù)據(jù)！
對(duì)于日志庫(kù)，我過(guò)去使用過(guò) logrus 和 zerolog，但您也可以選擇其他結(jié)構(gòu)化日志庫(kù)。如果您想了解更多信息，互聯(lián)網(wǎng)上有許多關(guān)于如何使用這些的指南。如果您將應(yīng)用程序部署到云中，您可能需要日志庫(kù)上的適配器來(lái)根據(jù)您的云平臺(tái)的日志 API 格式化日志 - 沒(méi)有它，云平臺(tái)可能無(wú)法檢測(cè)到日志級(jí)別等某些功能。
如果您在應(yīng)用程序中使用調(diào)試級(jí)別日志（默認(rèn)情況下通常不記錄），請(qǐng)確保您的應(yīng)用程序可以輕松更改日志級(jí)別，而無(wú)需更改代碼。更改日志級(jí)別還可以暫時(shí)使信息級(jí)別甚至警告級(jí)別的日志靜音，以防它們突然變得過(guò)于嘈雜并開(kāi)始淹沒(méi)錯(cuò)誤。您可以使用在啟動(dòng)時(shí)檢查以設(shè)置日志級(jí)別的環(huán)境變量來(lái)實(shí)現(xiàn)這一點(diǎn)。
原文：
當(dāng)您對(duì)外部模塊的存儲(chǔ)庫(kù)進(jìn)行了 fork （例如修復(fù)模塊代碼中的問(wèn)題或添加功能）時(shí)，您可以讓 Go 工具將您的 fork 用于模塊的源代碼。這對(duì)于測(cè)試您自己的代碼的更改很有用。
為此，您可以使用go.mod 文件中的replace指令將外部模塊的原始模塊路徑替換為存儲(chǔ)庫(kù)中 fork 的路徑。這指示 Go 工具在編譯時(shí)使用替換路徑（fork 的位置），例如，同時(shí)允許您保留import 原始模塊路徑中的語(yǔ)句不變。
在以下 go.mod 文件示例中，當(dāng)前模塊需要外部模塊example.com/theirmodule。然后該replace指令將原始模塊路徑替換為example.com/myfork/theirmodule模塊自己的存儲(chǔ)庫(kù)的分支。
設(shè)置require/replace對(duì)時(shí)，使用 Go 工具命令確保文件描述的需求保持一致。使用go list命令獲取當(dāng)前模塊正在使用的版本。然后使用go mod edit命令將需要的模塊替換為fork：
注意： 當(dāng)您使用該replace指令時(shí)，Go 工具不會(huì)像添加依賴項(xiàng)中所述對(duì)外部模塊進(jìn)行身份驗(yàn)證。
您可以使用go get命令從其存儲(chǔ)庫(kù)中的特定提交為模塊添加未發(fā)布的代碼。
為此，您使用go get命令，用符號(hào)@指定您想要的代碼 。當(dāng)您使用go get時(shí)，該命令將向您的 go.mod 文件添加一個(gè) 需要外部模塊的require指令，使用基于有關(guān)提交的詳細(xì)信息的偽版本號(hào)。
以下示例提供了一些說(shuō)明。這些基于源位于 git 存儲(chǔ)庫(kù)中的模塊。
當(dāng)您的代碼不再使用模塊中的任何包時(shí)，您可以停止將該模塊作為依賴項(xiàng)進(jìn)行跟蹤。
要停止跟蹤所有未使用的模塊，請(qǐng)運(yùn)行g(shù)o mod tidy 命令。此命令還可能添加在模塊中構(gòu)建包所需的缺失依賴項(xiàng)。
要?jiǎng)h除特定依賴項(xiàng)，請(qǐng)使用go get，指定模塊的模塊路徑并附加 @none，如下例所示：
go get命令還將降級(jí)或刪除依賴于已刪除模塊的其他依賴項(xiàng)。
當(dāng)您使用 Go 工具處理模塊時(shí)，這些工具默認(rèn)從 proxy.golang.org（一個(gè)公共的 Google 運(yùn)行的模塊鏡像）或直接從模塊的存儲(chǔ)庫(kù)下載模塊。您可以指定 Go 工具應(yīng)該使用另一個(gè)代理服務(wù)器來(lái)下載和驗(yàn)證模塊。
如果您（或您的團(tuán)隊(duì)）已經(jīng)設(shè)置或選擇了您想要使用的不同模塊代理服務(wù)器，您可能想要這樣做。例如，有些人設(shè)置了模塊代理服務(wù)器，以便更好地控制依賴項(xiàng)的使用方式。
要為 Go 工具指定另一個(gè)模塊代理服務(wù)器，請(qǐng)將GOPROXY 環(huán)境變量設(shè)置為一個(gè)或多個(gè)服務(wù)器的 URL。Go 工具將按照您指定的順序嘗試每個(gè) URL。默認(rèn)情況下，GOPROXY首先指定一個(gè)公共的 Google 運(yùn)行模塊代理，然后從模塊的存儲(chǔ)庫(kù)直接下載（在其模塊路徑中指定）：
您可以將變量設(shè)置為其他模塊代理服務(wù)器的 URL，用逗號(hào)或管道分隔 URL。
Go 模塊經(jīng)常在公共互聯(lián)網(wǎng)上不可用的版本控制服務(wù)器和模塊代理上開(kāi)發(fā)和分發(fā)。您可以設(shè)置 GOPRIVATE環(huán)境變量。您可以設(shè)置GOPRIVATE環(huán)境變量來(lái)配置go命令以從私有源下載和構(gòu)建模塊。然后 go 命令可以從私有源下載和構(gòu)建模塊。
GOPRIVATE或環(huán)境變量可以設(shè)置為匹配模塊前綴的全局模式列表，這些GONOPROXY前綴是私有的，不應(yīng)從任何代理請(qǐng)求。例如：
1.為什么golang的開(kāi)發(fā)效率高？
golang是一編譯型的強(qiáng)類型語(yǔ)言，它在開(kāi)發(fā)上的高效率主要來(lái)自于后發(fā)優(yōu)勢(shì)，不用考慮舊有惡心的歷史，又有一個(gè)較高的工程視角。良好的避免了程序員因?yàn)椤?{ 需不需要獨(dú)占一行 ”這種革命問(wèn)題打架，也解決了一部分趁編譯時(shí)間找產(chǎn)品妹妹搭訕的階級(jí)敵人。
它有自己的包管理機(jī)制，工具鏈成熟，從開(kāi)發(fā)、調(diào)試到發(fā)布都很簡(jiǎn)單方便；
有反向接口、defer、coroutine等大量的syntactic sugar；
編譯速度快，因?yàn)槭菑?qiáng)類型語(yǔ)言又有g(shù)c，只要通過(guò)編譯，非業(yè)務(wù)毛病就很少了；
它在語(yǔ)法級(jí)別上支持了goroutine，這是大家說(shuō)到最多的內(nèi)容，這里重點(diǎn)提一下。首先，coroutine并不稀罕，語(yǔ)言并不能超越硬件、操作系統(tǒng)實(shí)現(xiàn)神乎其神的功能。golang可以做到事情，其他語(yǔ)言也可以做到，譬如c++，在boost庫(kù)里面自己就有的coroutine實(shí)現(xiàn)（當(dāng)然用起來(lái)跟其他boost庫(kù)一樣惡心）。golang做的事情，是把這一套東西的使用過(guò)程簡(jiǎn)化了，并且提供了一套channel的通信模式，使得程序員可以忽略諸如死鎖等問(wèn)題。
goroutine的目的是描述并發(fā)編程模型。并發(fā)與并行不同，它并不需要多核的硬件支持，它不是一種物理運(yùn)行狀態(tài)，而是一種程序邏輯流程。它的主要目的不是利用多核提高運(yùn)行效率，而是提供一種更容易理解、不容易出錯(cuò)的語(yǔ)言來(lái)描述問(wèn)題。
實(shí)際上golang默認(rèn)就是運(yùn)行在單OS進(jìn)程上面的，通過(guò)指定環(huán)境變量GOMAXPROCS才能轉(zhuǎn)身跑在多OS進(jìn)程上面。有人提到了網(wǎng)易的pomelo，開(kāi)源本來(lái)是一件很不錯(cuò)的事情，但是基于自己對(duì)callback hell的偏見(jiàn)，我一直持有這種態(tài)度：敢用nodejs寫(xiě)大規(guī)模游戲服務(wù)器的人，都是真正的勇士 : ) 。
2、Erlang與Golang的coroutine有啥區(qū)別，coroutine是啥？
coroutine本質(zhì)上是語(yǔ)言開(kāi)發(fā)者自己實(shí)現(xiàn)的、處于user space內(nèi)的線程，無(wú)論是erlang、還是golang都是這樣。需要解決沒(méi)有時(shí)鐘中斷；碰著阻塞式i\o，整個(gè)進(jìn)程都會(huì)被操作系統(tǒng)主動(dòng)掛起；需要自己擁有調(diào)度控制能力（放在并行環(huán)境下面還是挺麻煩的一件事）等等問(wèn)題。那為啥要廢老大的勁自己做一套線程放user space里面呢？
并發(fā)是服務(wù)器語(yǔ)言必須要解決的問(wèn)題；
system space的進(jìn)程還有線程調(diào)度都太慢了、占用的空間也太大了。
把線程放到user space的可以避免了陷入system call進(jìn)行上下文切換以及高速緩沖更新，線程本身以及切換等操作可以做得非常的輕量。這也就是golang這類語(yǔ)言反復(fù)提及的超高并發(fā)能力，分分鐘給你開(kāi)上幾千個(gè)線程不費(fèi)力。
不同的是，golang的并發(fā)調(diào)度在i/o等易發(fā)阻塞的時(shí)候才會(huì)發(fā)生，一般是內(nèi)封在庫(kù)函數(shù)內(nèi)；erlang則更夸張，對(duì)每個(gè)coroutine維持一個(gè)計(jì)數(shù)器，常用語(yǔ)句都會(huì)導(dǎo)致這個(gè)計(jì)數(shù)器進(jìn)行reduction，一旦到點(diǎn)，立即切換調(diào)度函數(shù)。
中斷介入程度的不同，導(dǎo)致erlang看上去擁有了preemptive scheduling的能力，而golang則是cooperative shceduling的。golang一旦寫(xiě)出純計(jì)算死循環(huán)，進(jìn)程內(nèi)所有會(huì)話必死無(wú)疑；要有大計(jì)算量少i\o的函數(shù)還得自己主動(dòng)叫runtime.Sched()來(lái)進(jìn)行調(diào)度切換。
3、golang的運(yùn)行效率怎么樣？
我是相當(dāng)反感所謂的ping\pong式benchmark，運(yùn)行效率需要放到具體的工作環(huán)境下面考慮。
首先，它再快也是快不過(guò)c的，畢竟底下做了那么多工作，又有調(diào)度，又有g(shù)c什么的。那為什么在那些benchmark里面，golang、nodejs、erlang的響應(yīng)效率看上去那么優(yōu)秀呢，響應(yīng)快，并發(fā)強(qiáng)？并發(fā)能力強(qiáng)的原因上面已經(jīng)提到了，響應(yīng)快是因?yàn)榇罅糠亲枞絠\o操作出現(xiàn)的原因。這一點(diǎn)c也可以做到，并且能力更強(qiáng)，但是得多寫(xiě)不少優(yōu)質(zhì)代碼。
然后，針對(duì)游戲服務(wù)器這種高實(shí)時(shí)性的運(yùn)行環(huán)境，GC所造成的跳幀問(wèn)題確實(shí)比較麻煩，前面的大神 @達(dá)達(dá) 有比較詳細(xì)的論述和緩解方案，就不累述了 。隨著golang的持續(xù)開(kāi)發(fā)，相信應(yīng)該會(huì)有非常大的改進(jìn)。一是屏蔽內(nèi)存操作是現(xiàn)代語(yǔ)言的大勢(shì)所趨，它肯定是需要被實(shí)現(xiàn)的；二是GC算法已經(jīng)相當(dāng)?shù)某墒?，效率勉勉?qiáng)強(qiáng)過(guò)得去；三是可以通過(guò)incremental的操作來(lái)均攤cpu消耗。
用這一點(diǎn)點(diǎn)效率損失換取一個(gè)更高的生產(chǎn)能力是不是值得呢？我覺(jué)得是值得的，硬件已經(jīng)很便宜了，人生苦短，讓自己的生活更輕松一點(diǎn)吧: )。
4、基于以上的論述，我認(rèn)為采用go進(jìn)行小范圍的MMORPG開(kāi)發(fā)是可行的。
已經(jīng)有好多程序員都把Go語(yǔ)言描述為是一種所見(jiàn)即所得(WYSIWYG)的編程語(yǔ)言。這是說(shuō)，代碼要做的事和它在字面上表達(dá)的意思是完全一致的。 在這些新語(yǔ)言中，包含D，Go，Rust和Vala語(yǔ)言，Go曾一度出現(xiàn)在TIOBE的排行榜上面。與其他新語(yǔ)言相比，Go的魅力明顯要大很多。Go的成熟特征會(huì)得到許多開(kāi)發(fā)者的欣賞，而不僅僅是因?yàn)槠淇浯笃湓~的曝光度。下面我們來(lái)一起探討一下谷歌開(kāi)發(fā)的Go語(yǔ)言以及談?wù)凣o為什么會(huì)吸引眾多開(kāi)發(fā)者： 快速簡(jiǎn)單的編譯 Go編譯速度很快，如此快速的編譯使它很容易作為腳本語(yǔ)言使用。關(guān)于編譯速度快主要有以下幾個(gè)原因：首先，Go不使用頭文件；其次如果一個(gè)模塊是依賴A的，這反過(guò)來(lái)又取決于B，在A里面的需求改變只需重新編譯原始模塊和與A相依賴的地方；最后，對(duì)象模塊里面包含了足夠的依賴關(guān)系信息，所以編譯器不需要重新創(chuàng)建文件。你只需要簡(jiǎn)單地編譯主模塊，項(xiàng)目中需要的其他部分就會(huì)自動(dòng)編譯，很酷，是不是？ 通過(guò)返回?cái)?shù)值列表來(lái)處理錯(cuò)誤信息 目前，在本地語(yǔ)言里面處理錯(cuò)誤的方式主要有兩種：直接返回代碼或者拋異常。這兩種都不是最理想的處理方式。其中返回代碼是非常令人沮喪的，因?yàn)榉祷氐腻e(cuò)誤代碼經(jīng)常與從函數(shù)中返回的數(shù)據(jù)相沖突。Go允許函數(shù)返回多個(gè)值來(lái)解決這個(gè)問(wèn)題。這個(gè)從函數(shù)里面返回的值，可以用來(lái)檢查定義的類型是否正確并且可以隨時(shí)隨地對(duì)函數(shù)的返回值進(jìn)行檢查。如果你對(duì)錯(cuò)誤值不關(guān)心，你可以不必檢查。在這兩種情況下，常規(guī)的返回值都是可用的。 簡(jiǎn)化的成分（優(yōu)先于繼承） 通過(guò)使用接口，類型是有資格成為對(duì)象中一員的，就像Java指定行為一樣。例如在標(biāo)準(zhǔn)庫(kù)里面的IO包，定義一個(gè)Writer來(lái)指定一個(gè)方法，一個(gè)Writer函數(shù)，其中輸入?yún)?shù)是字節(jié)數(shù)組并且返回整數(shù)類型值或者錯(cuò)誤類型。任何類型實(shí)現(xiàn)一個(gè)帶有相同簽名的Writer方法是對(duì)IO的完全實(shí)現(xiàn)，Writer接口。這種是解耦代碼而不是優(yōu)雅。它還簡(jiǎn)化了模擬對(duì)象來(lái)進(jìn)行單元測(cè)試。例如你想在數(shù)據(jù)庫(kù)對(duì)象中測(cè)試一個(gè)方法，在標(biāo)準(zhǔn)語(yǔ)言中，你通常需要?jiǎng)?chuàng)建一個(gè)數(shù)據(jù)庫(kù)對(duì)象，并且需要進(jìn)行大量的初始化和協(xié)議來(lái)模擬對(duì)象。在Go里面，如果該方法需要實(shí)現(xiàn)一個(gè)接口，你可以創(chuàng)建任何對(duì)該接口有用的對(duì)象，所以，你創(chuàng)建了MockDatabase，這是很小的對(duì)象，只實(shí)現(xiàn)了幾個(gè)需要運(yùn)行和模擬的接口——沒(méi)有構(gòu)造函數(shù)，沒(méi)有附件功能，只是一些方法。 簡(jiǎn)化的并發(fā)性 相對(duì)于其他語(yǔ)言，并發(fā)性在Go里面顯得更加容易。把‘go’關(guān)鍵字放在任意函數(shù)前面然后那個(gè)函數(shù)就會(huì)在其go-routine自動(dòng)運(yùn)行（一個(gè)很輕的線程）。go-routines是通過(guò)通道進(jìn)行交流并且基本上封鎖了所有的隊(duì)列消息。普通工具對(duì)相互排斥是有用，但是Go通過(guò)使用通道來(lái)踢掉并發(fā)性任務(wù)和坐標(biāo)更加容易。 優(yōu)秀的錯(cuò)誤消息 所有與Go相似的語(yǔ)言，自身作出的診斷都是無(wú)法與Go相媲美的。例如，一個(gè)死鎖程序，在Go運(yùn)行時(shí)會(huì)通知你目前哪個(gè)線程導(dǎo)致了這種死鎖。編譯的錯(cuò)誤信息是非常詳細(xì)全面和有用的。 其他 這里還有許多其他吸引人的地方，下面就一概而過(guò)的介紹一下，比如高階函數(shù)、垃圾回收、哈希映射和可擴(kuò)展的數(shù)組內(nèi)置語(yǔ)言（部分語(yǔ)言語(yǔ)法，而不是作為一個(gè)庫(kù)）等等。 當(dāng)然，Go并不是完美無(wú)瑕。在工具方面還有些不成熟的地方和用戶社區(qū)較小等，但是隨著谷歌語(yǔ)言的不斷發(fā)展，肯定會(huì)有整治措施出來(lái)。盡管許多語(yǔ)言，尤其是D、Rust和Vala旨在簡(jiǎn)化C++并且對(duì)其進(jìn)行簡(jiǎn)化，但它們給人的感覺(jué)仍是“C++看上去要更好”。
【Go語(yǔ)言的優(yōu)勢(shì)】
可直接編譯成機(jī)器碼，不依賴其他庫(kù)，glibc的版本有一定要求，部署就是扔一個(gè)文件上去就完成了。
靜態(tài)類型語(yǔ)言，但是有動(dòng)態(tài)語(yǔ)言的感覺(jué)，靜態(tài)類型的語(yǔ)言就是可以在編譯的時(shí)候檢查出來(lái)隱藏的大多數(shù)問(wèn)題，動(dòng)態(tài)語(yǔ)言的感覺(jué)就是有很多的包可以使用，寫(xiě)起來(lái)的效率很高。
語(yǔ)言層面支持并發(fā)，這個(gè)就是Go最大的特色，天生的支持并發(fā)，我曾經(jīng)說(shuō)過(guò)一句話，天生的基因和整容是有區(qū)別的，大家一樣美麗，但是你喜歡整容的還是天生基因的美麗呢？Go就是基因里面支持的并發(fā)，可以充分的利用多核，很容易的使用并發(fā)。
內(nèi)置runtime，支持垃圾回收，這屬于動(dòng)態(tài)語(yǔ)言的特性之一吧，雖然目前來(lái)說(shuō)GC不算完美，但是足以應(yīng)付我們所能遇到的大多數(shù)情況，特別是Go1.1之后的GC。
簡(jiǎn)單易學(xué)，Go語(yǔ)言的作者都有C的基因，那么Go自然而然就有了C的基因，那么Go關(guān)鍵字是25個(gè)，但是表達(dá)能力很強(qiáng)大，幾乎支持大多數(shù)你在其他語(yǔ)言見(jiàn)過(guò)的特性：繼承、重載、對(duì)象等。
豐富的標(biāo)準(zhǔn)庫(kù)，Go目前已經(jīng)內(nèi)置了大量的庫(kù)，特別是網(wǎng)絡(luò)庫(kù)非常強(qiáng)大，我最愛(ài)的也是這部分。
內(nèi)置強(qiáng)大的工具，Go語(yǔ)言里面內(nèi)置了很多工具鏈，最好的應(yīng)該是gofmt工具，自動(dòng)化格式化代碼，能夠讓團(tuán)隊(duì)review變得如此的簡(jiǎn)單，代碼格式一模一樣，想不一樣都很困難。
跨編譯，如果你寫(xiě)的Go代碼不包含cgo，那么就可以做到window系統(tǒng)編譯linux的應(yīng)用，如何做到的呢？Go引用了plan9的代碼，這就是不依賴系統(tǒng)的信息。
內(nèi)嵌C支持，前面說(shuō)了作者是C的作者，所以Go里面也可以直接包含c代碼，利用現(xiàn)有的豐富的C庫(kù)。
原文：【 】
如果有解答的不對(duì)的，麻煩各位在評(píng)論寫(xiě)出來(lái)~
go的調(diào)度原理是基于GMP模型，G代表一個(gè)goroutine，不限制數(shù)量；M=machine，代表一個(gè)線程，最大1萬(wàn)，所有G任務(wù)還是在M上執(zhí)行；P=processor代表一個(gè)處理器，每一個(gè)允許的M都會(huì)綁定一個(gè)G，默認(rèn)與邏輯CPU數(shù)量相等（通過(guò)runtime.GOMAXPROCS(runtime.NumCPU())設(shè)置）。
go調(diào)用過(guò)程：
可以能，也可以不能。
因?yàn)間o存在不能使用==判斷類型：map、slice，如果struct包含這些類型的字段，則不能比較。
這兩種類型也不能作為map的key。
類似棧操作，后進(jìn)先出。
因?yàn)間o的return是一個(gè)非原子性操作，比如語(yǔ)句 return i ，實(shí)際上分兩步進(jìn)行，即將i值存入棧中作為返回值，然后執(zhí)行跳轉(zhuǎn)，而defer的執(zhí)行時(shí)機(jī)正是跳轉(zhuǎn)前，所以說(shuō)defer執(zhí)行時(shí)還是有機(jī)會(huì)操作返回值的。
select的case的表達(dá)式必須是一個(gè)channel類型，所有case都會(huì)被求值，求值順序自上而下，從左至右。如果多個(gè)case可以完成，則會(huì)隨機(jī)執(zhí)行一個(gè)case，如果有default分支，則執(zhí)行default分支語(yǔ)句。如果連default都沒(méi)有，則select語(yǔ)句會(huì)一直阻塞，直到至少有一個(gè)IO操作可以進(jìn)行。
break關(guān)鍵字可跳出select的執(zhí)行。
goroutine管理、信息傳遞。context的意思是上下文，在線程、協(xié)程中都有這個(gè)概念，它指的是程序單元的一個(gè)運(yùn)行狀態(tài)、現(xiàn)場(chǎng)、快照，包含。context在多個(gè)goroutine中是并發(fā)安全的。
應(yīng)用場(chǎng)景：
例子參考：
waitgroup
channel
len：切片的長(zhǎng)度，訪問(wèn)時(shí)間復(fù)雜度為O(1)，go的slice底層是對(duì)數(shù)組的引用。
cap：切片的容量，擴(kuò)容是以這個(gè)值為標(biāo)準(zhǔn)。默認(rèn)擴(kuò)容是2倍，當(dāng)達(dá)到1024的長(zhǎng)度后，按1.25倍。
擴(kuò)容：每次擴(kuò)容slice底層都將先分配新的容量的內(nèi)存空間，再將老的數(shù)組拷貝到新的內(nèi)存空間，因?yàn)檫@個(gè)操作不是并發(fā)安全的。所以并發(fā)進(jìn)行append操作，讀到內(nèi)存中的老數(shù)組可能為同一個(gè)，最終導(dǎo)致append的數(shù)據(jù)丟失。
共享：slice的底層是對(duì)數(shù)組的引用，因此如果兩個(gè)切片引用了同一個(gè)數(shù)組片段，就會(huì)形成共享底層數(shù)組。當(dāng)sliec發(fā)生內(nèi)存的重新分配（如擴(kuò)容）時(shí)，會(huì)對(duì)共享進(jìn)行隔斷。詳細(xì)見(jiàn)下面例子：
make([]Type,len,cap)
map的底層是hash table(hmap類型)，對(duì)key值進(jìn)行了hash，并將結(jié)果的低八位用于確定key/value存在于哪個(gè)bucket（bmap類型）。再將高八位與bucket的tophash進(jìn)行依次比較，確定是否存在。出現(xiàn)hash沖撞時(shí)，會(huì)通過(guò)bucket的overflow指向另一個(gè)bucket，形成一個(gè)單向鏈表。每個(gè)bucket存儲(chǔ)8個(gè)鍵值對(duì)。
如果要實(shí)現(xiàn)map的順序讀取，需要使用一個(gè)slice來(lái)存儲(chǔ)map的key并按照順序進(jìn)行排序。
利用map，如果要求并發(fā)安全，就用sync.map
要注意下set中的delete函數(shù)需要使用 delete(map) 來(lái)實(shí)現(xiàn)，但是這個(gè)并不會(huì)釋放內(nèi)存，除非value也是一個(gè)子map。當(dāng)進(jìn)行多次delete后，可以使用make來(lái)重建map。
使用sync.Map來(lái)管理topic，用channel來(lái)做隊(duì)列。
參考：
多路歸并法:
pre class="vditor-reset" placeholder="" contenteditable="true" spellcheck="false"p data-block="0"(1)假設(shè)有K路a href=""數(shù)據(jù)流/a，流內(nèi)部是有序的，且流間同為升序或降序；
/pp data-block="0"(2)首先讀取每個(gè)流的第一個(gè)數(shù)，如果已經(jīng)EOF，pass；
/pp data-block="0"(3)將有效的k(k可能小于K)個(gè)數(shù)比較，選出最小的那路mink，輸出，讀取mink的下一個(gè)；
/pp data-block="0"(4)直到所有K路都EOF。
/p/pre
假設(shè)文件又1個(gè)G，內(nèi)存只有256M，無(wú)法將1個(gè)G的文件全部讀到內(nèi)存進(jìn)行排序。
第一步：
可以分為10段讀取，每段讀取100M的數(shù)據(jù)并排序好寫(xiě)入硬盤。
假設(shè)寫(xiě)入后的文件為A,B，C...10
第二步:
將A，B,C...10的第一個(gè)字符拿出來(lái)，對(duì)這10個(gè)字符進(jìn)行排序，并將結(jié)果寫(xiě)入硬盤，同時(shí)記錄被寫(xiě)入的字符的文件指針P。
第三步：
將剛剛排序好的9個(gè)字符再加上從指針P讀取到的P+1位數(shù)據(jù)進(jìn)行排序，并寫(xiě)入硬盤。
重復(fù)二、三步驟。
go文件讀寫(xiě)參考：
保證排序前兩個(gè)相等的數(shù)其在序列的前后位置順序和排序后它們兩個(gè)的前后位置順序相同的排序叫穩(wěn)定排序。
快速排序、希爾排序、堆排序、直接選擇排序不是穩(wěn)定的排序算法。
基數(shù)排序、冒泡排序、直接插入排序、折半插入排序、歸并排序是穩(wěn)定的排序算法。
參考：
head只請(qǐng)求頁(yè)面的首部。多用來(lái)判斷網(wǎng)頁(yè)是否被修改和超鏈接的有效性。
get請(qǐng)求頁(yè)面信息，并返回實(shí)例的主體。
參考:
401：未授權(quán)的訪問(wèn)。
403: 拒絕訪問(wèn)。
普通的http連接是客戶端連接上服務(wù)端，然后結(jié)束請(qǐng)求后，由客戶端或者服務(wù)端進(jìn)行http連接的關(guān)閉。下次再發(fā)送請(qǐng)求的時(shí)候，客戶端再發(fā)起一個(gè)連接，傳送數(shù)據(jù)，關(guān)閉連接。這么個(gè)流程反復(fù)。但是一旦客戶端發(fā)送connection:keep-alive頭給服務(wù)端，且服務(wù)端也接受這個(gè)keep-alive的話，兩邊對(duì)上暗號(hào)，這個(gè)連接就可以復(fù)用了，一個(gè)http處理完之后，另外一個(gè)http數(shù)據(jù)直接從這個(gè)連接走了。減少新建和斷開(kāi)TCP連接的消耗。這個(gè)可以在Nginx設(shè)置，
這個(gè)keepalive_timout時(shí)間值意味著：一個(gè)http產(chǎn)生的tcp連接在傳送完最后一個(gè)響應(yīng)后，還需要hold住keepalive_timeout秒后，才開(kāi)始關(guān)閉這個(gè)連接。
特別注意TCP層的keep alive和http不是一個(gè)意思。TCP的是指：tcp連接建立后，如果客戶端很長(zhǎng)一段時(shí)間不發(fā)送消息，當(dāng)連接很久沒(méi)有收到報(bào)文，tcp會(huì)主動(dòng)發(fā)送一個(gè)為空的報(bào)文（偵測(cè)包）給對(duì)方，如果對(duì)方收到了并且回復(fù)了，證明對(duì)方還在。如果對(duì)方?jīng)]有報(bào)文返回，重試多次之后則確認(rèn)連接丟失，斷開(kāi)連接。
tcp的keep alive可通過(guò)
net.ipv4.tcp_keepalive_intvl = 75 // 當(dāng)探測(cè)沒(méi)有確認(rèn)時(shí)，重新發(fā)送探測(cè)的頻度。缺省是75秒。
net.ipv4.tcp_keepalive_probes = 9 //在認(rèn)定連接失效之前，發(fā)送多少個(gè)TCP的keepalive探測(cè)包。缺省值是9。這個(gè)值乘以tcp_keepalive_intvl之后決定了，一個(gè)連接發(fā)送了keepalive之后可以有多少時(shí)間沒(méi)有回應(yīng)
net.ipv4.tcp_keepalive_time = 7200 //當(dāng)keepalive起用的時(shí)候，TCP發(fā)送keepalive消息的頻度。缺省是2小時(shí)。一般設(shè)置為30分鐘1800
修改：
可以
tcp是面向連接的，upd是無(wú)連接狀態(tài)的。
udp相比tcp沒(méi)有建立連接的過(guò)程，所以更快，同時(shí)也更安全，不容易被攻擊。upd沒(méi)有阻塞控制，因此出現(xiàn)網(wǎng)絡(luò)阻塞不會(huì)使源主機(jī)的發(fā)送效率降低。upd支持一對(duì)多，多對(duì)多等，tcp是點(diǎn)對(duì)點(diǎn)傳輸。tcp首部開(kāi)銷20字節(jié)，udp8字節(jié)。
udp使用場(chǎng)景：視頻通話、im聊天等。
time-wait表示客戶端等待服務(wù)端返回關(guān)閉信息的狀態(tài)，closed_wait表示服務(wù)端得知客戶端想要關(guān)閉連接，進(jìn)入半關(guān)閉狀態(tài)并返回一段TCP報(bào)文。
time-wait作用：
解決辦法：
close_wait:
被動(dòng)關(guān)閉，通常是由于客戶端忘記關(guān)閉tcp連接導(dǎo)致。
根據(jù)業(yè)務(wù)來(lái)啊~
重要指標(biāo)是cardinality（不重復(fù)數(shù)量），這個(gè)數(shù)量/總行數(shù)如果過(guò)?。ㄚ吔?）代表索引基本沒(méi)意義，比如sex性別這種。
另外查詢不要使用select *，根據(jù)select的條件+where條件做組合索引，盡量實(shí)現(xiàn)覆蓋索引，避免回表。
僵尸進(jìn)程：
即子進(jìn)程先于父進(jìn)程退出后，子進(jìn)程的PCB需要其父進(jìn)程釋放，但是父進(jìn)程并沒(méi)有釋放子進(jìn)程的PCB，這樣的子進(jìn)程就稱為僵尸進(jìn)程，僵尸進(jìn)程實(shí)際上是一個(gè)已經(jīng)死掉的進(jìn)程。
孤兒進(jìn)程：
一個(gè)父進(jìn)程退出，而它的一個(gè)或多個(gè)子進(jìn)程還在運(yùn)行，那么那些子進(jìn)程將成為孤兒進(jìn)程。孤兒進(jìn)程將被init進(jìn)程(進(jìn)程號(hào)為1)所收養(yǎng)，并由init進(jìn)程對(duì)它們完成狀態(tài)收集工作。
子進(jìn)程死亡需要父進(jìn)程來(lái)處理，那么意味著正常的進(jìn)程應(yīng)該是子進(jìn)程先于父進(jìn)程死亡。當(dāng)父進(jìn)程先于子進(jìn)程死亡時(shí)，子進(jìn)程死亡時(shí)沒(méi)父進(jìn)程處理，這個(gè)死亡的子進(jìn)程就是孤兒進(jìn)程。
但孤兒進(jìn)程與僵尸進(jìn)程不同的是，由于父進(jìn)程已經(jīng)死亡，系統(tǒng)會(huì)幫助父進(jìn)程回收處理孤兒進(jìn)程。所以孤兒進(jìn)程實(shí)際上是不占用資源的，因?yàn)樗K究是被系統(tǒng)回收了。不會(huì)像僵尸進(jìn)程那樣占用ID,損害運(yùn)行系統(tǒng)。
原文鏈接：
產(chǎn)生死鎖的四個(gè)必要條件：
（1） 互斥條件：一個(gè)資源每次只能被一個(gè)進(jìn)程使用。
（2） 請(qǐng)求與保持條件：一個(gè)進(jìn)程因請(qǐng)求資源而阻塞時(shí)，對(duì)已獲得的資源保持不放。
（3） 不剝奪條件：進(jìn)程已獲得的資源，在末使用完之前，不能強(qiáng)行剝奪。
（4） 循環(huán)等待條件：若干進(jìn)程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系。
避免方法：
端口占用：lsof -i:端口號(hào) 或者 nestat
cpu、內(nèi)存占用：top
發(fā)送信號(hào)：kill -l 列出所有信號(hào)，然后用 kill [信號(hào)變化] [進(jìn)程號(hào)]來(lái)執(zhí)行。如kill -9 453。強(qiáng)制殺死453進(jìn)程
git log:查看提交記錄
git diff ：查看變更記錄
git merge：目標(biāo)分支改變，而源分支保持原樣。優(yōu)點(diǎn)：保留提交歷史，保留分支結(jié)構(gòu)。但會(huì)有大量的merge記錄
git rebase：將修改拼接到最新，復(fù)雜的記錄變得優(yōu)雅，單個(gè)操作變得(revert)很簡(jiǎn)單；缺點(diǎn)：
git revert:反做指定版本，會(huì)新生成一個(gè)版本
git reset:重置到某個(gè)版本，中間版本全部丟失
etcd、Consul
pprof
節(jié)省空間（非葉子節(jié)點(diǎn)不存儲(chǔ)數(shù)據(jù)，相對(duì)b tree的優(yōu)勢(shì)），減少I/O次數(shù)（節(jié)省的空間全部存指針地址，讓樹(shù)變的矮胖），范圍查找方便（相對(duì)hash的優(yōu)勢(shì)）。
explain
其他的見(jiàn)：
runtime2.go 中關(guān)于 p 的定義： 其中 runnext 指針決定了下一個(gè)要運(yùn)行的 g，根據(jù)英文的注釋大致意思是說(shuō)：
所以當(dāng)設(shè)置 runtime.GOMAXPROCS(1) 時(shí)，此時(shí)只有一個(gè) P，創(chuàng)建的 g 依次加入 P， 當(dāng)最后一個(gè)即 i==9 時(shí)，加入的最后 一個(gè) g 將會(huì)繼承當(dāng)前主 goroutinue 的剩余時(shí)間片繼續(xù)執(zhí)行，所以會(huì)先輸出 9， 之后再依次執(zhí)行 P 隊(duì)列中其它的 g。
方法一：
方法二：
[圖片上傳失敗...(image-4ef445-1594976286098)]
方法1：to_days，返回給的日期從0開(kāi)始算的天數(shù)。
方法2：data_add。向日期添加指定時(shí)間間隔
[圖片上傳失敗...(image-b67b10-1594976286098)]
重慶分公司
重慶分公司
