MongoDB高併發寫場景開啓讀寫分離讀從庫爲什麼阻塞? 咱們該如何處理?

目錄

• MongoDB高併發寫場景開啓讀寫分離讀從庫爲什麼阻塞? 咱們該如何處理?
• MongoDB 4.0有哪些新特性，你最期待的有哪些，爲何？
• Redis如何獲取全部的key，不阻塞？
• MySQL中間件的性能測試和常規業務性能測試相比有什麼不一樣？

---

1、MongoDB高併發寫場景開啓讀寫分離讀從庫爲什麼阻塞? 咱們該如何處理?

一、按業務拆分邏輯下降讀寫併發度

二、添加分片均衡讀寫

三、升級至即將到來的4.0經過讀snapshot解決從庫讀阻塞

2、MongoDB 4.0有哪些新特性，你最期待的有哪些，爲何？

一、多文檔事務的支持，解決了多文檔操做的原子性問題

二、snapshot讀相關支持，使得可在某個timestamp點上讀到一個一致性的快照

三、Change Streams 支持實例及庫級別粒度爲業務提供了更多實時捕獲變動的選擇

四、聚合框架支持類型轉換及字符先後空格截斷操做

五、加入對SCRAM-SHA-256認證策略以支持更強的認證加密驗證

六、提供經過簡單的命令開啓免費監控功能

七、更多的操做支持w:majority 好比對集合進行分片，建立刪除集合等

八、listCollections 能夠指定nameOnly:true 而不加鎖

九、增長 rollbackTimeLimitSecs參數控制節點回滾的最大時間限制

十、支持直接在mongos路由節點直接kill具體操做無需按分片進行

十一、使用WiredTiger引擎不容許關閉journal日誌

3、Redis如何獲取全部的key，不阻塞？

一、在slave上執行Save命令，拷貝rdb文件到其餘redis實例上用於統計key。

二、能夠利用scan命令，來遍歷當前數據庫中的數據庫鍵。

4、MySQL中間件的性能測試和常規業務性能測試相比有什麼不一樣？

性能測試的方法論基本都同樣，以觀察-分析-改進-再觀察這個循環進行。

常規業務因爲業務交互複雜、技術棧龐雜、性能瓶頸一般集中於業務, 性能測試使用的分析方法比較簡單, 經過診斷業務一般能夠低成本地找到性能瓶頸。

MySQL中間件的應用場景比較簡單、技術棧穩定、性能瓶頸一般集中於架構和環境, 性能測試使用的分析方法比較多, 對性能瓶頸的分析一般成本比較高。另外在這一方面的現有知識積累並不很成體系, 也是成本較高的緣由之一。

---

公衆號：知數堂，更多MySQL乾貨知識，關注公衆號獲取。

原文連接：https://zhishutang.com/QH9
推薦閱讀：https://zhishutang.com/xdI