日本乱偷中文字幕,美女脱内衣18禁免费看,亚洲国产精品丝袜在线观看,18女人腿打开无遮挡,廖承宇chinese野战做受

Redis服務(wù)器輔助的客戶(hù)端緩存

客戶(hù)端緩存是一種用于創(chuàng )建高性能服務(wù)的技術(shù)。它利用應用服務(wù)器中的可用內存，這些服務(wù)器通常是與數據庫節點(diǎn)不同的計算機，以便將數據庫信息的某些子集直接存儲在應用程序端。

通常當需要一些數據時(shí)，應用服務(wù)器會(huì )向數據庫詢(xún)問(wèn)這些信息，如下圖所示：

+-------------+                                +----------+
|             | ------- GET user:1234 -------> |          |
| Application |                                | Database |
|             | <---- username = Alice ------- |          |
+-------------+                                +----------+

當使用客戶(hù)端緩存時(shí)，應用程序將直接在應用程序內存中存儲流行查詢(xún)的答復，以便以后可以重用這些答復，而無(wú)需再次聯(lián)系數據庫。

+-------------+                                +----------+
|             |                                |          |
| Application |       ( No chat needed )       | Database |
|             |                                |          |
+-------------+                                +----------+
| Local cache |
|             |
| user:1234 = |
| username    |
| Alice       |
+-------------+

雖然用于本地緩存的應用程序內存可能不是很大，但是訪(fǎng)問(wèn)本地計算機內存所需的時(shí)間比請求數據庫之類(lèi)的網(wǎng)絡(luò )服務(wù)要小幾個(gè)數量級。由于經(jīng)常非常頻繁地訪(fǎng)問(wèn)同一小部分數據，因此這種模式可以大大減少應用程序獲取數據的延遲，同時(shí)也減少數據庫端的負載。

此外，有許多數據集中的項很少更改。例如，社交網(wǎng)絡(luò )中的大多數用戶(hù)帖子要么是不可變的，要么很少被用戶(hù)編輯。再加上一個(gè)事實(shí)，通常只有一小部分的帖子非常受歡迎，要么是因為一小部分用戶(hù)有很多關(guān)注者，要么是因為最近的帖子有更多的可見(jiàn)性，這就很清楚為什么這種模式非常有用。

通常，客戶(hù)端緩存的兩個(gè)主要優(yōu)點(diǎn)是：

• 數據可用，延遲非常小。
• 數據庫系統接收的查詢(xún)較少，允許使用較少的節點(diǎn)為同一數據集提供服務(wù)。

存在問(wèn)題

上述模式的一個(gè)問(wèn)題是如何使應用程序所保存的信息無(wú)效，以避免向用戶(hù)呈現過(guò)時(shí)的數據。例如，在上面的應用程序本地緩存用戶(hù)：1234信息，Alice可能會(huì )將她的用戶(hù)名更新為Flora。然而，應用程序可能繼續為用戶(hù)1234提供舊用戶(hù)名。

根據我們所建模的應用程序的具體情況，這個(gè)問(wèn)題并不是什么大問(wèn)題，因此客戶(hù)機只會(huì )使用固定的最大“生存時(shí)間”來(lái)存儲緩存的信息。一旦經(jīng)過(guò)給定的時(shí)間，信息將不再被視為有效。在使用Redis時(shí)，更復雜的模式利用Pub/Sub系統向監聽(tīng)的客戶(hù)端發(fā)送無(wú)效消息。這是可以實(shí)現的，但是從所使用的帶寬的角度來(lái)看，這是非常棘手和昂貴的，因為這樣的模式通常涉及到向應用程序中的每個(gè)客戶(hù)端發(fā)送無(wú)效消息，即使某些客戶(hù)端可能沒(méi)有無(wú)效數據的任何副本。此外，每個(gè)更改數據的應用程序查詢(xún)都需要使用PUBLISH命令，這會(huì )使數據庫花費更多的CPU時(shí)間來(lái)處理該命令。

不管使用什么模式，有一個(gè)簡(jiǎn)單的事實(shí)：許多非常大的應用程序實(shí)現某種形式的客戶(hù)端緩存，因為這是擁有快速存儲或快速緩存服務(wù)器的下一個(gè)邏輯步驟。為此，redis6實(shí)現了對客戶(hù)端緩存的直接支持，以使該模式實(shí)現起來(lái)更簡(jiǎn)單、更易訪(fǎng)問(wèn)、更可靠、更高效。

客戶(hù)端緩存的Redis實(shí)現

Redis客戶(hù)端緩存支持稱(chēng)為跟蹤，有兩種模式：

