紅魔電競平板評測：大屏幕硬實力
前言：三年的疫情因為要上網(wǎng)課的原因激活了平板市場，如今網(wǎng)課的時代已經(jīng)過去，大家的生活都恢復到了正軌，這也就意味著，真正考驗平板電腦生存的環(huán)境來了。也就是面對著這種殘酷的
高并發(fā)意味著系統(tǒng)要應對海量請求。從筆者多年的面試經(jīng)驗來看，很多面試者在面對“什么是高并發(fā)架構(gòu)”的問題時，往往會粗略地認為一個系統(tǒng)的設計是否滿足高并發(fā)架構(gòu)，就是看這個系統(tǒng)是否可以應對海量請求。
再細問具體的細節(jié)時，回答往往顯得模棱兩可，比如每秒多少個請求才是高并發(fā)請求、系統(tǒng)的性能表現(xiàn)如何、系統(tǒng)的可用性表現(xiàn)如何，等等。
為了可以清晰地評判一個系統(tǒng)的設計是否滿足高并發(fā)架構(gòu)，在正式給出通用的高并發(fā)架構(gòu)設計方案前，我們先要厘清形成高并發(fā)系統(tǒng)的必要條件、高并發(fā)系統(tǒng)的衡量指標和高并發(fā)場景分類。
◎高性能：性能代表一個系統(tǒng)的并行處理能力，在同樣的硬件設備條件下，性能越高，越能節(jié)約硬件資源；同時性能關乎用戶體驗，如果系統(tǒng)響應時間過長，用戶就會產(chǎn)生抱怨。
◎高可用性：系統(tǒng)可以長期穩(wěn)定、正常地對外提供服務，而不是經(jīng)常出故障、宕機、崩潰。
◎可擴展性：系統(tǒng)可以通過水平擴容的方式，從容應對請求量的日漸遞增乃至突發(fā)的請求量激增。
我們可以將形成高并發(fā)系統(tǒng)的必要條件類比為一個籃球運動員的各項屬性：“高性能”相當于這個球員在賽場上的表現(xiàn)力強，“高可用性”相當于這個球員在賽場上總可以穩(wěn)定發(fā)揮，“可擴展性”相當于這個球員的未來成長性好。
高并發(fā)系統(tǒng)的衡量指標
一個很容易想到的可以體現(xiàn)系統(tǒng)性能的指標是，在一段時間內(nèi)系統(tǒng)的平均響應時間。例如，在一段時間內(nèi)有10000個請求被成功響應，那么在這段時間內(nèi)系統(tǒng)的平均響應時間是這10000個請求響應時間的平均值。
然而，平均值有明顯的硬傷并在很多數(shù)據(jù)統(tǒng)計場景中為大家所調(diào)侃。假設你和傳奇籃球巨星姚明被分到同一組，你的身高是174cm，姚明的身高是226cm，那么這組的平均身高是2m！這看起來非常不合理。
假設在10000個請求中有9900個請求的響應時間分別是1ms，另外100個請求的響應時間分別是100ms，那么平均響應時間僅為1.99ms，完全掩蓋了那100個請求的100ms響應時間的問題。
平均值的主要缺點是易受極端值的影響，這里的極端值是指偏大值或偏小值——當出現(xiàn)偏大值時，平均值將會增大；當出現(xiàn)偏小值時，平均值將會減小。
筆者推薦的系統(tǒng)性能的衡量指標是響應時間PCTn統(tǒng)計方式，PCTn表示請求響 應時間按從小到大排序后第n分位的響應時間。假設在一段時間內(nèi)100個請求的響應時間從小到大排序如圖所示，則第99分位的響應時間是100ms，即PCT99= 100ms。
圖片
分位值越大，對響應時間長的請求越敏感。比如統(tǒng)計10000個請求的響應時間：
◎PCT50=1ms，表示在10000個請求中50%的請求響應時間都在1ms以內(nèi)。
◎PCT99=800ms，表示在10000個請求中99%的請求響應時間都在800ms以內(nèi)。
◎PCT999=1.2s，表示在10000個請求中99.9%的請求響應時間都在1.2s以內(nèi)。
從筆者總結(jié)的經(jīng)驗數(shù)據(jù)來看，請求的平均響應時間=200ms，且PCT99=1s的高并發(fā)系統(tǒng)基本能夠滿足高性能要求。如果請求的響應時間在200ms以內(nèi)，那么用戶不會感受到延遲；而如果請求的響應時間超過1s，那么用戶會明顯感受到延遲。
可用性=系統(tǒng)正常運行時間/系統(tǒng)總運行時間，表示一個系統(tǒng)正常運行的時間占比，也可以將其理解為一個系統(tǒng)對外可用的概率。我們一般使用N個9來描述系統(tǒng)的可用性如何，如表所示。
圖片
高可用性要求系統(tǒng)至少保證3個9或4個9的可用性。在實際的系統(tǒng)指標監(jiān)控中，很多公司會取3個9和4個9的中位數(shù)：99.95%（3個9、1個5），作為系統(tǒng)可用性監(jiān)控的閾值。當監(jiān)控到系統(tǒng)可用性低于99.95%時及時發(fā)出告警信息，以便系統(tǒng)維護者可以及時做出優(yōu)化，如系統(tǒng)可用性補救、擴容、分析故障原因、系統(tǒng)改造等。
面對到來的突發(fā)流量，我們明顯來不及對系統(tǒng)做架構(gòu)改造，而更快捷、有效的做法是增加系統(tǒng)集群中的節(jié)點來水平擴展系統(tǒng)的服務能力。可擴展性=吞吐量提升比例/集群節(jié)點增加比例。
在最理想的情況下，集群節(jié)點增加幾倍，系統(tǒng)吞吐量就能增加幾倍。一般來說，擁有70%～80%可擴展性的系統(tǒng)基本能夠滿足可擴展性要求。
高并發(fā)場景分類
我們使用計算機實現(xiàn)各種業(yè)務功能，最終將體現(xiàn)在對數(shù)據(jù)的兩種操作上，即讀和寫，于是高并發(fā)請求可以被歸類為高并發(fā)讀和高并發(fā)寫。
比如有的業(yè)務場景讀多寫少，需要重點解決高并發(fā)讀的問題；有的業(yè)務場景寫多讀少，需要重點解決高并發(fā)寫的問題；而有的業(yè)務場景讀多寫多，則需要同時解決高并發(fā)讀和高并發(fā)寫的問題。
將高并發(fā)場景劃分為高并發(fā)讀場景和高并發(fā)寫場景，是因為在這兩種場景中往往有不同的高并發(fā)解決方案。
大部分互聯(lián)網(wǎng)應用都是讀多寫少的，比如刷帖的請求永遠比發(fā)帖的請求多，瀏覽商品的請求永遠比下單購買商品的請求多。數(shù)據(jù)庫承受的高并發(fā)請求壓力，主要來自讀請求。
我們可以把數(shù)據(jù)庫按照讀/寫請求分成專門負責處理寫請求的數(shù)據(jù)庫（寫庫）和專門負責處理讀請求的數(shù)據(jù)庫（讀庫），讓所有的寫請求都落到寫庫，寫庫將寫請求處理后的最新數(shù)據(jù)同步到讀庫，所有的讀請求都從讀庫中讀取數(shù)據(jù)。這就是數(shù)據(jù)庫讀/寫分離的思路。
數(shù)據(jù)庫讀/寫分離使大量的讀請求從數(shù)據(jù)庫中分離出來，減少了數(shù)據(jù)庫訪問壓力，縮短了請求響應時間。
讀/寫分離架構(gòu)
我們通常使用數(shù)據(jù)庫主從復制技術實現(xiàn)讀/寫分離架構(gòu)，將數(shù)據(jù)庫主節(jié)點Master作為“寫庫”，將數(shù)據(jù)庫從節(jié)點Slave作為“讀庫”，一個Master可以與多個Slave連接，如圖所示。
圖片
市面上各主流數(shù)據(jù)庫都實現(xiàn)了主從復制技術。
在數(shù)據(jù)庫讀/寫分離架構(gòu)下，把寫請求交給Master處理，而把讀請求交給Slave處理，那么由什么角色來執(zhí)行這樣的讀/寫請求路由呢？一般可以采用如下兩種方式。
在業(yè)務服務和數(shù)據(jù)庫服務器之間增加數(shù)據(jù)庫Proxy代理節(jié)點（下文簡稱Proxy），業(yè)務服務對數(shù)據(jù)庫的一切操作都需要經(jīng)過Proxy轉(zhuǎn)發(fā)。
Proxy收到業(yè)務服務的數(shù)據(jù)庫操作請求后，根據(jù)請求中的SQL語句進行歸類，將屬于寫操作的請求（如insert/delete/update語句）轉(zhuǎn)發(fā)到數(shù)據(jù)庫Master，將屬于讀操作的請求（如select語句）轉(zhuǎn)發(fā)到數(shù)據(jù)庫任意一個Slave，完成讀/寫分離的路由。
開源項目如中心化代理形式的MySQL-Proxy和MyCat，以及本地代理形式的MySQL-Router等都實現(xiàn)了讀/寫分離功能。
基于應用內(nèi)嵌的方式與基于數(shù)據(jù)庫Proxy代理的方式的主要區(qū)別是，它在業(yè)務服務進程內(nèi)進行請求讀/寫分離，數(shù)據(jù)庫連接框架開源項目如gorm、shardingjdbc等都實現(xiàn)了此形式的讀/寫分離功能。
數(shù)據(jù)庫讀/寫分離架構(gòu)依賴數(shù)據(jù)庫主從復制技術，而數(shù)據(jù)庫主從復制存在數(shù)據(jù)復制延遲（主從延遲），因此會導致在數(shù)據(jù)復制延遲期間主從數(shù)據(jù)的不一致，Slave獲取不到最新數(shù)據(jù)。針對主從延遲問題有如下三種解決方案。
數(shù)據(jù)庫主從復制默認是異步模式，Master在寫完數(shù)據(jù)后就返回成功了，而不管Slave是否收到此數(shù)據(jù)。我們可以將主從復制配置為同步模式，Master在寫完數(shù)據(jù)后，要等到全部Slave都收到此數(shù)據(jù)后才返回成功。
這種方案可以保證數(shù)據(jù)庫每次寫操作成功后，Master和Slave都能讀取到最新數(shù)據(jù)。這種方案相對簡單，將數(shù)據(jù)庫主從復制修改為同步模式即可，無須改造業(yè)務服務。
但是由于在處理業(yè)務寫請求時，Master要等到全部Slave都收到數(shù)據(jù)后才能返回成功，寫請求的延遲將大大增加，數(shù)據(jù)庫的吞吐量也會有明顯的下滑。這種方案的實用價值較低，僅適合在低并發(fā)請求的業(yè)務場景中使用。
不同的業(yè)務場景對主從延遲的容忍性不一樣。例如，用戶a剛剛發(fā)布了一條狀態(tài)，他瀏覽個人主頁時應該展示這條狀態(tài)，這個場景不太能容忍主從延遲；而好友用戶b此時瀏覽用戶a的個人主頁時，可以暫時看不到用戶a最新發(fā)布的狀態(tài)，這個場景可以容忍主從延遲。我們可以對業(yè)務場景按照主從延遲容忍性的高低進行劃分，對于主從延遲容忍性高的場景，執(zhí)行正常的讀/寫分離邏輯；而對于主從延遲容忍性低的場景，強制將讀請求路由到數(shù)據(jù)庫Master，即強制讀主。
比如某會話在數(shù)據(jù)庫中執(zhí)行了寫操作，那么在接下來極短的一段時間內(nèi)，此會話的讀請求暫時被強制路由到數(shù)據(jù)庫Master，與“強制讀主”方案中的例子很像，保證每個用戶的寫操作立刻對自己可見。
暫時強制讀主的時間可以被設定為略高于數(shù)據(jù)庫完成主從數(shù)據(jù)復制的延遲時間，盡量使強制讀主的時間段覆蓋主從數(shù)據(jù)復制的實際延遲時間。
在計算機世界中，緩存（Cache）無處不在，如CPU緩存、DNS緩存、瀏覽器緩存等。值得一提的是，Cache在我國臺灣地區(qū)被譯為“快取”，更直接地體現(xiàn)了它的用途：快速讀取。緩存的本質(zhì)是通過空間換時間的思路來保證數(shù)據(jù)的快速讀取。
業(yè)務服務一般需要通過網(wǎng)絡調(diào)用向其他服務或數(shù)據(jù)庫發(fā)送讀數(shù)據(jù)請求。為了提高數(shù)據(jù)的讀取效率，業(yè)務服務進程可以將已經(jīng)獲取到的數(shù)據(jù)緩存到本地內(nèi)存中，之后業(yè)務服務進程收到相同的數(shù)據(jù)請求時就可以直接從本地內(nèi)存中獲取數(shù)據(jù)返回，將網(wǎng)絡請求轉(zhuǎn)化為高效的內(nèi)存存取邏輯。這就是本地緩存的主要用途。在本書后面的核心服務設計篇中會大量應用本地緩存，本節(jié)先重點介紹本地緩存的技術原理。
基本的緩存淘汰策略
雖然緩存使用空間換時間可以提高數(shù)據(jù)的讀取效率，但是內(nèi)存資源的珍貴決定了本地緩存不可無限擴張，需要在占用空間和節(jié)約時間之間進行權(quán)衡。這就要求本地緩存能自動淘汰一些緩存的數(shù)據(jù)，淘汰策略應該盡量保證淘汰不再被使用的數(shù)據(jù)，保證有較高的緩存命中率。基本的緩存淘汰策略如下。
◎FIFO（First In First Out）策略：優(yōu)先淘汰最早進入緩存的數(shù)據(jù)。這是最簡單的淘汰策略，可以基于隊列實現(xiàn)。但是此策略的緩存命中率較低，越是被頻繁訪問的數(shù)據(jù)是越早進入隊列的，于是會被越早地淘汰。此策略在實踐中很少使用。
◎LFU（Least Frequently Used）策略：優(yōu)先淘汰最不常用的數(shù)據(jù)。LFU策略會為每條緩存數(shù)據(jù)維護一個訪問計數(shù)，數(shù)據(jù)每被訪問一次，其訪問計數(shù)就加1，訪問計數(shù)最小的數(shù)據(jù)是被淘汰的目標。此策略很適合緩存在短時間內(nèi)會被頻繁訪問的熱點數(shù)據(jù)，但是最近最新緩存的數(shù)據(jù)總會被淘汰，而早期訪問頻率高但最近一直未被訪問的數(shù)據(jù)會長期占用緩存。
◎LRU（Least Recent Used）策略：優(yōu)先淘汰緩存中最近最少使用的數(shù)據(jù)。此策略一般基于雙向鏈表和哈希表配合實現(xiàn)。雙向鏈表負責存儲緩存數(shù)據(jù)，并總是將最近被訪問的數(shù)據(jù)放置在尾部，使緩存數(shù)據(jù)在雙向鏈表中按照最近訪問時間由遠及近排序，每次被淘汰的都是位于雙向鏈表頭部的數(shù)據(jù)。哈希表負責定位數(shù)據(jù)在雙向鏈表中的位置，以便實現(xiàn)快速數(shù)據(jù)訪問。此策略可以有效提高短期內(nèi)熱點數(shù)據(jù)的緩存命中率，但如果是偶發(fā)性地訪問冷數(shù)據(jù)，或者批量訪問數(shù)據(jù)，則會導致熱點數(shù)據(jù)被淘汰，進而降低緩存命中率。
LRU策略和LFU策略的缺點是都會導致緩存命中率大幅下降。近年來，業(yè)界出現(xiàn)了一些更復雜、效果更好的緩存淘汰策略，比如W-TinyLFU策略。
由于本地緩存把數(shù)據(jù)緩存在服務進程的內(nèi)存中，不需要網(wǎng)絡開銷，故而性能非常高。但是把數(shù)據(jù)緩存到內(nèi)存中也有較多限制，舉例如下。
◎無法共享：多個服務進程之間無法共享本地緩存。
◎編程語言限制：本地緩存與程序綁定，用Golang語言開發(fā)的本地緩存組件不可以直接為用Java語言開發(fā)的服務器所使用。
◎可擴展性差：由于服務進程攜帶了數(shù)據(jù)，因此服務是有狀態(tài)的。有狀態(tài)的服務不具備較好的可擴展性。
◎內(nèi)存易失性：服務進程重啟，緩存數(shù)據(jù)全部丟失。
我們需要一種支持多進程共享、與編程語言無關、可擴展、數(shù)據(jù)可持久化的緩存，這種緩存就是分布式緩存。
主流的分布式緩存開源項目有Memcached和Redis，兩者都是優(yōu)秀的緩存產(chǎn)品，并且都具有緩存數(shù)據(jù)共享、與編程語言無關的能力。不過，相對于Memcached而言，Redis更為流行，主要體現(xiàn)如下。
◎數(shù)據(jù)類型豐富：Memcached僅支持字符串數(shù)據(jù)類型緩存，而Redis支持字符串、列表、集合、哈希、有序集合等數(shù)據(jù)類型緩存。
◎數(shù)據(jù)可持久化：Redis通過RDB機制和AOF機制支持數(shù)據(jù)持久化，而Memcached沒有數(shù)據(jù)持久化能力。
◎高可用性：Redis支持主從復制模式，在服務器遇到故障后，它可以通過主從切換操作保證緩存服務不間斷。Redis具有較高的可用性。
◎分布式能力：Memcached本身并不支持分布式，因此只能通過客戶端，以一致性哈希這樣的負載均衡算法來實現(xiàn)基于Memcached的分布式緩存系統(tǒng)。而Redis有官方出品的無中心分布式方案Redis Cluster，業(yè)界也有豆瓣Codis和推特Twemproxy的中心化分布式方案。
由于Redis支持豐富的數(shù)據(jù)類型和數(shù)據(jù)持久化，同時擁有高可用性和高可擴展性，因此它成為大部分互聯(lián)網(wǎng)應用分布式緩存的首選。
使用Redis緩存的邏輯如下。
（1）嘗試在Redis緩存中查找數(shù)據(jù)，如果命中緩存，則返回數(shù)據(jù)。
（2）如果在Redis緩存中找不到數(shù)據(jù)，則從數(shù)據(jù)庫中讀取數(shù)據(jù)。
（3）將從數(shù)據(jù)庫中讀取到的數(shù)據(jù)保存到Redis緩存中，并為此數(shù)據(jù)設置一個過期時間。
（4）下次在Redis緩存中查找同樣的數(shù)據(jù)，就會命中緩存。
將數(shù)據(jù)保存到Redis緩存時，需要為數(shù)據(jù)設置一個合適的過期時間，這樣做有以下兩個好處。
◎如果沒有為緩存數(shù)據(jù)設置過期時間，那么數(shù)據(jù)會一直堆積在Redis內(nèi)存中，尤其是那些不再被訪問或者命中率極低的緩存數(shù)據(jù)，它們一直占據(jù)Redis內(nèi)存會造成大量的資源浪費。設置過期時間可以使Redis自動刪除那些不再被訪問的緩存數(shù)據(jù)，而對于經(jīng)常被訪問的緩存數(shù)據(jù)，每次被訪問時都重置過期時間，可以保證緩存命中率高。
◎當數(shù)據(jù)庫與Redis緩存由于各種故障出現(xiàn)了數(shù)據(jù)不一致的情況時，過期時間是一個很好的兜底手段。例如，設置緩存數(shù)據(jù)的過期時間為10s，那么數(shù)據(jù)庫和Redis緩存即使出現(xiàn)數(shù)據(jù)不一致的情況，最多也就持續(xù)10s。過期時間可以保證數(shù)據(jù)庫和Redis緩存僅在此時間段內(nèi)有數(shù)據(jù)不一致的情況，因此可以保證數(shù)據(jù)的最終一致性。
在上述邏輯中，有一個極有可能帶來風險的操作：某請求訪問的數(shù)據(jù)在Redis緩存中不存在，此請求會訪問數(shù)據(jù)庫讀取數(shù)據(jù)；而如果有大量的請求訪問數(shù)據(jù)庫，則可能導致數(shù)據(jù)庫崩潰。Redis緩存中不存在某數(shù)據(jù)，只可能有兩種原因：一是在Redis緩存中從未存儲過此數(shù)據(jù)，二是此數(shù)據(jù)已經(jīng)過期。下面我們就這兩種原因來做有針對性的優(yōu)化。
當用戶試圖請求一條連數(shù)據(jù)庫中都不存在的非法數(shù)據(jù)時，Redis緩存會顯得形同虛設。
（1）嘗試在Redis緩存中查找此數(shù)據(jù)，如果命中，則返回數(shù)據(jù)。
（2）如果在Redis緩存中找不到此數(shù)據(jù)，則從數(shù)據(jù)庫中讀取數(shù)據(jù)。
（3）如果在數(shù)據(jù)庫中也找不到此數(shù)據(jù)，則最終向用戶返回空數(shù)據(jù)
可以看到，Redis緩存完全無法阻擋此類請求直接訪問數(shù)據(jù)庫。如果黑客惡意持續(xù)發(fā)起請求來訪問某條不存在的非法數(shù)據(jù)，那么這些非法請求會全部穿透Redis緩存而直接訪問數(shù)據(jù)庫，最終導致數(shù)據(jù)庫崩潰。這種情況被稱為“緩存穿透”。
為了防止出現(xiàn)緩存穿透的情況，當在數(shù)據(jù)庫中也找不到某數(shù)據(jù)時，可以在Redis緩存中為此數(shù)據(jù)保存一個空值，用于表示此數(shù)據(jù)為空。這樣一來，之后對此數(shù)據(jù)的請求均會被Redis緩存攔截，從而阻斷非法請求對數(shù)據(jù)庫的騷擾。
不過，如果黑客訪問的不是一條非法數(shù)據(jù)，而是大量不同的非法數(shù)據(jù)，那么此方案會使得Redis緩存中存儲大量無用的空數(shù)據(jù)，甚至會逐出較多的合法數(shù)據(jù)，大大降低了Redis緩存命中率，數(shù)據(jù)庫再次面臨風險。我們可以使用布隆過濾器來解決緩存穿透問題。
布隆過濾器由一個固定長度為m的二進制向量和k個哈希函數(shù)組成。當某數(shù)據(jù)被加入布隆過濾器中后，k個哈希函數(shù)為此數(shù)據(jù)計算出k個哈希值并與m取模，并且在二進制向量對應的N個位置上設置值為1；如果想要查詢某數(shù)據(jù)是否在布隆過濾器中，則可以通過相同的哈希計算后在二進制向量中查看這k個位置值：
◎如果有任意一個位置值為0，則說明被查詢的數(shù)據(jù)一定不存在；
◎如果所有的位置值都為1，則說明被查詢的數(shù)據(jù)可能存在。之所以說可能存在，是因為哈希函數(shù)免不了會有數(shù)據(jù)碰撞的可能，在這種情況下會造成對某數(shù)據(jù)的誤判，不過可以通過調(diào)整m和k的值來降低誤判率。
雖然布隆過濾器對于“數(shù)據(jù)存在”有一定的誤判，但是對于“數(shù)據(jù)不存在”的判定是準確的。布隆過濾器很適合用來防止緩存穿透：將數(shù)據(jù)庫中的全部數(shù)據(jù)加入布隆過濾器中，當用戶請求訪問某數(shù)據(jù)但是在Redis緩存中找不到時，檢查布隆過濾器中是否記錄了此數(shù)據(jù)。如果布隆過濾器認為數(shù)據(jù)不存在，則用戶請求不再訪問數(shù)據(jù)庫；如果布隆過濾器認為數(shù)據(jù)可能存在，則用戶請求繼續(xù)訪問數(shù)據(jù)庫；如果在數(shù)據(jù)庫中找不到此數(shù)據(jù)，則在Redis緩存中設置空值。雖然布隆過濾器對“數(shù)據(jù)存在”有一定的誤判，但是誤判率較低。最后在Redis緩存中設置的空值也很少，不會影響Redis緩存命中率。
如果在同一時間Redis緩存中的數(shù)據(jù)大面積過期，則會導致請求全部涌向數(shù)據(jù)庫。這種情況被稱為“緩存雪崩”。緩存雪崩與緩存穿透的區(qū)別是，前者是很多緩存數(shù)據(jù)不存在造成的，后者是一條緩存數(shù)據(jù)不存在導致的。
緩存雪崩一般有兩種誘因：大量數(shù)據(jù)有相同的過期時間，或者Redis服務宕機。第一種誘因的解決方案比較簡單，可以在為緩存數(shù)據(jù)設置過期時間時，讓過期時間的值在預設的小范圍內(nèi)隨機分布，避免大部分緩存數(shù)據(jù)有相同的過期時間。第二種誘因取決于Redis的可用性，選取高可用的Redis集群架構(gòu)可以極大地降低Redis服務宕機的概率。
無論是數(shù)據(jù)庫讀/寫分離、本地緩存還是分布式緩存，其本質(zhì)上都是讀/寫分離，這也是在微服務架構(gòu)中經(jīng)常被提及的CQRS模式。CQRS（Command Query Responsibility Segregation，命令查詢職責分離）是一種將數(shù)據(jù)的讀取操作與更新操作分離的模式。query指的是讀取操作，而command是對會引起數(shù)據(jù)變化的操作的總稱，新增、刪除、修改這些操作都是命令。
圖片
（1）當業(yè)務服務收到客戶端發(fā)起的command請求（即寫請求）時，會將此請求交給寫數(shù)據(jù)存儲來處理。
（2）寫數(shù)據(jù)存儲完成數(shù)據(jù)變更后，將數(shù)據(jù)變更消息發(fā)送到消息隊列。
（3）讀數(shù)據(jù)存儲負責監(jiān)聽消息隊列，當它收到數(shù)據(jù)變更消息后，將數(shù)據(jù)寫入自身。
（4）當業(yè)務服務收到客戶端發(fā)起的query請求（即讀請求）時，將此請求交給讀數(shù)據(jù)存儲來處理。
（5）讀數(shù)據(jù)存儲將此請求希望訪問的數(shù)據(jù)返回。
寫數(shù)據(jù)存儲、讀數(shù)據(jù)存儲、數(shù)據(jù)傳輸通道均是較為寬泛的代稱，其中寫數(shù)據(jù)存儲和讀數(shù)據(jù)存儲在不同的高并發(fā)場景下有不同的具體指代，數(shù)據(jù)傳輸通道在不同的高并發(fā)場景下有不同的形式體現(xiàn)，可能是消息隊列、定時任務等。
◎?qū)τ跀?shù)據(jù)庫讀/寫分離來說，寫數(shù)據(jù)存儲是 Master，讀數(shù)據(jù)存儲是 Slave，消息隊列的實現(xiàn)形式是數(shù)據(jù)庫主從復制。
◎?qū)τ诜植际骄彺鎴鼍皝碚f，寫數(shù)據(jù)存儲是數(shù)據(jù)庫，讀數(shù)據(jù)存儲是 Redis 緩存，消息隊列的實現(xiàn)形式是使用消息中間件監(jiān)聽數(shù)據(jù)庫的binlog數(shù)據(jù)變更日志。
無論是何種場景，都應該為寫數(shù)據(jù)存儲選擇適合高并發(fā)寫入的存儲系統(tǒng)，為讀數(shù)據(jù)存儲選擇適合高并發(fā)讀取的存儲系統(tǒng)，消息隊列作為數(shù)據(jù)傳輸通道要足夠健壯，保證數(shù)據(jù)不丟失。
本文鏈接：http://www.tebozhan.com/showinfo-26-91018-0.html億級流量下通用的高并發(fā)架構(gòu)設計
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號