TiDB 是 PingCAP 自主研發(fā)的開源分布式關(guān)系型數(shù)據(jù)庫，具備商業(yè)級(jí)數(shù)據(jù)庫的數(shù)據(jù)可靠性，可用性，安全性等特性，支持在線彈性水平擴(kuò)展，兼容 MySQL 協(xié)議及生態(tài)，創(chuàng)新性實(shí)現(xiàn) OLTP 及 OLAP 融合。
創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),鐵嶺縣企業(yè)網(wǎng)站建設(shè),鐵嶺縣品牌網(wǎng)站建設(shè),網(wǎng)站定制,鐵嶺縣網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,鐵嶺縣網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
TiDB 3.0 版本顯著提升了大規(guī)模集群的穩(wěn)定性，集群支持 150+ 存儲(chǔ)節(jié)點(diǎn)，300+TB 存儲(chǔ)容量長期穩(wěn)定運(yùn)行。易用性方面引入大量降低用戶運(yùn)維成本的優(yōu)化，包括引入 Information_Schema 中的多個(gè)實(shí)用系統(tǒng)視圖、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特別是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升約 4.5 倍，Sysbench 性能提升約 1.5 倍，OLAP 方面，TPC-H 50G Q15 因?qū)崿F(xiàn) View 可以執(zhí)行，至此 TPC-H 22 個(gè) Query 均可正常運(yùn)行。新功能方面增加了窗口函數(shù)、視圖（實(shí)驗(yàn)特性）、分區(qū)表、插件系統(tǒng)、悲觀鎖（實(shí)驗(yàn)特性）。
截止本文發(fā)稿時(shí) TiDB 已在 500+ 用戶的生產(chǎn)環(huán)境中長期穩(wěn)定運(yùn)行，涵蓋金融、保險(xiǎn)、制造，互聯(lián)網(wǎng)， 游戲 等領(lǐng)域，涉及交易、數(shù)據(jù)中臺(tái)、 歷史 庫等多個(gè)業(yè)務(wù)場(chǎng)景。不同業(yè)務(wù)場(chǎng)景對(duì)關(guān)系型數(shù)據(jù)庫的訴求可用 “百花齊放”來形容，但對(duì)關(guān)系數(shù)據(jù)庫最根本的訴求未發(fā)生任何變化，如數(shù)據(jù)可靠性，系統(tǒng)穩(wěn)定性，可擴(kuò)展性，安全性，易用性等。請(qǐng)跟隨我們的腳步梳理 TiDB 3.0 有什么樣的驚喜。
3.0 與 2.1 版本相比，顯著提升了大規(guī)模集群的穩(wěn)定性，支持單集群 150+ 存儲(chǔ)節(jié)點(diǎn)，300+TB 存儲(chǔ)容量長期穩(wěn)定運(yùn)行，主要的優(yōu)化點(diǎn)如下：
1. 優(yōu)化 Raft 副本之間的心跳機(jī)制，按照 Region 的活躍程度調(diào)整心跳頻率，減小冷數(shù)據(jù)對(duì)集群的負(fù)擔(dān)。
2. 熱點(diǎn)調(diào)度策略支持更多參數(shù)配置，采用更高優(yōu)先級(jí)，并提升熱點(diǎn)調(diào)度的準(zhǔn)確性。
3. 優(yōu)化 PD 調(diào)度流程，提供調(diào)度限流機(jī)制，提升系統(tǒng)穩(wěn)定性。
4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 時(shí)間，提升系統(tǒng)穩(wěn)定性。
眾所周知，數(shù)據(jù)庫查詢計(jì)劃的穩(wěn)定性對(duì)業(yè)務(wù)至關(guān)重要，TiDB 3.0 版本采用多種優(yōu)化手段提升查詢計(jì)劃的穩(wěn)定性，如下：
1. 新增 Fast Analyze 功能，提升收集統(tǒng)計(jì)信息的速度，降低集群資源的消耗及對(duì)業(yè)務(wù)的影響。
2. 新增 Incremental Analyze 功能，提升收集單調(diào)遞增的索引統(tǒng)計(jì)信息的速度，降低集群資源的消耗及對(duì)業(yè)務(wù)的影響。
3. 在 CM-Sketch 中新增 TopN 的統(tǒng)計(jì)信息，緩解 CM-Sketch 哈希沖突導(dǎo)致估算偏大，提升代價(jià)估算的準(zhǔn)確性，提升查詢計(jì)劃的穩(wěn)定性。
4. 引入 Skyline Pruning 框架，利用規(guī)則防止查詢計(jì)劃過度依賴統(tǒng)計(jì)信息，緩解因統(tǒng)計(jì)信息滯后導(dǎo)致選擇的查詢計(jì)劃不是最優(yōu)的情況，提升查詢計(jì)劃的穩(wěn)定性。
5. 新增 SQL Plan Management 功能，支持在查詢計(jì)劃不準(zhǔn)確時(shí)手動(dòng)綁定查詢計(jì)劃，提升查詢計(jì)劃的穩(wěn)定性。
1. OLTP
3.0 與 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升約 1.5 倍，TPC-C 性能提升約 4.5 倍。主要的優(yōu)化點(diǎn)如下：
1. TiDB 持續(xù)優(yōu)化 SQL 執(zhí)行器，包括：優(yōu)化 NOT EXISTS 子查詢轉(zhuǎn)化為 Anti Semi Join，優(yōu)化多表 Join 時(shí) Join 順序選擇等。
2. 優(yōu)化 Index Join 邏輯，擴(kuò)大 Index Join 算子的適用場(chǎng)景并提升代價(jià)估算的準(zhǔn)確性。
3. TiKV 批量接收和發(fā)送消息功能，提升寫入密集的場(chǎng)景的 TPS 約 7%，讀密集的場(chǎng)景提升約 30%。
4. TiKV 優(yōu)化內(nèi)存管理，減少 Iterator Key Bound Option 的內(nèi)存分配和拷貝，多個(gè) Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。
5. 引入 Titan 存儲(chǔ)引擎插件，提升 Value 值超過 1KB 時(shí)性能，緩解 RocksDB 寫放大問題，減少磁盤 IO 的占用。
6. TiKV 新增多線程 Raftstore 和 Apply 功能，提升單節(jié)點(diǎn)內(nèi)可擴(kuò)展性，進(jìn)而提升單節(jié)點(diǎn)內(nèi)并發(fā)處理能力和資源利用率，降低延時(shí)，大幅提升集群寫入能力。
TiDB Lightning 性能與 2019 年年初相比提升 3 倍，從 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，優(yōu)化點(diǎn)，如下：
1. 提升 SQL 轉(zhuǎn)化成 KV Pairs 的性能，減少不必要的開銷。
2. 提升單表導(dǎo)入性能，單表支持批量導(dǎo)入。
3. 提升 TiKV-Importer 導(dǎo)入數(shù)據(jù)性能，支持將數(shù)據(jù)和索引分別導(dǎo)入。
4. TiKV-Importer 支持上傳 SST 文件限速功能。
RBAC（Role-Based Access Control，基于角色的權(quán)限訪問控制） 是商業(yè)系統(tǒng)中最常見的權(quán)限管理技術(shù)之一，通過 RBAC 思想可以構(gòu)建最簡單“用戶-角色-權(quán)限”的訪問權(quán)限控制模型。RBAC 中用戶與角色關(guān)聯(lián)，權(quán)限與角色關(guān)聯(lián)，角色與權(quán)限之間一般是多對(duì)多的關(guān)系，用戶通過成為什么樣的角色獲取該角色所擁有的權(quán)限，達(dá)到簡化權(quán)限管理的目的，通過此版本的迭代 RBAC 功能開發(fā)完成。
IP 白名單功能（企業(yè)版特性） ：TiDB 提供基于 IP 白名單實(shí)現(xiàn)網(wǎng)絡(luò)安全訪問控制，用戶可根據(jù)實(shí)際情況配置相關(guān)的訪問策略。
Audit log 功能（企業(yè)版特性） ：Audit log 記錄用戶對(duì)數(shù)據(jù)庫所執(zhí)行的操作，通過記錄 Audit log 用戶可以對(duì)數(shù)據(jù)庫進(jìn)行故障分析，行為分析，安全審計(jì)等，幫助用戶獲取數(shù)據(jù)執(zhí)行情況。
加密存儲(chǔ)（企業(yè)版特性） ：TiDB 利用 RocksDB 自身加密功能，實(shí)現(xiàn)加密存儲(chǔ)的功能，保證所有寫入到磁盤的數(shù)據(jù)都經(jīng)過加密，降低數(shù)據(jù)泄露的風(fēng)險(xiǎn)。
完善權(quán)限語句的權(quán)限檢查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 語句權(quán)限檢查。
1. 新增 SQL 方式查詢慢查詢，豐富 TiDB 慢查詢?nèi)罩緝?nèi)容，如：Coprocessor 任務(wù)數(shù)，平均/最長/90% 執(zhí)行/等待時(shí)間，執(zhí)行/等待時(shí)間最長的 TiKV 地址，簡化慢查詢定位工作，提高排查慢查詢問題效率，提升產(chǎn)品易用性。
2. 新增系統(tǒng)配置項(xiàng)合法性檢查，優(yōu)化系統(tǒng)監(jiān)控項(xiàng)等，提升產(chǎn)品易用性。
3. 新增對(duì) TableReader、IndexReader 和 IndexLookupReader 算子內(nèi)存使用情況統(tǒng)計(jì)信息，提高 Query 內(nèi)存使用統(tǒng)計(jì)的準(zhǔn)確性，提升處理內(nèi)存消耗較大語句的效率。
4. 制定日志規(guī)范，重構(gòu)日志系統(tǒng)，統(tǒng)一日志格式，方便用戶理解日志內(nèi)容，有助于通過工具對(duì)日志進(jìn)行定量分析。
5. 新增 EXPLAIN ANALYZE 功能，提升SQL 調(diào)優(yōu)的易用性。
6. 新增 SQL 語句 Trace 功能，方便排查問題。
7. 新增通過 unix_socket 方式連接數(shù)據(jù)庫。
8. 新增快速恢復(fù)被刪除表功能，當(dāng)誤刪除數(shù)據(jù)時(shí)可通過此功能快速恢復(fù)數(shù)據(jù)。
TiDB 3.0 新增 TiFlash 組件，解決復(fù)雜分析及 HTAP 場(chǎng)景。TiFlash 是列式存儲(chǔ)系統(tǒng)，與行存儲(chǔ)系統(tǒng)實(shí)時(shí)同步，具備低延時(shí)，高性能，事務(wù)一致性讀等特性。 通過 Raft 協(xié)議從 TiKV 中實(shí)時(shí)同步行存數(shù)據(jù)并轉(zhuǎn)化成列存儲(chǔ)格式持久化到一組獨(dú)立的節(jié)點(diǎn)，解決行列混合存儲(chǔ)以及資源隔離性問題。TiFlash 可用作行存儲(chǔ)系統(tǒng)（TiKV）實(shí)時(shí)鏡像，實(shí)時(shí)鏡像可獨(dú)立于行存儲(chǔ)系統(tǒng)，將行存儲(chǔ)及列存儲(chǔ)從物理隔離開，提供完善的資源隔離方案，HTAP 場(chǎng)景最優(yōu)推薦方案；亦可用作行存儲(chǔ)表的索引，配合行存儲(chǔ)對(duì)外提供智能的 OLAP 服務(wù)，提升約 10 倍復(fù)雜的混合查詢的性能。
TiFlash 目前處于 Beta 階段，計(jì)劃 2019 年 12 月 31 日之前 GA，歡迎大家申請(qǐng)?jiān)囉谩?/p>
未來我們會(huì)繼續(xù)投入到系統(tǒng)穩(wěn)定性，易用性，性能，彈性擴(kuò)展方面，向用戶提供極致的彈性伸縮能力，極致的性能體驗(yàn)，極致的用戶體驗(yàn)。
穩(wěn)定性方面 V4.0 版本將繼續(xù)完善 V3.0 未 GA 的重大特性，例如：悲觀事務(wù)模型，View，Table Partition，Titan 行存儲(chǔ)引擎，TiFlash 列存儲(chǔ)引擎；引入近似物理備份恢復(fù)解決分布數(shù)據(jù)庫備份恢復(fù)難題；優(yōu)化 PD 調(diào)度功能等。
性能方面 V4.0 版本將繼續(xù)優(yōu)化事務(wù)處理流程，減少事務(wù)資源消耗，提升性能，例如：1PC，省去獲取 commit ts 操作等。
彈性擴(kuò)展方面，PD 將提供彈性擴(kuò)展所需的元信息供外部系統(tǒng)調(diào)用，外部系統(tǒng)可根據(jù)元信息及負(fù)載情況動(dòng)態(tài)伸縮集群規(guī)模，達(dá)成節(jié)省成本的目標(biāo)。
我們相信戰(zhàn)勝“未知”最好的武器就是社區(qū)的力量，基礎(chǔ)軟件需要堅(jiān)定地走開源路線。截止發(fā)稿我們已經(jīng)完成 41 篇源碼閱讀文章。TiDB 開源社區(qū)總計(jì) 265 位 Contributor，6 位 Committer，在這里我們對(duì)社區(qū)貢獻(xiàn)者表示由衷的感謝，希望更多志同道合的人能加入進(jìn)來，也希望大家在 TiDB 這個(gè)開源社區(qū)能夠有所收獲。
TiDB 3.0 GA Release Notes：
為每個(gè)client fd開兩個(gè)goroutine，一個(gè)recv，一個(gè)send。同時(shí)還有加2個(gè)channel，一個(gè)用于recv routine向邏輯主線程傳送收到的數(shù)據(jù)，一個(gè)用于邏輯主線程向send goroutine傳送待發(fā)送的數(shù)據(jù)，是這樣的么？
實(shí)際上需要 3 個(gè) goroutine，一個(gè) read，一個(gè) send，還有一個(gè) handle。
read goroutine 讀，然后寫入 recevice chan。
write goroutine 把 send chan 的東西寫。
handle goroutine 是 conn 的主要處理邏輯，負(fù)責(zé)把 recevice chan 的東西讀出來 call 業(yè)務(wù)邏輯。
業(yè)務(wù)邏輯中要寫數(shù)據(jù)就直接寫入 send chan。
這樣就可以保證，業(yè)務(wù)邏輯的讀寫都是在 handle goroutine 上處理，而避免 race 產(chǎn)生。
如果需要定時(shí)任務(wù)（比如心跳），就在 handle goroutine 上加上一個(gè) timer.C；
如果需要 goroutine 下發(fā)任務(wù)，在 handle goroutine 增加一個(gè) task chan，hanlde 收到 task 后處理業(yè)務(wù)；
如果需要輸出結(jié)果，那就增加 result chan，業(yè)務(wù)邏輯把數(shù)據(jù)輸出即可。
----------------------------
還有，如果我開2個(gè)goroutine的話，client斷開連接了，假設(shè)recv goroutine先發(fā)生err并且close(fd)，那在send goroutine中該如何處理呢？有可能不應(yīng)該這樣處理，那應(yīng)該怎么處理呢？
如果 net.Conn Close() 了，不論 Read() 阻塞還是 Write() 阻塞都會(huì)立即收到 err 返回。
一般來說，Write() 是不可能主動(dòng)知道連接斷開的，除非是 SetDeadline() 猜測(cè)對(duì)方斷掉了，指定時(shí)間內(nèi)沒有寫成功就認(rèn)為是斷開。Read() 是可以主動(dòng)收到對(duì)方發(fā)來的斷開（TCP FIN），但也沒辦法知道異常的斷開（當(dāng)然也可以設(shè)置超時(shí)）。
無論是誰，是確實(shí)收到 FIN 還是 Deadline 猜測(cè)斷開，只要 Close() 大家就知道連接斷開了。
handle goroutine 還有一個(gè)用處就是：你的程序主動(dòng)結(jié)束的時(shí)候，能正確的 close conn，讓對(duì)方知道你是真的斷開了，而不用去猜。
mina與netty都是Trustin Lee的作品，所以在很多方面都十分相似，他們線程模型也是基本一致，采用了Reactors in threads模型，即Main Reactor + Sub Reactors的模式。由main reactor處理連接相關(guān)的任務(wù)：accept、connect等，當(dāng)連接處理完畢并建立
三次握手：
1. 主動(dòng)發(fā)起連接請(qǐng)求端（客戶端），發(fā)送 SYN 標(biāo)志位，攜帶數(shù)據(jù)包、包號(hào)
2. 被動(dòng)接收連接請(qǐng)求端（服務(wù)器），接收 SYN，回復(fù) ACK，攜帶應(yīng)答序列號(hào)。同時(shí)，發(fā)送SYN標(biāo)志位，攜帶數(shù)據(jù)包、包號(hào)
3. 主動(dòng)發(fā)起連接請(qǐng)求端（客戶端），接收SYN 標(biāo)志位，回復(fù) ACK。
被動(dòng)端（服務(wù)器）接收 ACK —— 標(biāo)志著 三次握手建立完成（ Accept()/Dial() 返回 ）
四次揮手：
1. 主動(dòng)請(qǐng)求斷開連接端（客戶端）， 發(fā)送 FIN標(biāo)志，攜帶數(shù)據(jù)包
2. 被動(dòng)接受斷開連接端（服務(wù)器）， 發(fā)送 ACK標(biāo)志，攜帶應(yīng)答序列號(hào)。 —— 半關(guān)閉完成。
3. 被動(dòng)接受斷開連接端（服務(wù)器）， 發(fā)送 FIN標(biāo)志，攜帶數(shù)據(jù)包
4. 主動(dòng)請(qǐng)求斷開連接端（客戶端）， 發(fā)送 最后一個(gè) ACK標(biāo)志，攜帶應(yīng)答序列號(hào)?！?發(fā)送完成，客戶端不會(huì)直接退出，等 2MSL時(shí)長。
等 2MSL待目的：確保服務(wù)器 收到最后一個(gè)ACK
滑動(dòng)窗口：
通知對(duì)端本地存儲(chǔ)數(shù)據(jù)的 緩沖區(qū)容量?！?write 函數(shù)在對(duì)端 緩沖區(qū)滿時(shí)，有可能阻塞。
TCP狀態(tài)轉(zhuǎn)換：
1. 主動(dòng)發(fā)起連接請(qǐng)求端：
CLOSED —— 發(fā)送SYN —— SYN_SENT(了解) —— 接收ACK、SYN，回發(fā) ACK —— ESTABLISHED (數(shù)據(jù)通信)
2. 主動(dòng)關(guān)閉連接請(qǐng)求端：
ESTABLISHED —— 發(fā)送FIN —— FIN_WAIT_1 —— 接收ACK —— FIN_WAIT_2 (半關(guān)閉、主動(dòng)端)
—— 接收FIN、回復(fù)ACK —— TIME_WAIT (主動(dòng)端) —— 等 2MSL 時(shí)長 —— CLOSED
3. 被動(dòng)建立連接請(qǐng)求端：
CLOSED —— LISTEN —— 接收SYN、發(fā)送ACK、SYN —— SYN_RCVD —— 接收 ACK —— ESTABLISHED (數(shù)據(jù)通信)
4. 被動(dòng)斷開連接請(qǐng)求端：
ESTABLISHED —— 接收 FIN、發(fā)送 ACK —— CLOSE_WAIT —— 發(fā)送 FIN —— LAST_ACK —— 接收ACK —— CLOSED
windows下查看TCP狀態(tài)轉(zhuǎn)換：
netstat -an | findstr? 端口號(hào)
Linux下查看TCP狀態(tài)轉(zhuǎn)換：
netstat -an | grep? 端口號(hào)
TCP和UDP對(duì)比:?
TCP: 面向連接的可靠的數(shù)據(jù)包傳遞。 針對(duì)不穩(wěn)定的 網(wǎng)絡(luò)層，完全彌補(bǔ)。ACK
UDP：無連接不可靠的報(bào)文傳輸。 針對(duì)不穩(wěn)定的 網(wǎng)絡(luò)層，完全不彌補(bǔ)。還原網(wǎng)絡(luò)真實(shí)狀態(tài)。
優(yōu)點(diǎn)???????????????????????????????????????????????????????????? 缺點(diǎn)
TCP： 可靠、順序、穩(wěn)定 ???????????????????????????????????? 系統(tǒng)資源消耗大，程序?qū)崿F(xiàn)繁復(fù)、速度慢
UDP：系統(tǒng)資源消耗小，程序?qū)崿F(xiàn)簡單、速度快 ???????????????????????? 不可靠、無序、不穩(wěn)定
使用場(chǎng)景：
TCP：大文件、可靠數(shù)據(jù)傳輸。 對(duì)數(shù)據(jù)的 穩(wěn)定性、準(zhǔn)確性、一致性要求較高的場(chǎng)合。
UDP：應(yīng)用于對(duì)數(shù)據(jù)時(shí)效性要求較高的場(chǎng)合。 網(wǎng)絡(luò)直播、電話會(huì)議、視頻直播、網(wǎng)絡(luò)游戲。
UDP-CS-Server實(shí)現(xiàn)流程：
1.? 創(chuàng)建 udp地址結(jié)構(gòu) ResolveUDPAddr(“協(xié)議”， “IP：port”) —— udpAddr 本質(zhì) struct{IP、port}
2.? 創(chuàng)建用于 數(shù)據(jù)通信的 socket ListenUDP(“協(xié)議”, udpAddr ) —— udpConn (socket)
3.? 從客戶端讀取數(shù)據(jù)，獲取對(duì)端的地址 udpConn.ReadFromUDP() —— 返回：n，clientAddr， err
4.? 發(fā)送數(shù)據(jù)包給 客戶端 udpConn.WriteToUDP("數(shù)據(jù)"， clientAddr)
UDP-CS-Client實(shí)現(xiàn)流程：
1.? 創(chuàng)建用于通信的 socket。 net.Dial("udp", "服務(wù)器IP：port") —— udpConn (socket)
2.? 以后流程參見 TCP客戶端實(shí)現(xiàn)源碼。
UDPserver默認(rèn)就支持并發(fā)！
------------------------------------
命令行參數(shù)： 在main函數(shù)啟動(dòng)時(shí)，向整個(gè)程序傳參。 【重點(diǎn)】
語法： go run xxx.go ? argv1 argv2? argv3? argv4 。。。
xxx.exe:? 第 0 個(gè)參數(shù)。
argv1 ：第 1 個(gè)參數(shù)。
argv2 ：第 2 個(gè)參數(shù)。
argv3 ：第 3 個(gè)參數(shù)。
argv4 ：第 4 個(gè)參數(shù)。
使用： list := os.Args? 提取所有命令行參數(shù)。
獲取文件屬性函數(shù)：
os.stat(文件訪問絕對(duì)路徑) —— fileInfo 接口
fileInfo 包含 兩個(gè)接口。
Name() 獲取文件名。 不帶訪問路徑
Size() 獲取文件大小。
網(wǎng)絡(luò)文件傳輸 —— 發(fā)送端（客戶端）
1.? 獲取命令行參數(shù)，得到文件名（帶路徑）filePath list := os.Args
2.? 使用 os.stat() 獲取 文件名（不帶路徑）fileName
3.? 創(chuàng)建 用于數(shù)據(jù)傳輸?shù)?socket? net.Dial("tcp"， “服務(wù)器IP+port”) —— conn
4.? 發(fā)送文件名(不帶路徑)? 給接收端， conn.write()
5.? 讀取 接收端回發(fā)“ok”，判斷無誤。封裝函數(shù) sendFile(filePath, conn) 發(fā)送文件內(nèi)容
6.? 實(shí)現(xiàn) sendFile(filePath,? conn)
1) 只讀打開文件 os.Open(filePath)
for {
2) 從文件中讀數(shù)據(jù)? f.Read(buf)
3) 將讀到的數(shù)據(jù)寫到socket中? conn.write(buf[:n])
4）判斷讀取文件的 結(jié)尾。 io.EOF. 跳出循環(huán)
}
網(wǎng)絡(luò)文件傳輸 —— 接收端（服務(wù)器）
1. 創(chuàng)建用于監(jiān)聽的 socket net.Listen() —— listener
2. 借助listener 創(chuàng)建用于 通信的 socket listener.Accpet()? —— conn
3. 讀取 conn.read() 發(fā)送端的 文件名， 保存至本地。
4. 回發(fā) “ok”應(yīng)答 發(fā)送端。
5. 封裝函數(shù)，接收文件內(nèi)容 recvFile(文件路徑)
1) f = os.Create(帶有路徑的文件名)
for {
2）從 socket中讀取發(fā)送端發(fā)送的 文件內(nèi)容 。 conn.read(buf)
3)? 將讀到的數(shù)據(jù) 保存至本地文件 f.Write(buf[:n])
4)? 判斷 讀取conn 結(jié)束， 代表文件傳輸完成。 n == 0? break
}
socket代理又分為socket4和sockt5代理，其中socket4只能支持TCP協(xié)議，而socket5則同時(shí)支持TCP協(xié)議和UDP協(xié)議。
Go 語言之所以叫 Go，是想表達(dá)這門語言的運(yùn)行速度、開發(fā)速度、學(xué)習(xí)速度（develop）都像 gopher 一樣快。
gopher 是一種生活在加拿大的小動(dòng)物，Go 語言的吉祥物就是這個(gè)小動(dòng)物， 它的中文名叫作囊地鼠，他們最大的特點(diǎn)就是挖洞速度特別快。
Go 語言吉祥物是才華橫溢的插畫家 Renee French 設(shè)計(jì)的，她也是 golang 設(shè)計(jì)者之一 Rob Pike 的妻子。
重慶分公司
重慶分公司
