查詢資料庫並發
限流演算法目前程序開發過程常用的限流演算法有兩個：漏桶演算法和令牌桶演算法。
漏桶演算法
漏桶演算法的原理比較簡單，請求進入到漏桶中，漏桶以一定的速率漏水。當請求過多時，水直接溢出。可以看出，漏桶演算法可以強制限制數據的傳輸速度。如圖所示，把請求比作是水滴，水先滴到桶里，通過漏洞並以限定的速度出水，當水來得過猛而出水不夠快時就會導致水直接溢出，即拒絕服務。
圖片來自網路
漏桶演算法和令牌桶演算法的選擇
兩者的主要區別漏桶演算法能夠強行限制處理數據的速率，不論系統是否空閑。而令牌桶演算法能夠在限制數據的平均處理速率的同時還允許某種程度的突發流量。如何理解上面的含義呢？漏桶演算法，比如系統吞吐量是 120/s，業務請求 130/s，使用漏斗限流 100/s，起到限流的作用，多餘的請求將產生等待或者丟棄。對於令牌桶演算法，每秒產生 100 個令牌，系統容量 200 個令牌。正常情況下，業務請求 100/s 時，請求能被正常被處理。當有突發流量過來比如 200 個請求時，因為系統容量有 200 個令牌可以同一時刻處理掉這 200 個請求。如果是漏桶演算法，則只能處理 100 個請求，其他的請求等待或者被丟棄。
Ⅱ 如何處理資料庫並發問題
想要知道如何處理數據並發，自然需要先了解數據並發。
什麼是數據並發操作呢？
就是同一時間內，不同的線程同時對一條數據進行讀寫操作。
在互聯網時代，一個系統常常有很多人在使用，因此就可能出現高並發的現象，也就是不同的用戶同時對一條數據進行操作，如果沒有有效的處理，自然就會出現數據的異常。而最常見的一種數據並發的場景就是電商中的秒殺，成千上萬個用戶對在極端的時間內，搶購一個商品。針對這種場景，商品的庫存就是一個需要控制的數據，而多個用戶對在同一時間對庫存進行重寫，一個不小心就可能出現超賣的情況。
針對這種情況，我們如何有效的處理數據並發呢？
第一種方案、資料庫鎖
從鎖的基本屬性來說，可以分為兩種：一種是共享鎖（S），一種是排它鎖（X）。在MySQL的資料庫中，是有四種隔離級別的，會在讀寫的時候，自動的使用這兩種鎖，防止數據出現混亂。
這四種隔離級別分別是：
讀未提交（Read Uncommitted）
讀提交（Read Committed）
可重復讀（Repeated Read）
串列化（Serializable）
當然，不同的隔離級別，效率也是不同的，對於數據的一致性保證也就有不同的結果。而這些可能出現的又有哪些呢？
臟讀（dirty read）
當事務與事務之間沒有任何隔離的時候，就可能會出現臟讀。例如：商家想看看所有的訂單有哪些，這時，用戶A提交了一個訂單，但事務還沒提交，商家卻看到了這個訂單。而這時就會出現一種問題，當商家去操作這個訂單時，可能用戶A的訂單由於部分問題，導致數據回滾，事務沒有提交，這時商家的操作就會失去目標。
不可重復讀（unrepeatable read）
一個事務中，兩次讀操作出來的同一條數據值不同，就是不可重復讀。
例如：我們有一個事務A，需要去查詢一下商品庫存，然後做扣減，這時，事務B操作了這個商品，扣減了一部分庫存，當事務A再次去查詢商品庫存的時候，發現這一次的結果和上次不同了，這就是不可重復讀。
幻讀（phantom problem）
一個事務中，兩次讀操作出來的結果集不同，就是幻讀。
例如：一個事務A，去查詢現在已經支付的訂單有哪些，得到了一個結果集。這時，事務B新提交了一個訂單，當事務A再次去查詢時，就會出現，兩次得到的結果集不同的情況，也就是幻讀了。
那針對這些結果，不同的隔離級別可以干什麼呢？
「讀未提（Read Uncommitted）」能預防啥？啥都預防不了。
「讀提交（Read Committed）」能預防啥？使用「快照讀（Snapshot Read）」方式，避免「臟讀」，但是可能出現「不可重復讀」和「幻讀」。
「可重復讀（Repeated Red）」能預防啥？使用「快照讀（Snapshot Read）」方式，鎖住被讀取記錄，避免出現「臟讀」、「不可重復讀」，但是可能出現「幻讀」。
「串列化（Serializable）」能預防啥？有效避免「臟讀」、「不可重復讀」、「幻讀」，不過運行效率奇差。
好了，鎖說完了，但是，我們的資料庫鎖，並不能有效的解決並發的問題，只是盡可能保證數據的一致性，當並發量特別大時，資料庫還是容易扛不住。那解決數據並發的另一個手段就是，盡可能的提高處理的速度。
因為數據的IO要提升難度比較大，那麼通過其他的方式，對數據進行處理，減少資料庫的IO，就是提高並發能力的有效手段了。
最有效的一種方式就是：緩存
想要減少並發出現的概率，那麼讀寫的效率越高，讀寫的執行時間越短，自然數據並發的可能性就變小了，並發性能也有提高了。
還是用剛才的秒殺舉例，我們為的就是保證庫存的數據不出錯，賣出一個商品，減一個庫存，那麼，我們就可以將庫存放在內存中進行處理。這樣，就能夠保證庫存有序的及時扣減，並且不出現問題。這樣，我們的資料庫的寫操作也變少了，執行效率也就大大提高了。
當然，常用的分布式緩存方式有：Redis和Memcache，Redis可以持久化到硬碟，而Memcache不行，應該怎麼選擇，就看具體的使用場景了。
當然，緩存畢竟使用的范圍有限，很多的數據我們還是必須持久化到硬碟中，那我們就需要提高資料庫的IO能力，這樣避免一個線程執行時間太長，造成線程的阻塞。
那麼，讀寫分離就是另一種有效的方式了
當我們的寫成為了瓶頸的時候，讀寫分離就是一種可以選擇的方式了。
我們的讀庫就只需要執行讀，寫庫就只需要執行寫，把讀的壓力從主庫中分離出去，讓主庫的資源只是用來保證寫的效率，從而提高寫操作的性能。
Ⅲ 怎麼查詢SQL資料庫的在線用戶，並發用戶
在線用戶一般是用一個標識的。http屬於無狀態連接，
比如你登陸後就置為在線，點擊更新時間。退出置為下線。如果長久不點擊，可以拿比如windows服務將標識置為下線。另外應該也可以根據session多少判斷吧，看下是否有這個函數。
另外並發用戶是指某一個時刻的，這個有工具，以win2003Server為例，它有自帶的監視工具。管理工具-》性能。裡面可以選擇post指數和get指數可以實時查詢。
iis中的log里也有。
要不你也可以用戶點擊一下你插入一條，記錄時間。
Ⅳ 如何查MSSQL的並發連接數
最近有些客戶提出想對SQL Server的連接數進行一些監聽。總結了以下一些方法：
1、獲取SQL Server允許同時用戶連接的最大數
SELECT @@MAX_CONNECTIONS
2、獲取當前指定資料庫的連接信息
SELECT * FROM master.dbo.sysprocesses WHERE dbid IN
(
SELECT dbid FROM master.dbo.sysdatabases
WHERE NAME='YourDataBaseName'
)
--根據需要更改YourDataBaseName
SELECT * FROM master.dbo.sysprocesses WHERE DB_NAME(dbid) = 'YourDataBaseName'
3、獲取當前SQL伺服器所有的連接詳細信息
SELECT * FROM sysprocesses
以上查詢結果包含了：系統進程和用戶進程。
如果只是想查用戶進程的話則需採用下面的方法
4、獲取自上次啟動 SQL Server服務 以來連接或試圖連接的次數
SELECT @@CONNECTIONS
這個剛開始會有點誤解，認為是當前SQL Server伺服器當前所有的連接數。需要重點注意。