• 在默認模式下，服務(wù)器會(huì )記住給定客戶(hù)機訪(fǎng)問(wèn)的密鑰，并在修改相同的密鑰時(shí)發(fā)送無(wú)效消息。這會(huì )消耗服務(wù)器端的內存，但只會(huì )為客戶(hù)端可能在內存中擁有的一組密鑰發(fā)送無(wú)效消息。
• 在廣播模式下，服務(wù)器不會(huì )試圖記住給定客戶(hù)機訪(fǎng)問(wèn)的密鑰，因此這種模式在服務(wù)器端根本不消耗任何內存。相反，客戶(hù)機訂閱密鑰前綴，如object:或user:，并且在每次碰到與該前綴匹配的密鑰時(shí)都會(huì )收到一條通知消息。

回顧一下，現在讓我們暫時(shí)忘掉廣播模式，集中討論第一種模式。稍后我們將更詳細地描述廣播。

• 如果需要，客戶(hù)端可以啟用跟蹤。連接在未啟用跟蹤的情況下啟動(dòng)。
• 啟用跟蹤后，服務(wù)器會(huì )記住每個(gè)客戶(hù)端在連接生存期內請求的密鑰（通過(guò)發(fā)送關(guān)于這些密鑰的read命令）。
• 當某個(gè)客戶(hù)端修改了某個(gè)密鑰，或者因為該密鑰具有相關(guān)的過(guò)期時(shí)間而被逐出，或者由于maxmemory策略而被逐出時(shí)，所有啟用了跟蹤且可能緩存了該密鑰的客戶(hù)端都將收到一條無(wú)效消息。
• 當客戶(hù)機接收到無(wú)效消息時(shí)，它們需要刪除相應的密鑰，以避免提供過(guò)時(shí)的數據。

這是協(xié)議的一個(gè)例子：

Client 1 -> Server: CLIENT TRACKING ON
Client 1 -> Server: GET foo
(The server remembers that Client 1 may have the key "foo" cached)
(Client 1 may remember the value of "foo" inside its local memory)
Client 2 -> Server: SET foo SomeOtherValue
Server -> Client 1: INVALIDATE "foo"

從表面上看，這看起來(lái)很不錯，但是如果你認為，在每一個(gè)長(cháng)時(shí)間連接的故事中，有10k個(gè)連接的客戶(hù)端都需要數百萬(wàn)個(gè)密鑰，那么服務(wù)器最終會(huì )存儲太多的信息。為此，Redis使用了兩個(gè)關(guān)鍵思想來(lái)限制服務(wù)器端的內存使用量，以及處理實(shí)現該功能的數據結構的CPU成本：

• 服務(wù)器會(huì )記住可能已在單個(gè)全局表中緩存給定鍵的客戶(hù)端列表。這個(gè)表叫做失效表。這樣的無(wú)效表可以包含最大數量的條目，如果插入了一個(gè)新的鍵，服務(wù)器可以通過(guò)假裝該鍵被修改（即使沒(méi)有修改），并向客戶(hù)端發(fā)送無(wú)效消息來(lái)逐出舊條目。這樣做，它可以回收用于此密鑰的內存，即使這將迫使擁有密鑰本地副本的客戶(hù)端將其逐出。
• 在失效表中，我們實(shí)際上不需要存儲指向客戶(hù)端結構的指針，這將在客戶(hù)端斷開(kāi)連接時(shí)強制執行垃圾回收過(guò)程：相反，我們所做的只是存儲客戶(hù)端ID（每個(gè)Redis客戶(hù)端都有一個(gè)唯一的數字ID）。如果一個(gè)客戶(hù)機斷開(kāi)連接，信息將隨著(zhù)緩存槽的失效而逐漸被垃圾回收。
• 只有一個(gè)鍵名稱(chēng)空間，不除以數據庫編號。因此，如果一個(gè)客戶(hù)機正在緩存數據庫2中的key foo，而其他一些客戶(hù)機更改了數據庫3中key foo的值，那么仍然會(huì )發(fā)送一條無(wú)效消息。通過(guò)這種方式，我們可以忽略數據庫編號，從而降低內存使用量和實(shí)現復雜性。

雙連接方式

