1、簡單易學。
在福山等地區(qū)，都構建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供網(wǎng)站建設、網(wǎng)站設計 網(wǎng)站設計制作按需設計網(wǎng)站,公司網(wǎng)站建設,企業(yè)網(wǎng)站建設,品牌網(wǎng)站設計,營銷型網(wǎng)站,成都外貿(mào)網(wǎng)站制作,福山網(wǎng)站建設費用合理。
Go語言的作者本身就很懂C語言，所以同樣Go語言也會有C語言的基因，所以對于程序員來說，Go語言天生就會讓人很熟悉，容易上手。
2、并發(fā)性好。
Go語言天生支持并發(fā)，可以充分利用多核，輕松地使用并發(fā)。 這是Go語言最大的特點。
描述
Go的語法接近C語言，但對于變量的聲明有所不同。Go支持垃圾回收功能。Go的并行模型是以東尼·霍爾的通信順序進程（CSP）為基礎，采取類似模型的其他語言包括Occam和Limbo，但它也具有Pi運算的特征，比如通道傳輸。
在1.8版本中開放插件（Plugin）的支持，這意味著現(xiàn)在能從Go中動態(tài)加載部分函數(shù)。
與C++相比，Go并不包括如枚舉、異常處理、繼承、泛型、斷言、虛函數(shù)等功能，但增加了 切片(Slice) 型、并發(fā)、管道、垃圾回收、接口（Interface）等特性的語言級支持。
這個項目已經(jīng)封裝了 golang版本的red-lock
注意以下幾點就行了：
1.red-lock貌似得你單獨拎出1臺以上的相互獨立的redis出來，也就是它們間沒有任務聯(lián)系。這有點尷尬，所以redis去實現(xiàn)分布式鎖你最好再想個兜底的。。。比如說用mysql多版本再原子性的控制一下（之所以說mysql是因為一般的項目都有mysql+redis）
3.如果各方面要求都很高就換一種方案吧，比如說 消息隊列，但就又引入了新的東西。。。
本文目錄如下，閱讀本文后，將一網(wǎng)打盡下面Golang Map相關面試題
Go中的map是一個指針，占用8個字節(jié)，指向hmap結構體; 源碼 src/runtime/map.go 中可以看到map的底層結構
每個map的底層結構是hmap，hmap包含若干個結構為bmap的bucket數(shù)組。每個bucket底層都采用鏈表結構。接下來，我們來詳細看下map的結構
bmap 就是我們常說的“桶”，一個桶里面會最多裝 8 個 key，這些 key 之所以會落入同一個桶，是因為它們經(jīng)過哈希計算后，哈希結果是“一類”的，關于key的定位我們在map的查詢和插入中詳細說明。在桶內(nèi)，又會根據(jù) key 計算出來的 hash 值的高 8 位來決定 key 到底落入桶內(nèi)的哪個位置（一個桶內(nèi)最多有8個位置)。
bucket內(nèi)存數(shù)據(jù)結構可視化如下：
注意到 key 和 value 是各自放在一起的，并不是 key/value/key/value/... 這樣的形式。源碼里說明這樣的好處是在某些情況下可以省略掉 padding字段，節(jié)省內(nèi)存空間。
當 map 的 key 和 value 都不是指針，并且 size 都小于 128 字節(jié)的情況下，會把 bmap 標記為不含指針，這樣可以避免 gc 時掃描整個 hmap。但是，我們看 bmap 其實有一個 overflow 的字段，是指針類型的，破壞了 bmap 不含指針的設想，這時會把 overflow 移動到 extra 字段來。
map是個指針，底層指向hmap，所以是個引用類型
golang 有三個常用的高級類型 slice 、map、channel, 它們都是 引用類型 ，當引用類型作為函數(shù)參數(shù)時，可能會修改原內(nèi)容數(shù)據(jù)。
golang 中沒有引用傳遞，只有值和指針傳遞。所以 map 作為函數(shù)實參傳遞時本質(zhì)上也是值傳遞，只不過因為 map 底層數(shù)據(jù)結構是通過指針指向?qū)嶋H的元素存儲空間，在被調(diào)函數(shù)中修改 map，對調(diào)用者同樣可見，所以 map 作為函數(shù)實參傳遞時表現(xiàn)出了引用傳遞的效果。
因此，傳遞 map 時，如果想修改map的內(nèi)容而不是map本身，函數(shù)形參無需使用指針
map 底層數(shù)據(jù)結構是通過指針指向?qū)嶋H的元素 存儲空間 ，這種情況下，對其中一個map的更改，會影響到其他map
map 在沒有被修改的情況下，使用 range 多次遍歷 map 時輸出的 key 和 value 的順序可能不同。這是 Go 語言的設計者們有意為之，在每次 range 時的順序被隨機化，旨在提示開發(fā)者們，Go 底層實現(xiàn)并不保證 map 遍歷順序穩(wěn)定，請大家不要依賴 range 遍歷結果順序。
map 本身是無序的，且遍歷時順序還會被隨機化，如果想順序遍歷 map，需要對 map key 先排序，再按照 key 的順序遍歷 map。
map默認是并發(fā)不安全的，原因如下：
Go 官方在經(jīng)過了長時間的討論后，認為 Go map 更應適配典型使用場景（不需要從多個 goroutine 中進行安全訪問），而不是為了小部分情況（并發(fā)訪問），導致大部分程序付出加鎖代價（性能），決定了不支持。
場景: 2個協(xié)程同時讀和寫，以下程序會出現(xiàn)致命錯誤：fatal error: concurrent map writes
如果想實現(xiàn)map線程安全，有兩種方式：
方式一：使用讀寫鎖 map + sync.RWMutex
方式二：使用golang提供的 sync.Map
sync.map是用讀寫分離實現(xiàn)的，其思想是空間換時間。和map+RWLock的實現(xiàn)方式相比，它做了一些優(yōu)化：可以無鎖訪問read map，而且會優(yōu)先操作read map，倘若只操作read map就可以滿足要求(增刪改查遍歷)，那就不用去操作write map(它的讀寫都要加鎖)，所以在某些特定場景中它發(fā)生鎖競爭的頻率會遠遠小于map+RWLock的實現(xiàn)方式。
golang中map是一個kv對集合。底層使用hash table，用鏈表來解決沖突 ，出現(xiàn)沖突時，不是每一個key都申請一個結構通過鏈表串起來，而是以bmap為最小粒度掛載，一個bmap可以放8個kv。在哈希函數(shù)的選擇上，會在程序啟動時，檢測 cpu 是否支持 aes，如果支持，則使用 aes hash，否則使用 memhash。
map有3鐘初始化方式，一般通過make方式創(chuàng)建
map的創(chuàng)建通過生成匯編碼可以知道，make創(chuàng)建map時調(diào)用的底層函數(shù)是 runtime.makemap 。如果你的map初始容量小于等于8會發(fā)現(xiàn)走的是 runtime.fastrand 是因為容量小于8時不需要生成多個桶，一個桶的容量就可以滿足
makemap函數(shù)會通過 fastrand 創(chuàng)建一個隨機的哈希種子，然后根據(jù)傳入的 hint 計算出需要的最小需要的桶的數(shù)量，最后再使用 makeBucketArray 創(chuàng)建用于保存桶的數(shù)組，這個方法其實就是根據(jù)傳入的 B 計算出的需要創(chuàng)建的桶數(shù)量在內(nèi)存中分配一片連續(xù)的空間用于存儲數(shù)據(jù)，在創(chuàng)建桶的過程中還會額外創(chuàng)建一些用于保存溢出數(shù)據(jù)的桶，數(shù)量是 2^(B-4) 個。初始化完成返回hmap指針。
找到一個 B，使得 map 的裝載因子在正常范圍內(nèi)
Go 語言中讀取 map 有兩種語法：帶 comma 和 不帶 comma。當要查詢的 key 不在 map 里，帶 comma 的用法會返回一個 bool 型變量提示 key 是否在 map 中；而不帶 comma 的語句則會返回一個 value 類型的零值。如果 value 是 int 型就會返回 0，如果 value 是 string 類型，就會返回空字符串。
map的查找通過生成匯編碼可以知道，根據(jù) key 的不同類型，編譯器會將查找函數(shù)用更具體的函數(shù)替換，以優(yōu)化效率：
函數(shù)首先會檢查 map 的標志位 flags。如果 flags 的寫標志位此時被置 1 了，說明有其他協(xié)程在執(zhí)行“寫”操作，進而導致程序 panic。這也說明了 map 對協(xié)程是不安全的。
key經(jīng)過哈希函數(shù)計算后，得到的哈希值如下（主流64位機下共 64 個 bit 位）：
m: 桶的個數(shù)
從buckets 通過 hash m 得到對應的bucket，如果bucket正在擴容，并且沒有擴容完成，則從oldbuckets得到對應的bucket
計算hash所在桶編號：
用上一步哈希值最后的 5 個 bit 位，也就是 01010 ，值為 10，也就是 10 號桶（范圍是0~31號桶）
計算hash所在的槽位:
用上一步哈希值哈希值的高8個bit 位，也就是 10010111 ，轉(zhuǎn)化為十進制，也就是151，在 10 號 bucket 中尋找** tophash 值（HOB hash）為 151* 的 槽位**，即為key所在位置，找到了 2 號槽位，這樣整個查找過程就結束了。
如果在 bucket 中沒找到，并且 overflow 不為空，還要繼續(xù)去 overflow bucket 中尋找，直到找到或是所有的 key 槽位都找遍了，包括所有的 overflow bucket。
通過上面找到了對應的槽位，這里我們再詳細分析下key/value值是如何獲取的：
bucket 里 key 的起始地址就是 unsafe.Pointer(b)+dataOffset。第 i 個 key 的地址就要在此基礎上跨過 i 個 key 的大?。欢覀冇种?，value 的地址是在所有 key 之后，因此第 i 個 value 的地址還需要加上所有 key 的偏移。
通過匯編語言可以看到，向 map 中插入或者修改 key，最終調(diào)用的是 mapassign 函數(shù)。
實際上插入或修改 key 的語法是一樣的，只不過前者操作的 key 在 map 中不存在，而后者操作的 key 存在 map 中。
mapassign 有一個系列的函數(shù)，根據(jù) key 類型的不同，編譯器會將其優(yōu)化為相應的“快速函數(shù)”。
我們只用研究最一般的賦值函數(shù) mapassign 。
map的賦值會附帶著map的擴容和遷移，map的擴容只是將底層數(shù)組擴大了一倍，并沒有進行數(shù)據(jù)的轉(zhuǎn)移，數(shù)據(jù)的轉(zhuǎn)移是在擴容后逐步進行的，在遷移的過程中每進行一次賦值（access或者delete）會至少做一次遷移工作。
1.判斷map是否為nil
每一次進行賦值/刪除操作時，只要oldbuckets != nil 則認為正在擴容，會做一次遷移工作，下面會詳細說下遷移過程
根據(jù)上面查找過程，查找key所在位置，如果找到則更新，沒找到則找空位插入即可
經(jīng)過前面迭代尋找動作，若沒有找到可插入的位置，意味著需要擴容進行插入，下面會詳細說下擴容過程
通過匯編語言可以看到，向 map 中刪除 key，最終調(diào)用的是 mapdelete 函數(shù)
刪除的邏輯相對比較簡單，大多函數(shù)在賦值操作中已經(jīng)用到過，核心還是找到 key 的具體位置。尋找過程都是類似的，在 bucket 中挨個 cell 尋找。找到對應位置后，對 key 或者 value 進行“清零”操作，將 count 值減 1，將對應位置的 tophash 值置成 Empty
再來說觸發(fā) map 擴容的時機：在向 map 插入新 key 的時候，會進行條件檢測，符合下面這 2 個條件，就會觸發(fā)擴容：
1、裝載因子超過閾值
源碼里定義的閾值是 6.5 (loadFactorNum/loadFactorDen)，是經(jīng)過測試后取出的一個比較合理的因子
我們知道，每個 bucket 有 8 個空位，在沒有溢出，且所有的桶都裝滿了的情況下，裝載因子算出來的結果是 8。因此當裝載因子超過 6.5 時，表明很多 bucket 都快要裝滿了，查找效率和插入效率都變低了。在這個時候進行擴容是有必要的。
對于條件 1，元素太多，而 bucket 數(shù)量太少，很簡單：將 B 加 1，bucket 最大數(shù)量( 2^B )直接變成原來 bucket 數(shù)量的 2 倍。于是，就有新老 bucket 了。注意，這時候元素都在老 bucket 里，還沒遷移到新的 bucket 來。新 bucket 只是最大數(shù)量變?yōu)樵瓉碜畲髷?shù)量的 2 倍( 2^B * 2 ) 。
2、overflow 的 bucket 數(shù)量過多
在裝載因子比較小的情況下，這時候 map 的查找和插入效率也很低，而第 1 點識別不出來這種情況。表面現(xiàn)象就是計算裝載因子的分子比較小，即 map 里元素總數(shù)少，但是 bucket 數(shù)量多（真實分配的 bucket 數(shù)量多，包括大量的 overflow bucket）
不難想像造成這種情況的原因：不停地插入、刪除元素。先插入很多元素，導致創(chuàng)建了很多 bucket，但是裝載因子達不到第 1 點的臨界值，未觸發(fā)擴容來緩解這種情況。之后，刪除元素降低元素總數(shù)量，再插入很多元素，導致創(chuàng)建很多的 overflow bucket，但就是不會觸發(fā)第 1 點的規(guī)定，你能拿我怎么辦？overflow bucket 數(shù)量太多，導致 key 會很分散，查找插入效率低得嚇人，因此出臺第 2 點規(guī)定。這就像是一座空城，房子很多，但是住戶很少，都分散了，找起人來很困難
對于條件 2，其實元素沒那么多，但是 overflow bucket 數(shù)特別多，說明很多 bucket 都沒裝滿。解決辦法就是開辟一個新 bucket 空間，將老 bucket 中的元素移動到新 bucket，使得同一個 bucket 中的 key 排列地更緊密。這樣，原來，在 overflow bucket 中的 key 可以移動到 bucket 中來。結果是節(jié)省空間，提高 bucket 利用率，map 的查找和插入效率自然就會提升。
由于 map 擴容需要將原有的 key/value 重新搬遷到新的內(nèi)存地址，如果有大量的 key/value 需要搬遷，會非常影響性能。因此 Go map 的擴容采取了一種稱為“漸進式”的方式，原有的 key 并不會一次性搬遷完畢，每次最多只會搬遷 2 個 bucket。
上面說的 hashGrow() 函數(shù)實際上并沒有真正地“搬遷”，它只是分配好了新的 buckets，并將老的 buckets 掛到了 oldbuckets 字段上。真正搬遷 buckets 的動作在 growWork() 函數(shù)中，而調(diào)用 growWork() 函數(shù)的動作是在 mapassign 和 mapdelete 函數(shù)中。也就是插入或修改、刪除 key 的時候，都會嘗試進行搬遷 buckets 的工作。先檢查 oldbuckets 是否搬遷完畢，具體來說就是檢查 oldbuckets 是否為 nil。
如果未遷移完畢，賦值/刪除的時候，擴容完畢后（預分配內(nèi)存），不會馬上就進行遷移。而是采取 增量擴容 的方式，當有訪問到具體 bukcet 時，才會逐漸的進行遷移（將 oldbucket 遷移到 bucket）
nevacuate 標識的是當前的進度，如果都搬遷完，應該和2^B的長度是一樣的
在evacuate 方法實現(xiàn)是把這個位置對應的bucket，以及其沖突鏈上的數(shù)據(jù)都轉(zhuǎn)移到新的buckets上。
轉(zhuǎn)移的判斷直接通過tophash 就可以，判斷tophash中第一個hash值即可
遍歷的過程，就是按順序遍歷 bucket，同時按順序遍歷 bucket 中的 key。
map遍歷是無序的，如果想實現(xiàn)有序遍歷，可以先對key進行排序
為什么遍歷 map 是無序的？
如果發(fā)生過遷移，key 的位置發(fā)生了重大的變化，有些 key 飛上高枝，有些 key 則原地不動。這樣，遍歷 map 的結果就不可能按原來的順序了。
如果就一個寫死的 map，不會向 map 進行插入刪除的操作，按理說每次遍歷這樣的 map 都會返回一個固定順序的 key/value 序列吧。但是 Go 杜絕了這種做法，因為這樣會給新手程序員帶來誤解，以為這是一定會發(fā)生的事情，在某些情況下，可能會釀成大錯。
Go 做得更絕，當我們在遍歷 map 時，并不是固定地從 0 號 bucket 開始遍歷，每次都是從一個**隨機值序號的 bucket 開始遍歷，并且是從這個 bucket 的一個 隨機序號的 cell **開始遍歷。這樣，即使你是一個寫死的 map，僅僅只是遍歷它，也不太可能會返回一個固定序列的 key/value 對了。
TiDB 是 PingCAP 自主研發(fā)的開源分布式關系型數(shù)據(jù)庫，具備商業(yè)級數(shù)據(jù)庫的數(shù)據(jù)可靠性，可用性，安全性等特性，支持在線彈性水平擴展，兼容 MySQL 協(xié)議及生態(tài)，創(chuàng)新性實現(xiàn) OLTP 及 OLAP 融合。
TiDB 3.0 版本顯著提升了大規(guī)模集群的穩(wěn)定性，集群支持 150+ 存儲節(jié)點，300+TB 存儲容量長期穩(wěn)定運行。易用性方面引入大量降低用戶運維成本的優(yōu)化，包括引入 Information_Schema 中的多個實用系統(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 個 Query 均可正常運行。新功能方面增加了窗口函數(shù)、視圖（實驗特性）、分區(qū)表、插件系統(tǒng)、悲觀鎖（實驗特性）。
截止本文發(fā)稿時 TiDB 已在 500+ 用戶的生產(chǎn)環(huán)境中長期穩(wěn)定運行，涵蓋金融、保險、制造，互聯(lián)網(wǎng)， 游戲 等領域，涉及交易、數(shù)據(jù)中臺、 歷史 庫等多個業(yè)務場景。不同業(yè)務場景對關系型數(shù)據(jù)庫的訴求可用 “百花齊放”來形容，但對關系數(shù)據(jù)庫最根本的訴求未發(fā)生任何變化，如數(shù)據(jù)可靠性，系統(tǒng)穩(wěn)定性，可擴展性，安全性，易用性等。請跟隨我們的腳步梳理 TiDB 3.0 有什么樣的驚喜。
3.0 與 2.1 版本相比，顯著提升了大規(guī)模集群的穩(wěn)定性，支持單集群 150+ 存儲節(jié)點，300+TB 存儲容量長期穩(wěn)定運行，主要的優(yōu)化點如下：
1. 優(yōu)化 Raft 副本之間的心跳機制，按照 Region 的活躍程度調(diào)整心跳頻率，減小冷數(shù)據(jù)對集群的負擔。
2. 熱點調(diào)度策略支持更多參數(shù)配置，采用更高優(yōu)先級，并提升熱點調(diào)度的準確性。
3. 優(yōu)化 PD 調(diào)度流程，提供調(diào)度限流機制，提升系統(tǒng)穩(wěn)定性。
4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 時間，提升系統(tǒng)穩(wěn)定性。
眾所周知，數(shù)據(jù)庫查詢計劃的穩(wěn)定性對業(yè)務至關重要，TiDB 3.0 版本采用多種優(yōu)化手段提升查詢計劃的穩(wěn)定性，如下：
1. 新增 Fast Analyze 功能，提升收集統(tǒng)計信息的速度，降低集群資源的消耗及對業(yè)務的影響。
2. 新增 Incremental Analyze 功能，提升收集單調(diào)遞增的索引統(tǒng)計信息的速度，降低集群資源的消耗及對業(yè)務的影響。
3. 在 CM-Sketch 中新增 TopN 的統(tǒng)計信息，緩解 CM-Sketch 哈希沖突導致估算偏大，提升代價估算的準確性，提升查詢計劃的穩(wěn)定性。
4. 引入 Skyline Pruning 框架，利用規(guī)則防止查詢計劃過度依賴統(tǒng)計信息，緩解因統(tǒng)計信息滯后導致選擇的查詢計劃不是最優(yōu)的情況，提升查詢計劃的穩(wěn)定性。
5. 新增 SQL Plan Management 功能，支持在查詢計劃不準確時手動綁定查詢計劃，提升查詢計劃的穩(wěn)定性。
1. OLTP
3.0 與 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升約 1.5 倍，TPC-C 性能提升約 4.5 倍。主要的優(yōu)化點如下：
1. TiDB 持續(xù)優(yōu)化 SQL 執(zhí)行器，包括：優(yōu)化 NOT EXISTS 子查詢轉(zhuǎn)化為 Anti Semi Join，優(yōu)化多表 Join 時 Join 順序選擇等。
2. 優(yōu)化 Index Join 邏輯，擴大 Index Join 算子的適用場景并提升代價估算的準確性。
3. TiKV 批量接收和發(fā)送消息功能，提升寫入密集的場景的 TPS 約 7%，讀密集的場景提升約 30%。
4. TiKV 優(yōu)化內(nèi)存管理，減少 Iterator Key Bound Option 的內(nèi)存分配和拷貝，多個 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。
5. 引入 Titan 存儲引擎插件，提升 Value 值超過 1KB 時性能，緩解 RocksDB 寫放大問題，減少磁盤 IO 的占用。
6. TiKV 新增多線程 Raftstore 和 Apply 功能，提升單節(jié)點內(nèi)可擴展性，進而提升單節(jié)點內(nèi)并發(fā)處理能力和資源利用率，降低延時，大幅提升集群寫入能力。
TiDB Lightning 性能與 2019 年年初相比提升 3 倍，從 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，優(yōu)化點，如下：
1. 提升 SQL 轉(zhuǎn)化成 KV Pairs 的性能，減少不必要的開銷。
2. 提升單表導入性能，單表支持批量導入。
3. 提升 TiKV-Importer 導入數(shù)據(jù)性能，支持將數(shù)據(jù)和索引分別導入。
4. TiKV-Importer 支持上傳 SST 文件限速功能。
RBAC（Role-Based Access Control，基于角色的權限訪問控制） 是商業(yè)系統(tǒng)中最常見的權限管理技術之一，通過 RBAC 思想可以構建最簡單“用戶-角色-權限”的訪問權限控制模型。RBAC 中用戶與角色關聯(lián)，權限與角色關聯(lián)，角色與權限之間一般是多對多的關系，用戶通過成為什么樣的角色獲取該角色所擁有的權限，達到簡化權限管理的目的，通過此版本的迭代 RBAC 功能開發(fā)完成。
IP 白名單功能（企業(yè)版特性） ：TiDB 提供基于 IP 白名單實現(xiàn)網(wǎng)絡安全訪問控制，用戶可根據(jù)實際情況配置相關的訪問策略。
Audit log 功能（企業(yè)版特性） ：Audit log 記錄用戶對數(shù)據(jù)庫所執(zhí)行的操作，通過記錄 Audit log 用戶可以對數(shù)據(jù)庫進行故障分析，行為分析，安全審計等，幫助用戶獲取數(shù)據(jù)執(zhí)行情況。
加密存儲（企業(yè)版特性） ：TiDB 利用 RocksDB 自身加密功能，實現(xiàn)加密存儲的功能，保證所有寫入到磁盤的數(shù)據(jù)都經(jīng)過加密，降低數(shù)據(jù)泄露的風險。
完善權限語句的權限檢查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 語句權限檢查。
1. 新增 SQL 方式查詢慢查詢，豐富 TiDB 慢查詢?nèi)罩緝?nèi)容，如：Coprocessor 任務數(shù)，平均/最長/90% 執(zhí)行/等待時間，執(zhí)行/等待時間最長的 TiKV 地址，簡化慢查詢定位工作，提高排查慢查詢問題效率，提升產(chǎn)品易用性。
2. 新增系統(tǒng)配置項合法性檢查，優(yōu)化系統(tǒng)監(jiān)控項等，提升產(chǎn)品易用性。
3. 新增對 TableReader、IndexReader 和 IndexLookupReader 算子內(nèi)存使用情況統(tǒng)計信息，提高 Query 內(nèi)存使用統(tǒng)計的準確性，提升處理內(nèi)存消耗較大語句的效率。
4. 制定日志規(guī)范，重構日志系統(tǒng)，統(tǒng)一日志格式，方便用戶理解日志內(nèi)容，有助于通過工具對日志進行定量分析。
5. 新增 EXPLAIN ANALYZE 功能，提升SQL 調(diào)優(yōu)的易用性。
6. 新增 SQL 語句 Trace 功能，方便排查問題。
7. 新增通過 unix_socket 方式連接數(shù)據(jù)庫。
8. 新增快速恢復被刪除表功能，當誤刪除數(shù)據(jù)時可通過此功能快速恢復數(shù)據(jù)。
TiDB 3.0 新增 TiFlash 組件，解決復雜分析及 HTAP 場景。TiFlash 是列式存儲系統(tǒng)，與行存儲系統(tǒng)實時同步，具備低延時，高性能，事務一致性讀等特性。 通過 Raft 協(xié)議從 TiKV 中實時同步行存數(shù)據(jù)并轉(zhuǎn)化成列存儲格式持久化到一組獨立的節(jié)點，解決行列混合存儲以及資源隔離性問題。TiFlash 可用作行存儲系統(tǒng)（TiKV）實時鏡像，實時鏡像可獨立于行存儲系統(tǒng)，將行存儲及列存儲從物理隔離開，提供完善的資源隔離方案，HTAP 場景最優(yōu)推薦方案；亦可用作行存儲表的索引，配合行存儲對外提供智能的 OLAP 服務，提升約 10 倍復雜的混合查詢的性能。
TiFlash 目前處于 Beta 階段，計劃 2019 年 12 月 31 日之前 GA，歡迎大家申請試用。
未來我們會繼續(xù)投入到系統(tǒng)穩(wěn)定性，易用性，性能，彈性擴展方面，向用戶提供極致的彈性伸縮能力，極致的性能體驗，極致的用戶體驗。
穩(wěn)定性方面 V4.0 版本將繼續(xù)完善 V3.0 未 GA 的重大特性，例如：悲觀事務模型，View，Table Partition，Titan 行存儲引擎，TiFlash 列存儲引擎；引入近似物理備份恢復解決分布數(shù)據(jù)庫備份恢復難題；優(yōu)化 PD 調(diào)度功能等。
性能方面 V4.0 版本將繼續(xù)優(yōu)化事務處理流程，減少事務資源消耗，提升性能，例如：1PC，省去獲取 commit ts 操作等。
彈性擴展方面，PD 將提供彈性擴展所需的元信息供外部系統(tǒng)調(diào)用，外部系統(tǒng)可根據(jù)元信息及負載情況動態(tài)伸縮集群規(guī)模，達成節(jié)省成本的目標。
我們相信戰(zhàn)勝“未知”最好的武器就是社區(qū)的力量，基礎軟件需要堅定地走開源路線。截止發(fā)稿我們已經(jīng)完成 41 篇源碼閱讀文章。TiDB 開源社區(qū)總計 265 位 Contributor，6 位 Committer，在這里我們對社區(qū)貢獻者表示由衷的感謝，希望更多志同道合的人能加入進來，也希望大家在 TiDB 這個開源社區(qū)能夠有所收獲。
TiDB 3.0 GA Release Notes：
1. 保留但大幅度簡化指針
Go語言保留著C中值和指針的區(qū)別，但是對于指針繁瑣用法進行了大量的簡化，引入引用的概念。所以在Go語言中，你幾乎不用擔心會因為直接操作內(nèi)寸而引起各式各樣的錯誤。
2. 多參數(shù)返回
還記得在C里面為了回饋多個參數(shù)，不得不開辟幾段指針傳到目標函數(shù)中讓其操作么？在Go里面這是完全不必要的。而且多參數(shù)的支持讓Go無需使用繁瑣的exceptions體系，一個函數(shù)可以返回期待的返回值加上error，調(diào)用函數(shù)后立刻處理錯誤信息，清晰明了。
3. Array，slice，map等內(nèi)置基本數(shù)據(jù)結構
如果你習慣了Python中簡潔的list和dict操作，在Go語言中，你不會感到孤單。一切都是那么熟悉，而且更加高效。如果你是C++程序員，你會發(fā)現(xiàn)你又找到了STL的vector 和 map這對朋友。
4. Interface
Go語言最讓人贊嘆不易的特性，就是interface的設計。任何數(shù)據(jù)結構，只要實現(xiàn)了interface所定義的函數(shù)，自動就implement了這個interface，沒有像Java那樣冗長的class申明，提供了靈活太多的設計度和OO抽象度，讓你的代碼也非常干凈。千萬不要以為你習慣了Java那種一條一條加implements的方式，感覺還行，等接口的設計越來越復雜的時候，無數(shù)Bug正在后面等著你。
同時，正因為如此，Go語言的interface可以用來表示任何generic的東西，比如一個空的interface，可以是string可以是int，可以是任何數(shù)據(jù)類型，因為這些數(shù)據(jù)類型都不需要實現(xiàn)任何函數(shù)，自然就滿足空interface的定義了。加上Go語言的type assertion，可以提供一般動態(tài)語言才有的duck typing特性， 而仍然能在compile中捕捉明顯的錯誤。
5. OO
Go語言本質(zhì)上不是面向?qū)ο笳Z言，它還是過程化的。但是，在Go語言中， 你可以很輕易的做大部分你在別的OO語言中能做的事，用更簡單清晰的邏輯。是的，在這里，不需要class，仍然可以繼承，仍然可以多態(tài)，但是速度卻快得多。因為本質(zhì)上，OO在Go語言中，就是普通的struct操作。
6. Goroutine
這個幾乎算是Go語言的招牌特性之一了，我也不想多提。如果你完全不了解Goroutine，那么你只需要知道，這玩意是超級輕量級的類似線程的東西，但通過它，你不需要復雜的線程操作鎖操作，不需要care調(diào)度，就能玩轉(zhuǎn)基本的并行程序。在Go語言里，觸發(fā)一個routine和erlang spawn一樣簡單?；旧弦莆誈o語言，以Goroutine和channel為核心的內(nèi)存模型是必須要懂的。不過請放心，真的非常簡單。
7. 更多現(xiàn)代的特性
和C比較，Go語言完全就是一門現(xiàn)代化語言，原生支持的Unicode, garbage collection, Closures(是的，和functional programming language類似), function是first class object，等等等等。
看到這里，你可能會發(fā)現(xiàn)，我用了很多輕易，簡單，快速之類的形容詞來形容Go語言的特點。我想說的是，一點都不夸張，連Go語言的入門學習到提高，都比別的語言門檻低太多太多。在大部分人都有C的背景的時代，對于Go語言，從入門到能夠上手做項目，最多不過半個月。Go語言給人的感覺就是太直接了，什么都直接，讀源代碼直接，寫自己的代碼也直接。
部署簡單。Go編譯生成的是一個靜態(tài)可執(zhí)行文件，除了glibc外沒有其他外部依賴。這讓部署變得異常方便：目標機器上只需要一個基礎的系統(tǒng)和必要的管理、監(jiān)控工具，完全不需要操心應用所需的各種包、庫的依賴關系，大大減輕了維護的負擔。這和Python有著巨大的區(qū)別。由于歷史的原因，Python的部署工具生態(tài)相當混亂【比如setuptools,distutils,pip,
buildout的不同適用場合以及兼容性問題】。官方PyPI源又經(jīng)常出問題，需要搭建私有鏡像，而維護這個鏡像又要花費不少時間和精力。
并發(fā)性好。Goroutine和channel使得編寫高并發(fā)的服務端軟件變得相當容易，很多情況下完全不需要考慮鎖機制以及由此帶來的各種問題。單個Go應用也能有效的利用多個CPU核，并行執(zhí)行的性能好。這和Python也是天壤之比。多線程和多進程的服務端程序編寫起來并不簡單，而且由于全局鎖GIL的原因，多線程的Python程序并不能有效利用多核，只能用多進程的方式部署;如果用標準庫里的multiprocessing包又會對監(jiān)控和管理造成不少的挑戰(zhàn)【我們用的supervisor管理進程，對fork支持不好】。部署Python應用的時候通常是每個CPU核部署一個應用，這會造成不少資源的浪費，比如假設某個Python應用啟動后需要占用100MB內(nèi)存，而服務器有32個CPU核，那么留一個核給系統(tǒng)、運行31個應用副本就要浪費3GB的內(nèi)存資源。
良好的語言設計。從學術的角度講Go語言其實非常平庸，不支持許多高級的語言特性;但從工程的角度講，Go的設計是非常優(yōu)秀的：規(guī)范足夠簡單靈活，有其他語言基礎的程序員都能迅速上手。更重要的是Go自帶完善的工具鏈，大大提高了團隊協(xié)作的一致性。比如gofmt自動排版Go代碼，很大程度上杜絕了不同人寫的代碼排版風格不一致的問題。把編輯器配置成在編輯存檔的時候自動運行gofmt，這樣在編寫代碼的時候可以隨意擺放位置，存檔的時候自動變成正確排版的代碼。此外還有gofix,
govet等非常有用的工具。
執(zhí)行性能好。雖然不如C和Java，但通常比原生Python應用還是高一個數(shù)量級的，適合編寫一些瓶頸業(yè)務。內(nèi)存占用也非常省。
重慶分公司
重慶分公司
