1.什麼是高併發?
高併發是解決大資料量業務的一種思路,源於現實的生產生活中的問題。
舉乙個現實生活中的例子:去銀行辦業務,銀行裡段時間來了100個人辦理業務,但是只有乙個視窗來辦理,平均乙個人辦完業務需要5分鐘,100個人需要500分鐘。
當出現類似問題的時候,我們應該怎樣去解決呢?
(1)提高單個視窗辦理業務的效率,比如提高櫃檯營業員的業務水平,之前5分鐘能夠辦理1個人,
現在可以辦理2個人,提高單人處理效率,那麼100個人辦完需要250分鐘;
(2)當單個人的處理效率達到最大時,應該如何繼續提高辦理效率呢?
乙個視窗處理能力達到最大時,就要考慮其他方法了。乙個問題如果縱向上沒有好的解決辦法,可以考慮橫向來處理。比如這個問題,我們可以增加視窗並行處理,增加4個視窗,每個視窗都達到最大處理能力,比如都是5分鐘辦理兩個人的業務,那麼辦完100個人需要50分鐘。
用通俗的話來說,就是眾人拾柴火焰高 說的就是這個道理,單個人的力量是有限的 ,大家一起幹 處理效率自然就快很多。那麼我們在處理海量資料的思路也是這樣的,一台機器處理達到瓶頸時 我們增加幾台機器 並行處理。
所以總結來說:高併發,就是高效率的並行處理 多通道處理,每個通道的功能相同,通過累加效應 體現整體的高效率。
2.如何實現高併發
目前有很多實現高併發的框架,比如netty、disruptor、訊息中介軟體,他們有乙個共同特點:多執行緒+快取佇列。
(1)併發是多通道並行,那麼多執行緒就是實現多通道,乙個執行緒負責乙個處理通道;
(2)快取佇列用來幹什麼呢?
比如來了100個人辦業務,5個視窗同時處理5個人,那麼剩餘的人就在等待區的座位上等待 當叫到下一位就會離開休息區到視窗去辦業務。休息區起到了緩衝作用,否則大家都排在視窗面前堵在那裡。在處理資料時候,等到資料來了放到緩衝佇列裡暫時存放,等到執行緒空閒了,就繼續處理。
有乙個問題是,為什麼不放到資料庫裡,而是要建立乙個快取去存放?
要回答這個問題,需要了解兩件事情:
1、搞清楚資料庫和快取的區別:
資料庫是用來持久存放資料的,是記錄到磁碟裡,讀取或者插入有磁碟io操作,有一定的耗時的,一般是在業務設計中,如果是業務需要必需存下來的資料,就需要記錄到資料庫裡;
快取是用來存放少量臨時資料的,不需要記錄到磁碟,優點是處理速度快。
2、高併發的目的就是高效率,所以一切提高效率的事情都是必要的。
cpu是按照暫存器》記憶體條》磁碟的次序,效率依次降低,所以這裡相對於資料庫,使用快取佇列,效率高。 比如jdk的concurrenthashmap,訊息中介軟體、netty等都是載入到記憶體裡,disruptor更厲害,載入到暫存器裡,效率更高。
以後要**的問題:
關於訊息順序消費 重複消費的問題:
關於高併發支付 秒殺的一些設計思路
於高併發支付 秒殺的一些設計思路 一 問題描述 高併發支付和秒殺的場景有很多,amazon黑色星期 五 天貓雙11 京東618等情況都是如此。假如amazon某件低價商品只有100個,庫存也就是這100份,不會再變了。在00 00秒殺開搶的那一刻,會湧入非常多的流量程序查詢 read 和下單支付 w...
高併發的一些處理方法
最近一段時間一直在看一些高併發處理策略的文章,在此也稍微總結一下自己的心得 一.高併發 可以這麼理解高併發,在同一時間,有大量使用者同時訪問同乙個url,容易導致伺服器和資料庫資源被佔滿崩潰,資料庫的儲存和更新結果跟理想不一致,例如出現重複的資料記錄,多次新增記錄等資料錯亂問題。二.高併發的處理策略...
關於SpringIOC的一些思考
ioc是 依賴倒置原則 的乙個特例,說其是特例,就是說其具有 依賴倒置原則 的性質。依賴倒置原則強調的兩點是 上層模組和下次模組都依賴於抽象,二者之間通過這種抽象的東西聯絡在一起 具體可以依賴於抽象,而抽象不能依賴於具體。我認為spring提倡的 基於介面程式設計 就是為了遵循 依賴倒置原則 其中所...