本週學習了MongoDB的一個專欄，原因有兩點：在最近開發過程中，也意識到MySQL分庫分表有其侷限性，第三範式也讓整個應用程序複雜度變高，數據處理的聯動性非常多，所以至少要有一個非關係數據庫軟件，相信MongoDB在某些場景下是個很好的補充；第二就是未來可能有用戶畫像或行爲數據需求，在這方面MongoDB也是一種解決方案。

第二個事情還是搜索，在《 logstash grok filter插件實戰 》文章中描述了logstash的一些運用，其實logstash也能將數據導入到MongoDB中。另外簡單說說一種搜索需求，比如一個品牌有很多別名，比如阿迪達斯、addidas，如果用戶純粹搜索阿迪達斯這個詞，匹配度會少了很多，在這種情況下，如果是品牌文章搜索，先根據關鍵字搜索出一個品牌的所有別名，然後使用multi_match進行多字段值查詢，匹配的文章數量會更高。

第三這週一直在進行業務開發，前幾天看到一臺副庫 show slave status 報 Slave_SQL_Running_State: System lock 錯誤，導致同步延時，但當時的線程query運行並不多，這提示我，MySQL還是我們服務的根本，需要進一步挖掘。

說到業務開發，其實一線寫代碼某種程度上並不是那麼容易的，畢竟每個人及周圍的情況不是那麼完美的，所以需要體諒、洞察，儘量去做好每件事情即可。我們需要理解每件事情的重要性和緊急性，但也必須尊重客觀規律。

新工作四個月了，有兩個項目讓我挺緊張的，一個就是街區街文的改造，另外一個就是這次的父子話題改造，如果理解的太複雜，那結構性就會有大的破壞，對於後續的開發、維護會有很大的影響。這也提示我們，需要突破原有思維，未來需要更靈活的實現方式，比如說選擇更好的數據存儲軟件，MongoDB可能就是一個補充。而且類似這樣的項目，一定要在開始說清楚，否則一邊開發一邊妥協，到後面就難辦了，事情的判斷需要有一定的界限。

昨天一個客戶端同事一起討論，意思就是API提供的數據能不能模塊化，比如很多接口會涉及到 話題 數據結構，如果數據結構完全一樣，客戶端開發的時候就會更加方便，效率會更高。

這是一個非常普遍的需求，和小夥伴們商量了下，有幾點想法：

API看上去好像就是一個個接口，但它後面的實現邏輯千變萬化，在需求快速迭代的過程中，數據結構會經常變化，甚至還要兼容很多老的版本（這是APP開發的一個痛點），歷史包袱也很重，既要往前跑還要擦屁股，實現模塊化真的很難。

不說實現邏輯層的模塊化，就實現數據層的模塊化很難，很難寫出完全通用的模塊，基本上是一個需求就一個模塊，到最後越來越多的模塊，這就不是模塊化了。即使寫出來也是在性能上做了很多妥協，比如爲了實現一個通用的模塊，調用方可能僅僅用到其中的一小部分，可最終卻查詢了很多數據，這肯定不合適。

那這是開發語言層面的問題嗎？比如PHP是不是就比Java弱？我想Java可能有更多的規範去保證代碼質量，但本質上還是人的技術實現佔主導因素，和開發語言沒有關係。

那怎麼辦呢？我也沒想到好的方法，只能說盡力去想辦法。

比如說客戶端希望API模塊化，就要想到API有很多歷史版本問題，就要配合着API去優化，比如這個字段已經廢棄不用了，這個接口不用了，這個接口能不能合併，這個接口不用考慮性能問題（客戶端去做緩存），多多反饋給API提供者，把自己當成API的實現者。當做一個整體才能達到共贏，只要多多協作，結果就會越來越好。

而對於我們來說，要有更多的解決方案，不能純粹依靠MySQL、緩存，要想更優秀的解決方案，比如將很多“數”同步到Redis中就是一種優化方案，依賴於Redis的高效和簡潔，就可以擺脫MySQL複雜的關係查詢，也能擺脫緩存一致性更新的問題，從而讓代碼更輕量。

同時也要不斷的迭代，迭代需要經驗的積累，需要互相理解，因爲系統是由我們自己維護的，如果系統像一輛破車，那自己騎的時候也很費勁。

最後也不要妄自菲薄，很多大公司一個個高深技術，可出問題的時候，才發現寫的代碼那麼的低級，完全顛覆你的認知，這個世界上沒有銀彈。