六月七月，寫了十多篇緩存架構設計，彙總在《緩存架構，一篇足夠？》。面試
八月九月，寫了十多篇MySQL內核的底層細節，彙總在《關於MySQL內核，必定要知道的！》。算法
很多小夥伴留言，問能不能同時「併發」多個系列，因而，九月份以來就同時啓動了如下幾個系列。數據庫
1、本身職場經歷緩存
目前寫了兩篇：微信
《技術類簡歷要怎麼寫》數據結構
《找工做的血淚史》架構
但願本身走出校園，走向職場的經驗，能給到你們一些啓示。併發
這個系列的下一篇，準備寫本身職業生涯前兩年在百度的感觸，早就構思好了，只是遲遲沒有動筆。分佈式
2、數據結構算法類優化
也就是標題爲「拜託，面試別再問我XXXX」的這一系列，目前這一系列反饋比較好。
TopK，數1，斐波拉契數列：
算法時間複雜度，一篇搞定：
時間複雜度爲O(n)的排序問題：
後續爭取講透更多更有意思的算法，但願這些文章可以幫助你們在面試中勝出，拿到本身心儀的offer。
3、管理經驗
除了在8月份已完結的，「leader教個人那些事」系列，已彙總在《這些年，leader教個人那些事》。
10月份又重啓了一個系列，「新晉leader那些事」，目前只輸出了一篇：
這一個系列必定會體系化的寫下去，心想，追劇「架構師之路」3年的小夥伴，如今應該都至少是主管，經理了吧？
4、數據庫相關
只輸出了一篇，關於數據庫主從同步延時很長，MySQL的優化思路：
5、架構相關
架構類的文章，是「架構師之路」啓動的初心，沒想到最近一篇長文，閱讀量如此慘淡，考慮後續減小此類輸出：
畫外音：莫非這類比較長的文章，不適合碎片時間閱讀？
6、分佈式相關
這個系列，是你們在評論中但願啓動的，目前聊了CAP，2PC，後置提交等幾個話題：
《分佈式基礎，啥是兩階段提交？》
《分佈式事務，原來能夠這麼玩？》
可是，從閱讀量和轉發量上看，不是很理想。
固然，我也不會只從閱讀量和轉發量來選擇創做主題，只要以爲有價值的東西，就會繼續寫下去，大夥以爲呢？
畫外音：固然，閱讀和轉發會帶來更大的動力。
有位小夥伴留言「技術圈爲數很少值得置頂的公衆號」，十分感動，感謝。
只要你們有收穫，凌晨筆耕不輟的時光，就不是白費。
調研：追劇「架構師之路」3年的小夥伴，如今至少是主管，經理了麼？
本文分享自微信公衆號 - 架構師之路（road5858）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。