【悟思維】項目架構決定性能？優秀的架構勝過一萬次的調優
這個問題很容易理解，一個單節點（一臺應用服務器+一臺數據庫服務器）的系統架構，任憑你使出渾身解數來調優也不可能讓系統達到百萬級併發，別說百萬級了，上萬併發都不可能。不說其他的，在一個性能相對不錯的物理機上，mysql最多也就能承載3500-4500的QPS，你說你能調優調到上萬併發？？在目前來看如果不借助於其他組件或者其他技術手段是不太可能的。
首先大家要明白一個最底層的邏輯，所有的性能問題歸根結底絕大多數都是要解決IO的讀寫性能問題。
我們在線程模型上面孜孜不倦的追求，從BIO到NIO，再到reactor，最後到proactor，對這些模型的追求本質上就是不斷對IO性能的追求。
那IO又分爲讀IO和寫IO，在單節點上，高併發上來之後，請求直接通過tomcat打到mysql上達到3500qps左右的時候，mysql就會報警了，這時候怎麼辦？
打到mysql上的請求無非就是讀和寫，所以我們分兩種情況來處理：
- 一是解決讀IO的問題，如何解決？最直接的就是我們把熱點數據直接放內存裏（走邏輯io），不走mysql了（走mysql實際是到磁盤去拿數據的，走的是物理IO），所以我們大名鼎鼎的redis就派上用場了。絕大部分熱點數據都存放在redis，高併發時候，讀IO絕大部分都走redis了，這樣就減輕了mysql的負擔。
- 二是解決寫IO的問題，當大量的寫需求到達mysql的時候，如果我們在mysql前面加上消息隊列相關組件，讓寫請求先進隊列，然後再通過隊列慢慢依次的來對mysql進行寫操作，那麼這樣不就減輕了mysql的寫請求IO了嗎？
所以我們的架構就從單一架構（比如說是tomcat+mysql）變成了（tomcat+mq+redis+mysql）的架構，這兩種架構的性能有着天壤之別。因爲mq和redis分別解決了高併發時的讀寫問題，這纔是影響性能的根本因素。那麼第二種架構還有很多的優化空間，比如我們繼續給他增加多級緩存，redis再做集羣，mq也做集羣，甚至tomcat，mysql都做集羣，那麼這個系統將會變的非常龐大，也更加的複雜，但是帶來的效果卻是顯而易見的，達到百萬併發，千萬併發甚至億級併發都是有可能的。