關於資料庫的高併發處理研究，蟲子只是淺嘗輒止。可能很多方面各位大牛都用過，蟲子就來丟醜一下了。
基於web方面的減壓蟲子已經在博文中介紹過 就不贅述了
本章我們著重介紹下基於資料庫的解決方案
1.分庫分表
按業務來算，橫向分庫、縱向分表。
2.資料庫集群和庫表雜湊
大型**都有複雜的應用，這些應用必須使用資料庫，那麼在面對大量訪問的時候，資料庫的瓶頸很快就能顯現出來，這時一台資料庫將很快無法滿足應用，於是我們需要使用資料庫集群或者庫表雜湊。
3.memcache分布式快取
將系統中價值不大並且不需要即時更新的資料放進memcache中作為臨時表來用，相當於在db層前擋了一招~ ~
4.合併請求
如果效能不佳，盡量將多個請求合併成乙個請求。
5.映象
映象是大型**常採用的提高效能和資料安全性的方式，映象的技術可以解決不同網路接入商和地域帶來的使用者訪問速度差異，比如chinanet和edunet之間的差異就促使了很多**在教育網內搭建映象站點，資料進行定時更新或者實時更新。在映象的細節技術方面，這裡不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟體實現的思路，比如linux上的rsync等工具。
6.讀寫分離
對於大資料量的表但是對於呈現讀寫要求不平均的話，讀操作與寫操作分離
7.建立高效的索引
蟲子一般都是直接用sql的索引分析來操作
8.業務合併（根據實際專案來看，不一定好用）
將耦合度比較高的業務以儲存過程的方式實現，不過系統的可維護性會變差
高併發，如何提高併發量
一 什麼是高併發 高併發 high concurrency 是網際網路分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。高併發相關常用的一些指標有響應時間 response time 吞吐量 throughput 每秒查詢率qps query per se...
處理高併發
這個我感覺都不是做開發來考慮的，但是估計面試需要。做查詢的時候會對查詢的表加上共享鎖。做更改的時候對錶加排它鎖。這個進行多個表更新查詢的時候x需要加鎖abc，y加鎖cba。現在x加了a需要c，y加了c需要a，就形成死鎖了。可以對錶建立乙個臨時表，臨時表不需要加鎖。還可以通過建立檔案組，來處理高併發，...
高併發處理
真實的支撐複雜業務場景的高併發系統架構其實是非常複雜的。比如說每秒百萬併發的中介軟體系統 每日百億請求的閘道器系統 瞬時每秒幾十萬請求的秒殺大促系統 支撐幾億使用者的大規模高並發電商平台架構，等等。為了支撐高併發請求，在系統架構的設計時，會結合具體的業務場景和特點，設計出各種複雜的架構，這需要大量底...