1.總的老說，優化方案中只有兩種，一種是給查詢的欄位加組合索引。另一種是給在用戶和資料庫中增加緩存
2.添加索引方案：面對1~2千的並發是沒有壓力的，在往上則限制的瓶頸就是資料庫最大連接數了，在上面中我用show global status like 'Max_used_connections』查看資料庫可以知道資料庫最大響應連接數是5700多，超過這個數tomcat直接報錯連接被拒絕或者連接已經失效
3.緩存方案：在上面的測試可以知道，要是我們事先把資料庫的千萬條數據同步到redis緩存中，瓶頸就是我們的設備硬體性能了，假如我們的主機有幾百個核心CPU，就算是千萬級的並發下也可以完全無壓力，帶個用戶很好的。
4.索引+緩存方案：緩存事先沒有要查詢的數據，在一萬的並發下測試資料庫毫無壓力，程序先通過查緩存再查資料庫大大減輕了資料庫的壓力，即使緩存不命中在一萬的並發下也能正常訪問,在10萬並發下資料庫依然沒壓力，但是redis伺服器設置最大連接數300去處理10萬的線程，4核CPU處理不過來，很多redis連接不了。我用show global status like 'Max_used_connections'查看資料庫發現最大響應連接數是388，這么低所以資料庫是不會掛掉的。雷達下載更專業。
5.使用場景：a.幾百或者2000以下並發直接加上組合索引就可以了。b.不想加索引又高並發的情況下可以先事先把數據放到緩存中，硬體設備支持下可解決百萬級並發。c.加索引且緩存事先沒有數據，在硬體設備支持下可解決百萬級並發問題。d.不加索引且緩存事先沒有數據，不可取，要80多秒才能得到結果，用戶體驗極差。
6.原理：其實使用了redis的話為什麼資料庫不會崩潰是因為redis最大連接數為300，這樣資料庫最大同時連接數也是300多，所以不會掛掉，至於redis為什麼設置為300是因為設置的太高就會報錯(連接被拒絕)或者等待超時(就算設置等待超時的時間很長也會報這個錯)。
⑵ redis的高並發表現
相同的key，裡面的數據是要覆蓋的，如果數據特別重要，可以加鎖。參考
網頁鏈接
一般情況下，redis用來進行數據的緩存，在這樣的場景下，下一個用戶寫入之前應該先判斷是否存在這個key，有就取值，沒有就加入。
redis可以有很多key的，如用戶信息，一般使用用戶的ID來做key，這樣每個用戶不會出現相同的key
⑶ redis解決高並發問題嗎
edis真的是一個很好的技術，它可以很好的在一定程度上解決網站一瞬間的並發量，例如商品搶購秒殺等活動。。。
redis之所以能解決高並發的原因是它可以直接訪問內存，而以往我們用的是資料庫(硬碟),提高了訪問效率,解決了資料庫伺服器壓力。
為什麼redis的地位越來越高，我們為何不選擇memcache，這是因為memcache只能存儲字元串，而redis存儲類型很豐富（例如有字元串、LIST、SET等），memcache每個值最大隻能存儲1M,存儲資源非常有限,十分消耗內存資源,而redis可以存儲1G,最重要的是memcache它不如redis安全,當伺服器發生故障或者意外關機等情況時,redsi會把內存中的數據備份到硬碟中,而memcache所存儲的東西全部丟失;這也說明了memcache不適合做資料庫來用,可以用來做緩存。
下面用redis解決瞬間秒殺活動來說明：
下面這個程序模擬了20w人一瞬間湧入這個頁面進行秒殺,能夠秒殺成功的只有500人,我們把先進來的用戶放入redis隊列中,當隊列中的用戶達到500時，後來用戶就轉到秒殺結束頁面。這里用隨機數來表示不同的用戶。
我們可以看到從秒殺成功隊列中依次取出的第一個用戶id是208522，最後一個用戶是176260，可以看出結果是很准確的。
redis在解決高並發這方面的能力是真的挺不錯的。
⑷ 如何解決高並發問題
使用高性能的伺服器、高性能的資料庫、高效率的編程語言、還有高性能的Web容器，(對架構分層+負載均衡+集群)這幾個解決思路在一定程度上意味著更大的投入。
1、高並發：在同一個時間點，有大量的客戶來訪問我們的網站，如果訪問量過大，就可能造成網站癱瘓。
2、高流量：當網站大後，有大量的圖片，視頻，這樣就會對流量要求高，需要更多更大的帶寬。
3、大存儲：可能對數據保存和查詢出現問題。
解決方案：
1、提高硬體能力、增加系統伺服器。（當伺服器增加到某個程度的時候系統所能提供的並發訪問量幾乎不變，所以不能根本解決問題）
2、本地緩存：本地可以使用JDK自帶的Map、Guava Cache.分布式緩存：Redis、Memcache.本地緩存不適用於提高系統並發量，一般是用處用在程序中。
Spiring把已經初始過的變數放在一個Map中，下次再要使用這個變數的時候，先判斷Map中有沒有，這也就是系統中常見的單例模式的實現。
⑸ redis作為mybatis的二級緩存，此時二級緩存可以作為高並發緩存嗎
一級緩存只對當前session可見二級緩存作用域則可以跨越多個session 當一些數據不常發生變化或者允許偶爾的並發的時候 二級緩存可能更有效率 因為它的緩存時間更久 不會像一級緩存一樣一旦session銷毀就銷毀
⑹ redis原理，單線程怎麼做到高並發的
但線程，只能靠單個處理器速度，內存速度，處理器上的緩存速度，匯流排傳輸速度。餘下的是你的網路IO。但線程高並發完全依賴程序的運行速度。redis這種東西肯定不是但線程的。一個連接就是一個線程，你這樣理解應該不準確。
⑺ 在高並發的情況下，session存redis和session存mong
redis 和mango都屬於nosql，兩者都可以作為緩存,同樣的都可以作為資料庫。 1MongoDB的文檔模型自由靈活，可以讓你在開發過程中暢順無比。對於大數據量、高並發、弱事務的互聯網應用，MongoDB可以應對自如。MongoDB內置的水平擴展機制提供了從百在高並發的情況下，session存redis和session存mong
⑻ redis怎樣解決高並發
1.Redis存取數據是基於內存的，而內存的讀寫速度非常快，這是前提。
2.Redis是單線程的，省去了很多切換線程的時間消耗。(PS：Redis單線程指的是網路請求模塊使用了一個線程（所以不需考慮並發安全性），即一個線程處理所有網路請求，其他模塊仍用了多線程。PPS：目前新版的Redis分支也在深入的探索多線程的方式，理論效率要高於目前市面上的穩定版本。)
3.Redis採用網路IO多路復用技術（非阻塞IO）來保證在多連接的時候，系統的高吞吐量。而非阻塞IO，其內部實現採用了epoll並結合了本身實現的簡單的事件框架，epoll中的讀、寫、關閉、連接都轉化成了事件，然後利用epoll的多路復用特性極大的節省了在處理IO上的時間。（PS：多路復用指的是多個socket連接復用一個線程。而epoll是目前最好的多路復用技術，所以使用epoll實現多路I/O復用技術可以讓單個線程高效的處理多個連接請求，從而達到盡量減少網路IO的時間消耗）
⑼ 在高並發的情況下，session存redis和session存mongodb差異大么
集群web系統的話，可以通過第三方緩存來統一實現session管理。如果使用spring的話，可以通過sessionlistener來監聽session的變化，實現起來比較方便。不建議把Session存儲起來可以考慮用Redis模擬session，特別是分布式環境，比如多台webserve（如tomcat）r的情況下