- micro服務發現
服務的注冊與發現是微服務必不可少的功能，這樣系統才能有更高的性能，更高的可用性。go-micro框架的服務發現有自己能用的接口Registry。只要實現這個接口就可以定制自己的服務注冊和發現。
go-micro在客戶端做的負載，典型的Balancing-aware Client模式。
參考鏈接: https://www.cnblogs.com/li-peng/p/9689786.html
1 MySQL 的常用引擎
a InnoDB
b Myisam
c 存儲結構
2 MySQL 的數據、索引存儲結構
a 數據存儲的原理（硬盤）
b 數據讀寫的原理
c 訪盤請求完成過程
d 磁盤的讀寫原理
e 減少 I/O 的預讀原理
f MySQL 的索引
g MySQL 的 B+Tree
目前大多數數據庫系統及文件系統都采用 B-Tree 或其變種 B+Tree 作為索引結構。
B+ 樹索引是 B+ 樹在數據庫中的一種實現，是最常見也是數據庫中使用最為頻繁的一種索引。B+ 樹中的 B 代表平衡，而不是二叉。
因為 B+ 樹是從最早的平衡二叉樹演化而來的。B+ 樹是由二叉查找樹、平衡二叉樹（AVLTree）和平衡多路查找樹（B-Tree）逐步優化而來。
二叉查找樹：左子樹的鍵值小於根的鍵值，右子樹的鍵值大於根的鍵值。
AVL 樹：平衡二叉樹（AVL 樹）在符合二叉查找樹的條件下，還滿足任何節點的兩個子樹的高度最大差為 1。
平衡多路查找樹（B-Tree）：為磁盤等外存儲設備設計的一種平衡查找樹。
參考鏈接: https://www.cnblogs.com/xuxinstyle/p/9813747.html
- channel底層實現
參考鏈接: https://www.cnblogs.com/sunsky303/p/14007172.html
B+樹能顯著減少IO次數，提高效率
B+樹的查詢效率更加穩定，因為數據放在葉子節點
B+樹能提高范圍查詢的效率，因為葉子節點指向下一個葉子節點
么B樹和B+樹的區別在哪呢？
B+跟B樹不同B+樹的非葉子節點不保存鍵值對應的數據，這樣使得B+樹每個節點所能保存的鍵值大大增加；
B+樹葉子節點保存了父節點的所有鍵值和鍵值對應的數據，每個葉子節點的關鍵字從小到大鏈接；
B+樹的根節點鍵值數量和其子節點個數相等;
B+的非葉子節點只進行數據索引，不會存實際的鍵值對應的數據，所有數據必須要到葉子節點才能獲取到，所以每次數據查詢的次數都一樣；
參考鏈接： https://blog.csdn.net/zzti_erlie/article/details/82973742
1.硬件
2.系統配置
3.數據庫表結構
4.SQL以及索引
參考鏈接: https://www.cnblogs.com/111testing/p/11440064.html
有兩種主要的服務發現機制：客戶端發現機制和服務端發現機制。首先來看一下客戶端發現機制。
參考鏈接: https://blog.csdn.net/lmy86263/article/details/75156520
這就是分布式系統的一致性問題。
在分布式環境中， 一致性是指數據在多個副本之間是否能夠保持一致的特性。在一致性的需求下，當一個系統在數據一致的狀態下執行更新操作之后， 應該能夠保證系統的數據仍然處於一致的狀態。
對於一個將數據副本分別在不同分布式節點上的系統來說，如果對於第一個節點的數據進行了更新操作，並且成功更新之后，卻沒有使得其他節點上的數據得到相應的更新，於是在對第二個節點的數據進行讀操作時，獲取的是老數據（臟數據），這就是典型的分布式數據不一致的情況。
在一個分布式系統中，如果能夠做到針對一個數據項的更新操作執行成功之后，所有的用戶都可以讀取到其中的最新值，那么這樣的系統就被認為是具有強一致性（嚴格一致性）。
當然，在有些分布式系統實現中，並不需要實時保證系統數據的強一致性，它允許數據存在中間狀態，並認為該中間狀態不會影響系統的整體可用性（允許數據在不同節點之間的同步存在延時），在經過一段時間之后，最終能夠達到一個一致的狀態，這就是最終一致性（弱一致性）。
參考鏈接: https://www.jianshu.com/p/b93e883b92ea
簡單易學。Paxos算法由Leslie Lamport通過論文發表於1990年，是當時最實用的分布式存儲一致性算法。有許多上了年頭的分布式系統底層采用的是Paxos。而Raft是由Paxos簡化得來。Diego Ongaro與John Ousterhout在自己的論文中指出：經過對比，學生學習Paxos所需時間明顯長於學習Raft所需時間。
最終一致性。存儲一致性根據對於各個服務器的同一份數據之間允許差異的嚴格程度不同，可以分為強一致性、最終一致性、弱一致性。根據CAP定理，一個分布式系統不能同時保障一致性（Consistency）、可用性（Availability）與分區容錯性（Partition tolerence）。但是經過權衡，系統可以達到“BASE”效果：基本可用（Basically available）、軟狀態（Soft state）、最終一致性（Eventually consistent）。Raft所達到的最終一致性，是指各節點上的數據在經過足夠的時間之后，最終會達到一致的狀態。
- 當go服務部署到線上了，發現有內存泄露，該怎么處理
內存泄露指的是程序運行過程中已不再使用的內存，沒有被釋放掉，導致這些內存無法被使用，直到程序結束這些內存才被釋放的問題。
Go雖然有GC來回收不再使用的堆內存，減輕了開發人員對內存的管理負擔，但這並不意味着Go程序不再有內存泄露問題。在Go程序中，如果沒有Go語言的編程思維，也不遵守良好的編程實踐，就可能埋下隱患，造成內存泄露問題。
怎么發現內存泄露
在Go中發現內存泄露有2種方法，一個是通用的監控工具，另一個是go pprof：
監控工具：固定周期對進程的內存占用情況進行采樣，數據可視化后，根據內存占用走勢（持續上升），很容易發現是否發生內存泄露。
go pprof：適合沒有監控工具的情況，使用Go提供的pprof工具判斷是否發生內存泄露。
參考鏈接: https://blog.csdn.net/amars_ding/article/details/105865165