使用Redis 6支持的新版Redis協(xié)議RESP3，可以在同一連接中運行數據查詢(xún)和接收失效消息。然而，許多客戶(hù)端實(shí)現可能更喜歡使用兩個(gè)獨立的連接來(lái)實(shí)現客戶(hù)端緩存：一個(gè)用于數據，另一個(gè)用于無(wú)效消息。因此，當客戶(hù)端啟用跟蹤時(shí)，它可以指定通過(guò)指定不同連接的“客戶(hù)端ID”將無(wú)效消息重定向到另一個(gè)連接。許多數據連接可以將無(wú)效消息重定向到同一個(gè)連接，這對于實(shí)現連接池的客戶(hù)端很有用。雙連接模型是唯一支持RESP2的模型（它缺乏在同一連接中復用不同類(lèi)型信息的能力）。

我們將展示一個(gè)例子，這一次在舊的RRESP2模式下使用實(shí)際的Redis協(xié)議，如何完成會(huì )話(huà)，包括以下步驟：?jiǎn)⒂酶欀囟ㄏ虻搅硪粋€(gè)連接，請求密鑰，以及在該密鑰被修改后獲得無(wú)效消息。

首先，客戶(hù)機打開(kāi)第一個(gè)將用于失效的連接，請求連接ID，并通過(guò)Pub/Sub訂閱用于在RESP2模式下獲取失效消息的特殊通道（記住RESP2是通常的Redis協(xié)議，而不是可以與Redis一起使用的更高級的協(xié)議）6使用HELLO命令）：

(Connection 1 -- used for invalidations)
CLIENT ID
:4
SUBSCRIBE __redis__:invalidate
*3
$9
subscribe
$20
__redis__:invalidate
:1

現在我們可以從數據連接啟用跟蹤：

(Connection 2 -- data connection)
CLIENT TRACKING on REDIRECT 4
+OK

GET foo
$3
bar

客戶(hù)機可能決定在本地內存中緩存“foo”=>“bar”。

另一個(gè)客戶(hù)端現在將修改“foo”鍵的值：

(Some other unrelated connection)
SET foo bar
+OK

因此，失效連接將接收一條消息，使指定的鍵失效。

(Connection 1 -- used for invalidations)
*3
$7
message
$20
__redis__:invalidate
*1
$3
foo

客戶(hù)端將檢查這種緩存槽中是否有緩存的密鑰，并將逐出不再有效的信息。

請注意，發(fā)布/訂閱消息的第三個(gè)元素不是一個(gè)鍵，而是一個(gè)只有一個(gè)元素的Redis數組。因為我們發(fā)送了一個(gè)數組，如果有一組鍵要失效，我們可以在一條消息中完成。

要了解RESP2使用的客戶(hù)端緩存和用于讀取無(wú)效消息的Pub/Sub連接的一個(gè)非常重要的事情是，為了重用舊的客戶(hù)端實(shí)現，使用Pub/Sub完全是一個(gè)技巧，但實(shí)際上消息并不是真正發(fā)送到一個(gè)通道并由訂閱它的所有客戶(hù)端接收。只有我們在CLIENT命令的REDIRECT參數中指定的連接才會(huì )真正接收Pub/Sub消息，這使得特性更具可伸縮性。

當改為使用RESP3時(shí)，無(wú)效消息將作為推送消息發(fā)送（在同一連接中，或者在使用重定向時(shí)在輔助連接中發(fā)送）（有關(guān)詳細信息，請閱讀RESP3規范）。

什么跟蹤記錄

默認情況下，客戶(hù)機不需要告訴服務(wù)器它們正在緩存哪些密鑰。服務(wù)器會(huì )跟蹤只讀命令上下文中提到的每個(gè)鍵，因為它可以被緩存。

這樣做的明顯優(yōu)點(diǎn)是不需要客戶(hù)機告訴服務(wù)器它在緩存什么。此外，在許多客戶(hù)機實(shí)現中，這正是您所希望的，因為一個(gè)好的解決方案可以是使用先進(jìn)先出的方法緩存所有尚未緩存的對象：我們可能希望緩存固定數量的對象，我們檢索到的每一個(gè)新數據都可以緩存它，丟棄最舊的緩存對象。更高級的實(shí)現可能會(huì )放棄使用最少的對象或類(lèi)似對象。

請注意，不管怎樣，如果服務(wù)器上有寫(xiě)流量，緩存槽將在這段時(shí)間內失效。一般情況下，當服務(wù)器假定我們得到的東西也要緩存時(shí)，我們正在權衡：

• 當客戶(hù)機傾向于用一個(gè)歡迎新對象的策略緩存許多東西時(shí)，這種方法更有效。
• 服務(wù)器將被迫保留有關(guān)客戶(hù)端密鑰的更多數據。
• 客戶(hù)端將收到關(guān)于它沒(méi)有緩存的對象的無(wú)效消息。