在线观看www成人影院-在线观看www日本免费网站-在线观看www视频-在线观看操-欧美18在线-欧美1级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

一文理解 Redis 的核心原理與技術(shù)

數(shù)據(jù)分析與開發(fā) ? 來(lái)源:何永康 ? 作者:何永康 ? 2021-05-28 10:49 ? 次閱讀

一、Redis 基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)

1. String

Redis 里的字符串是動(dòng)態(tài)字符串,會(huì)根據(jù)實(shí)際情況動(dòng)態(tài)調(diào)整。類似于 Go 里面的切片-slice,如果長(zhǎng)度不夠則自動(dòng)擴(kuò)容。至于如何擴(kuò)容,方法大致如下:當(dāng) length 小于 1M 的時(shí)候,擴(kuò)容規(guī)則將目前的字符串翻倍;如果 length 大于 1M 的話,則每次只會(huì)擴(kuò)容 1M,直到達(dá)到 512M。

e9ea5f1e-bf1a-11eb-9e57-12bb97331649.png

2. List

Redis 里的 List 是一個(gè)鏈表,由于鏈表本身插入和刪除比較塊,但是查詢的效率比較低,所以常常被用做異步隊(duì)列。Redis 里的 List 設(shè)計(jì)非常牛,當(dāng)數(shù)據(jù)量比較小的時(shí)候,數(shù)據(jù)結(jié)構(gòu)是壓縮鏈表,而當(dāng)數(shù)據(jù)量比較多的時(shí)候就成為了快速鏈表。 可運(yùn)用的場(chǎng)景:在業(yè)務(wù)中異步隊(duì)列使用 rpush/lpush 操作隊(duì)列,使用 lpop 和 rpop 出隊(duì)列,具體結(jié)構(gòu)如下圖所示:

e9f5ba08-bf1a-11eb-9e57-12bb97331649.png

3. Set Redis 中的 set 是一個(gè)無(wú)序 Map,由于 Go 中沒(méi)有 set 結(jié)構(gòu),所以這里只能類比 Java 中的 HashSet 概念。Redis 的 set 底層也是一個(gè) Map 結(jié)構(gòu),不同于 Java 的是:alue 是一個(gè) NULL。由于 set 的特性,它可以用于去重邏輯,這一點(diǎn)在 Java 中也經(jīng)常使用。 可運(yùn)用場(chǎng)景:活動(dòng)抽獎(jiǎng)去重。

4. Hash Redis 中的字典類型大家不陌生,也許其他語(yǔ)言都有這種結(jié)構(gòu)(python,Java,Go), hash 的擴(kuò)容 rehash 過(guò)程和 Go 里面的設(shè)計(jì)頗有類似,也就是維護(hù)了兩個(gè) hash 結(jié)構(gòu),如果需要擴(kuò)容的時(shí)候,就把新的數(shù)據(jù)寫入新字典中,然后后端起一個(gè)線程來(lái)逐步遷移,總體上來(lái)說(shuō)就是采用了空間換時(shí)間的思想。 可運(yùn)用場(chǎng)景:記錄業(yè)務(wù)中的不同用戶/不同商品/不同場(chǎng)景的信息:如某個(gè)用戶的名稱,或者用戶的歷史行為。

ea135022-bf1a-11eb-9e57-12bb97331649.png

5. Zset

Redis 中的 zset 是一個(gè)比較特殊的數(shù)據(jù)結(jié)構(gòu)(跳躍列表),也就是我們了解到的跳表,底層由于 set 的特性保證了 value 唯一,同時(shí)也給了 value 一個(gè)得分,所謂的有序其實(shí)就是根據(jù)這個(gè)得分來(lái)排序。至于跳躍表如何插入,其實(shí)內(nèi)部采用了一個(gè)隨機(jī)策略:L0:100%-L2:50%-L3:25%-。。。.Ln:(n-1)value/2%。 可運(yùn)用場(chǎng)景:榜單,總榜,熱榜。

ea236d22-bf1a-11eb-9e57-12bb97331649.png

二、Redis 進(jìn)階使用

1. 布隆過(guò)濾器

Redis 在 4.0 以后支持布隆過(guò)濾(準(zhǔn)確的來(lái)說(shuō)是支持了布隆過(guò)濾器的插件),給 Redis 提供了強(qiáng)大的去重功能。在業(yè)務(wù)中,我們可能需要查詢數(shù)據(jù)庫(kù)判斷歷史數(shù)據(jù)是否存在,如果數(shù)據(jù)庫(kù)的并發(fā)能力有限,這個(gè)時(shí)候我們可以采用 Redis 的 set 做去重。

如果緩存的數(shù)據(jù)過(guò)大,這個(gè)時(shí)候就需要遍歷所有緩存數(shù)據(jù),另外如果我們的歷史數(shù)據(jù)緩存寫不下了,終究要去查詢數(shù)據(jù)庫(kù),這個(gè)時(shí)候就可以使用布隆過(guò)濾器。 當(dāng)然布隆過(guò)濾器精確度不是 100% 準(zhǔn)確(如果對(duì)數(shù)據(jù)準(zhǔn)確度要求很高的話,這里不建議使用),因?yàn)閷?duì)于存在的數(shù)據(jù)也許這個(gè)值不一定存在,當(dāng)然如果不存在,那肯定 100% 不存在了。

(1)命令使用

bf.add #添加元素bf.exists #判斷元素是否存在bf.madd #批量添加bf.mexists #批量判斷是否存在

(2)原理

ea358660-bf1a-11eb-9e57-12bb97331649.png

布隆過(guò)濾的組成可以當(dāng)作一個(gè)位數(shù)組和幾個(gè)計(jì)算結(jié)果比較均勻的 hash 函數(shù),每次添加 key 的時(shí)候,會(huì)把 key 通過(guò)多次 hash 來(lái)計(jì)算所得到的位置,如果當(dāng)前位置不是 0 則表示存在。可以看到,這樣的計(jì)算存在一定誤差,這也正是它的不準(zhǔn)確性問(wèn)題的由來(lái)。

2. 分布式鎖

大家對(duì)分布式鎖也許也不會(huì)陌生,現(xiàn)在市面上主流的實(shí)現(xiàn)分布鎖的技術(shù)有 ZK 和 Redis;下文為大家簡(jiǎn)單介紹一下 Redis 如何實(shí)現(xiàn)分布式鎖。

命令

setnx lock:mutex ture #加鎖del lock:mutex #刪除鎖 實(shí)現(xiàn)分布式鎖的核心就是:請(qǐng)求的時(shí)候 Set 這個(gè) key,如果其他請(qǐng)求設(shè)置失敗的時(shí)候,即拿不到鎖。但是存在一個(gè)問(wèn)題:如果業(yè)務(wù) panic 或者忘記調(diào)用 del 的話,就會(huì)產(chǎn)生死鎖,這個(gè)時(shí)候大家很容易能想到:我們可以 expire 一個(gè)過(guò)期時(shí)間,這樣就可以保證請(qǐng)求不會(huì)一直獨(dú)占鎖且無(wú)法釋放鎖的邏輯了。

但是假設(shè)業(yè)務(wù)存在這樣一種情況:A 請(qǐng)求在獲取鎖后處理邏輯,由于邏輯過(guò)長(zhǎng),這個(gè)時(shí)候鎖到期釋放了,A 這個(gè)時(shí)候剛剛處理完成,而 B 又去改了這個(gè)數(shù)據(jù),這就存在一個(gè)鎖失效的問(wèn)題。解決這種問(wèn)題參考 CAS 的方式,對(duì)鎖設(shè)置一個(gè)隨機(jī)數(shù),可以理解為版本號(hào),如果釋放的時(shí)候版本號(hào)不一致,則表示數(shù)字已經(jīng)在釋放那一刻改掉了。

三、深入原理

1. IO模型

Redis 是單線程模型(這里的單線程指的是 IO 和鍵值對(duì)的讀寫是一個(gè)線程完成的),當(dāng)然如果嚴(yán)謹(jǐn)?shù)膩?lái)說(shuō)還是可以理解為是多線程,不過(guò)這樣的多線程不過(guò)是在數(shù)據(jù)備份的時(shí)候會(huì) fork 一個(gè)子進(jìn)程對(duì)數(shù)據(jù)進(jìn)行從磁盤讀取數(shù)據(jù)并組裝 RDB,然后同步給 slaver 節(jié)點(diǎn)的操作,當(dāng)然包括備份和持久化也都是通過(guò)另外起線程完成的,所以我們可以把 Redis 認(rèn)作為一個(gè)單線程模型。

那么問(wèn)題來(lái)了,為什么單線程的模型能這么快?原因很簡(jiǎn)單,因?yàn)?Redis 本身就是在內(nèi)存中運(yùn)算,而對(duì)于上游的客戶端請(qǐng)求,采用了多路復(fù)用的原理。Redis 會(huì)給每一個(gè)客戶端套接字都關(guān)聯(lián)一個(gè)指令隊(duì)列,客戶端的指令隊(duì)列通過(guò)隊(duì)列排隊(duì)來(lái)進(jìn)行順序處理,同時(shí) Reids 給每一個(gè)客戶端的套件字關(guān)聯(lián)一個(gè)響應(yīng)隊(duì)列,Redis 服務(wù)器通過(guò)響應(yīng)隊(duì)列來(lái)將指令的接口返回給客戶端。

ea6729ea-bf1a-11eb-9e57-12bb97331649.png

Redis IO 處理模型

2. 通信協(xié)議

Redis 采用了 Gossip 協(xié)議作為通信協(xié)議。Gossip 是一種傳播消息的方式,可以類比為瘟疫或者流感的傳播方式,使用 Gossip 協(xié)議的有:Redis Cluster、Consul、Apache Cassandra 等。Gossip 協(xié)議類似病毒擴(kuò)散的方式,將信息傳播到其他的節(jié)點(diǎn),這種協(xié)議效率很高,只需要廣播到附近節(jié)點(diǎn),然后被廣播的節(jié)點(diǎn)繼續(xù)做同樣的操作即可。當(dāng)然這種協(xié)議也有一個(gè)弊端就是:會(huì)存在浪費(fèi),哪怕一個(gè)節(jié)點(diǎn)之前被通知到了,下次被廣播后仍然會(huì)重復(fù)轉(zhuǎn)發(fā)。

3. 持久化

(1)RDB

RDB 是對(duì)當(dāng)前 Redis 的存儲(chǔ)數(shù)據(jù)進(jìn)行一次快照(具體原理和如何做,限于篇幅這里不做過(guò)多復(fù)述了)。

(2)AOF

日志只記錄 Redis 對(duì)內(nèi)存修改的指令記錄,Redis 提供了一個(gè) bgrewriteaif 的指令對(duì) AOF 進(jìn)行壓縮。原理就是:開辟一個(gè)子進(jìn)程對(duì)內(nèi)存進(jìn)行遍歷后,轉(zhuǎn)換成一系列對(duì) Redis 的操作指令,序列化到一個(gè)新的 AOF 日志文件中。系列化完成后再將發(fā)送的增量 AOF 日志追加到這個(gè)新的 AOF 日志中,追加完成后用新的 AOF 日志代替舊的。

(3)混合持久化

由于單純 RDB 的話,可能存在數(shù)據(jù)的丟失,而頻繁的 AOF 又會(huì)影響了性能,在 Redis 4.0 之后,支持了混合持久化,也就是每次啟動(dòng)時(shí)候通過(guò) RDB+增量的 AOF 文件來(lái)進(jìn)行回復(fù),由于增量的 AOF 僅記錄了開始持久化到持久化結(jié)束期間發(fā)生的增量,這樣日志不會(huì)太大,性能相對(duì)較高。

4. 主從同步

Redis 的同步方式有:主從同步、從從同步(由于全部都由 master 同步的話,會(huì)損耗性能,所以部分的 slave 會(huì)通過(guò) slave 之間進(jìn)行同步)。

同步過(guò)程:

建立連接,然后從庫(kù)告訴主庫(kù):“我要同步啦,你給我準(zhǔn)備好”,然后主庫(kù)跟從庫(kù)說(shuō):“收到”。

從庫(kù)拿到數(shù)據(jù)后,要把數(shù)據(jù)保存到庫(kù)里。這個(gè)時(shí)候就會(huì)在本地完成數(shù)據(jù)的加載,會(huì)用到 RDB 。

主庫(kù)把新來(lái)的數(shù)據(jù) AOF 同步給從庫(kù)。

5. Sentinel

Redis 的主從切換是通過(guò)哨兵來(lái)解決的。這里哨兵主要解決的問(wèn)題就是:當(dāng) master 掛了的情況下,如果在短時(shí)間內(nèi)重新選舉出一個(gè)新的 master 。

Sentinel 集群是一個(gè)由 3-5 個(gè)(可以更多)節(jié)點(diǎn)組成的,用來(lái)監(jiān)聽(tīng)整個(gè) Redis 的集群,如果發(fā)現(xiàn) master 不可用的時(shí)候,會(huì)關(guān)閉和斷開全部的與 master 相連的舊鏈接。這個(gè)時(shí)候 Sentinel 會(huì)完成選舉和故障轉(zhuǎn)移,新的請(qǐng)求則會(huì)轉(zhuǎn)到新到 master 中。

6. Redis集群工作原理

Redis 集群通過(guò)槽指派機(jī)制來(lái)決定寫命令應(yīng)該被分配到那個(gè)節(jié)點(diǎn)。整個(gè)集群對(duì)應(yīng)的槽是由 16384 大小的二進(jìn)制數(shù)組組成,集群中每個(gè)主節(jié)點(diǎn)分配一部分槽,每條寫命令落到二進(jìn)制數(shù)組中的某個(gè)位置,該位置被分配給了哪個(gè)節(jié)點(diǎn),則對(duì)應(yīng)的命令就由該節(jié)點(diǎn)去執(zhí)行。槽指派對(duì)應(yīng)的二進(jìn)制數(shù)組如下圖所示:

eae9ca30-bf1a-11eb-9e57-12bb97331649.png

從上圖可以看到:節(jié)點(diǎn) 1 只負(fù)責(zé) 執(zhí)行 0 - 4999 的槽位,而節(jié)點(diǎn) 2 負(fù)責(zé)執(zhí)行 5000 - 9999,節(jié)點(diǎn) 3 執(zhí)行 9999- 16383 。當(dāng)進(jìn)行寫的時(shí)候:

set key value 命令通過(guò)CRC16(key) & 16383 = 6789(假設(shè)結(jié)果),由于節(jié)點(diǎn) 2 負(fù)責(zé) 5000~9999 的槽位,則該命令的結(jié)果 6789 最終由節(jié)點(diǎn) 2 執(zhí)行。當(dāng)然如果在節(jié)點(diǎn) 2 執(zhí)行一條命令時(shí),假設(shè)通過(guò) CRC 計(jì)算后得到的值為 567,則其應(yīng)該由節(jié)點(diǎn) 1 執(zhí)行,此時(shí)命令會(huì)進(jìn)行轉(zhuǎn)向操作,將要執(zhí)行的命令流轉(zhuǎn)到節(jié)點(diǎn) 1 上去執(zhí)行。

eb9a420c-bf1a-11eb-9e57-12bb97331649.png

集群節(jié)點(diǎn)同步:集群中每個(gè)主節(jié)點(diǎn)都會(huì)定時(shí)發(fā)送信息到其他主節(jié)點(diǎn)進(jìn)行同步,如果其他主節(jié)點(diǎn)在規(guī)定時(shí)間內(nèi)響應(yīng)了發(fā)送消息的主節(jié)點(diǎn),則發(fā)送消息的主節(jié)點(diǎn)認(rèn)為響應(yīng)了消息的主節(jié)點(diǎn)正常,反之則認(rèn)為響應(yīng)消息的主節(jié)點(diǎn)疑似下線,則發(fā)送消息的主節(jié)點(diǎn)在其節(jié)點(diǎn)上將其標(biāo)記“疑似下線”。

當(dāng)集群中超過(guò)一半以上的節(jié)點(diǎn)認(rèn)為某個(gè)主節(jié)點(diǎn)被標(biāo)記為“疑似下線”,則其中某個(gè)主節(jié)點(diǎn)將疑似下線節(jié)點(diǎn)標(biāo)記為下線狀態(tài),并向集群廣播一條下線消息,當(dāng)下線節(jié)點(diǎn)對(duì)應(yīng)的從節(jié)點(diǎn)接收到該消息時(shí),則從從節(jié)點(diǎn)中選舉出一個(gè)節(jié)點(diǎn)作為主節(jié)點(diǎn)繼續(xù)對(duì)外提供服務(wù)。

四、Redis為什么變慢了

業(yè)務(wù)場(chǎng)景中,不知道大家是否碰到過(guò) Redis 變慢的情況:

執(zhí)行 SET、DEL 命令耗時(shí)也很久;

偶現(xiàn)卡頓,之后又恢復(fù)正常了;

在某個(gè)時(shí)間點(diǎn),突然開始變慢了。

原因分析

查看慢查詢,由于筆者本身機(jī)器沒(méi)有慢查詢,所以這里看到是空(實(shí)在尷尬,這里沒(méi)有可用的例子~~)

ebcccf92-bf1a-11eb-9e57-12bb97331649.png

由于 Redis 在 IO 操作和對(duì)鍵值對(duì)的操作是單線程的,所以直接在客戶端 Redis-cli 上執(zhí)行的 Redis 命令有可能會(huì)導(dǎo)致操作延遲變大;

使用復(fù)雜的命令會(huì)讓 Redis的處理變慢,以及CPU過(guò)高,例如 SORT、SUNION、ZUNIONSTORE 聚合類命令(時(shí)間負(fù)責(zé)度O(N) );

查詢的數(shù)據(jù)量過(guò)大,使得更多時(shí)間花費(fèi)在數(shù)據(jù)協(xié)議的組裝和網(wǎng)絡(luò)傳輸過(guò)程中;

大 key 查詢,比如對(duì)于一個(gè)很大的 hash、zset 等,這樣的對(duì)象對(duì) Redis 的集群數(shù)據(jù)遷移帶來(lái)了很大的問(wèn)題,因?yàn)樵诩涵h(huán)境下,如果某個(gè) key 太大,會(huì)導(dǎo)致數(shù)據(jù)遷移卡頓;

另外在內(nèi)存分配上,如果一個(gè) key 太大,那么當(dāng)它需要擴(kuò)容時(shí),會(huì)一次性申請(qǐng)更大的一塊內(nèi)存,這也會(huì)導(dǎo)致卡頓。如果這個(gè)大 key 被刪除,內(nèi)存會(huì)一次性回收,卡頓現(xiàn)象會(huì)再一次產(chǎn)生。

集中過(guò)期,變慢的時(shí)間統(tǒng)一,所以業(yè)務(wù)中的 Key 過(guò)期時(shí)間盡量在統(tǒng)一的一個(gè)時(shí)間點(diǎn)加上一個(gè)隨機(jī)數(shù)時(shí)間;

內(nèi)存使用達(dá)到上限,當(dāng)內(nèi)存達(dá)到內(nèi)存上限的時(shí)候,就不許淘汰一些數(shù)據(jù),這個(gè)時(shí)候也可能導(dǎo)致 Redis 查詢效率低;

碎片整理,Redis 在 4.0 版本后會(huì)自動(dòng)整理碎片(由于內(nèi)存回收過(guò)程中存在大量的碎片空間,不整理會(huì)導(dǎo)致 Redis 的空間少量浪費(fèi)),而在整理碎片的過(guò)程中會(huì)消耗 CPU 的資源,從而影響了請(qǐng)求得到性能;

網(wǎng)絡(luò)帶寬,Redis 集群和業(yè)務(wù)混部,或者并發(fā)量過(guò)大以及每次返回的數(shù)據(jù)也很大,網(wǎng)卡帶寬跑滿的情況容易導(dǎo)致網(wǎng)絡(luò)阻塞;

AOF 的頻率過(guò)高,由于 AOF 需要將全部的寫命令同步,如果同步的間隔比較短,也會(huì)影響到 Redis 的性能;

Redis 提供了 flushdb 和 flushall 指令,用來(lái)清空數(shù)據(jù)庫(kù),這也是導(dǎo)致 Redis 緩慢的操作。

五、Redis安全

默認(rèn)會(huì)監(jiān)聽(tīng) 6379 端口,最好在 Redis 的配置文件中指定監(jiān)聽(tīng)的 IP 地址,更進(jìn)一步還可以增加 Redis 的 ACL 訪問(wèn)控制,對(duì)客戶指定群組,并限限制用戶對(duì)數(shù)據(jù)的讀寫權(quán)限。 訪問(wèn) Redis 盡量走公司代理,由于 Redis 本身不支持 SSL 的鏈接,所以走公司代理可以保證安全。客戶端登陸 Redis 必須設(shè)置 Auth 秘密登陸。

編輯:jq

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • cpu
    cpu
    +關(guān)注

    關(guān)注

    68

    文章

    10873

    瀏覽量

    212093
  • ACL
    ACL
    +關(guān)注

    關(guān)注

    0

    文章

    61

    瀏覽量

    11986
  • 網(wǎng)絡(luò)帶寬
    +關(guān)注

    關(guān)注

    0

    文章

    40

    瀏覽量

    8318
  • sort
    +關(guān)注

    關(guān)注

    0

    文章

    5

    瀏覽量

    2624

原文標(biāo)題:一文理解 Redis 的核心原理與技術(shù)

文章出處:【微信號(hào):DBDevs,微信公眾號(hào):數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    華為云Flexus X實(shí)例,Redis性能加速評(píng)測(cè)及對(duì)比

    隨著云計(jì)算技術(shù)的飛速發(fā)展,Redis 作為種高性能的內(nèi)存數(shù)據(jù)庫(kù),在各種應(yīng)用場(chǎng)景中發(fā)揮著越來(lái)越重要的作用。為了滿足不同用戶對(duì) Redis 性能的高要求,華為云推出了 Flexus X
    的頭像 發(fā)表于 12-29 15:47 ?169次閱讀
    華為云Flexus X實(shí)例,<b class='flag-5'>Redis</b>性能加速評(píng)測(cè)及對(duì)比

    華為云 Flexus X 輕松實(shí)現(xiàn) Redis 主多從高效部署

    前言 ????????華為云 Flexus?X 是款專為高性能計(jì)算設(shè)計(jì)的云服務(wù)器實(shí)例,其搭載的 X-Turbo 加速技術(shù)和智能應(yīng)用調(diào)優(yōu)算法,能夠大幅提升 Redis 的處理能力和響應(yīng)速度。此外
    的頭像 發(fā)表于 12-27 13:45 ?185次閱讀
    華為云 Flexus X 輕松實(shí)現(xiàn) <b class='flag-5'>Redis</b> <b class='flag-5'>一</b>主多從高效部署

    Redis緩存與Memcached的比較

    Redis和Memcached都是廣泛使用的內(nèi)存數(shù)據(jù)存儲(chǔ)系統(tǒng),它們主要用于提高應(yīng)用程序的性能,通過(guò)減少對(duì)數(shù)據(jù)庫(kù)的直接訪問(wèn)來(lái)加速數(shù)據(jù)檢索。以下是對(duì)Redis和Memcached的比較,涵蓋了它們的
    的頭像 發(fā)表于 12-18 09:33 ?165次閱讀

    文理解多模態(tài)大語(yǔ)言模型——下

    /understanding-multimodal-llms ? 《文理解多模態(tài)大語(yǔ)言模型 - 上》介紹了什么是多模態(tài)大語(yǔ)言模型,以及構(gòu)建多模態(tài) LLM 有兩種主要方式之:統(tǒng)嵌入
    的頭像 發(fā)表于 12-03 15:18 ?143次閱讀
    <b class='flag-5'>一</b><b class='flag-5'>文理解</b>多模態(tài)大語(yǔ)言模型——下

    文理解多模態(tài)大語(yǔ)言模型——上

    利于中文讀者理解的目標(biāo),做了刪減、重構(gòu)和意譯,并替換了多張不適合中文讀者的示意圖。 原文地址:https://magazine.sebastianraschka.com/p
    的頭像 發(fā)表于 12-02 18:29 ?348次閱讀
    <b class='flag-5'>一</b><b class='flag-5'>文理解</b>多模態(tài)大語(yǔ)言模型——上

    文理解2.5D和3D封裝技術(shù)

    隨著半導(dǎo)體行業(yè)的快速發(fā)展,先進(jìn)封裝技術(shù)成為了提升芯片性能和功能密度的關(guān)鍵。近年來(lái),作為2.5D和3D封裝技術(shù)之間的種結(jié)合方案,3.5D封裝技術(shù)逐漸走向前臺(tái)。
    的頭像 發(fā)表于 11-11 11:21 ?1291次閱讀
    <b class='flag-5'>一</b><b class='flag-5'>文理解</b>2.5D和3D封裝<b class='flag-5'>技術(shù)</b>

    家人工智能企業(yè)成功IPO,核心技術(shù)涉及感知、理解、執(zhí)行

    流程。主要服務(wù)于城市管理及行政、汽車及交通、通信、金融以及教育、醫(yī)療健康、電商及零售等行業(yè)。 ? 核心技術(shù)涉及感知、理解、執(zhí)行 ????????????????????????????????? 聲通科技核心技術(shù)包括交互式人工智
    的頭像 發(fā)表于 07-17 00:16 ?3104次閱讀

    Redis 開源協(xié)議調(diào)整,我們?cè)趺崔k?

    許可,時(shí)間點(diǎn)恰逢剛剛完成最新輪融資,宣布的時(shí)機(jī)耐人尋味。 Redis 協(xié)議調(diào)整,對(duì)云計(jì)算廠商的影響 Redis 協(xié)議調(diào)整聽(tīng)起來(lái)可能沒(méi)什么,但在開源項(xiàng)目領(lǐng)域是個(gè)大問(wèn)題。這并不是
    的頭像 發(fā)表于 05-09 22:59 ?446次閱讀
    <b class='flag-5'>Redis</b> 開源協(xié)議調(diào)整,我們?cè)趺崔k?

    Redis開源版與Redis企業(yè)版,怎么選用?

    Redis開源版,二者有何不同?該如何選擇?Redis企業(yè)版Redis企業(yè)版基于開源Redis構(gòu)建,企業(yè)版將開發(fā)人員、架構(gòu)師和DevO
    的頭像 發(fā)表于 04-04 08:04 ?1101次閱讀
    <b class='flag-5'>Redis</b>開源版與<b class='flag-5'>Redis</b>企業(yè)版,怎么選用?

    數(shù)據(jù)安全沒(méi)保障?GaussDB(for Redis) 為你保駕護(hù)航

    未知的 key,實(shí)際上可能面臨數(shù)據(jù)庫(kù)信息丟失和記錄篡改的風(fēng)險(xiǎn)。 作為個(gè)重視技術(shù)的團(tuán)隊(duì),我們始終將用戶信息安全和使用體驗(yàn)放在第位。對(duì)于這次用戶使用開源 Redis 遇到的問(wèn)題,我們盤
    的頭像 發(fā)表于 03-28 22:09 ?686次閱讀
    數(shù)據(jù)安全沒(méi)保障?GaussDB(for <b class='flag-5'>Redis</b>) 為你保駕護(hù)航

    新版 Redis 不再“開源”,對(duì)使用者都有哪些影響?

    2024 年 3 月 20 日,Redis Labs 宣布從 Redis 7.4 開始,將原先比較寬松的 BSD 源碼使用協(xié)議修改為 RSAv2和 SSPLv1協(xié)議。該變化意味著 Redis
    的頭像 發(fā)表于 03-27 22:30 ?507次閱讀
    新版 <b class='flag-5'>Redis</b> 不再“開源”,對(duì)使用者都有哪些影響?

    Redis官方搜索引擎來(lái)了,性能炸裂!

    RediSearch 是個(gè) Redis 模塊,為 Redis 提供查詢、二級(jí)索引和全文搜索功能。
    的頭像 發(fā)表于 02-21 10:01 ?2407次閱讀
    <b class='flag-5'>Redis</b>官方搜索引擎來(lái)了,性能炸裂!

    MongoDB和Redis技術(shù)特性

    Redis作為個(gè)高性能的內(nèi)存數(shù)據(jù)存儲(chǔ)系統(tǒng),能夠提供快速的緩存機(jī)制,從而幫助應(yīng)用承受高并發(fā)請(qǐng)求,顯著提高系統(tǒng)響應(yīng)速度和吞吐量。這與國(guó)內(nèi)互聯(lián)網(wǎng)公司推崇的快速迭代和高用戶并發(fā)量的特點(diǎn)非常契合。
    的頭像 發(fā)表于 02-01 11:42 ?514次閱讀
    MongoDB和<b class='flag-5'>Redis</b>的<b class='flag-5'>技術(shù)</b>特性

    Redis為L(zhǎng)angChain定制AI代理——OpenGPTs

    于構(gòu)建定制化的人工智能代理。因?yàn)?b class='flag-5'>Redis具有高速和穩(wěn)定性的優(yōu)點(diǎn),所以LangChain選擇了Redis來(lái)作為OpenGPTs的默認(rèn)向量數(shù)據(jù)庫(kù)。
    的頭像 發(fā)表于 01-13 08:03 ?852次閱讀
    用<b class='flag-5'>Redis</b>為L(zhǎng)angChain定制AI代理——OpenGPTs

    分鐘,自動(dòng)完成Redis數(shù)據(jù)遷移

    NineData提供了高效、安全的Redis不停機(jī)數(shù)據(jù)遷移方案。與傳統(tǒng)遷移方案相比,NineData具備簡(jiǎn)單易用、強(qiáng)勁性能和高可靠性的優(yōu)勢(shì)。通過(guò)優(yōu)化核心技術(shù),NineData的遷移性能達(dá)到了16萬(wàn)個(gè)
    的頭像 發(fā)表于 01-08 11:34 ?437次閱讀
    <b class='flag-5'>一</b>分鐘,自動(dòng)完成<b class='flag-5'>Redis</b>數(shù)據(jù)遷移
    主站蜘蛛池模板: 亚a在线| 在线国产高清| 日本黄色短片| 5060午夜一级| 淫欲网| h网站亚洲| 一区二区三区四区国产精品| 一区二区三区伦理| 四虎中文| 美女张开大腿让男人桶| 四虎在线永久视频观看| 天天噜噜色| 在线天堂中文官网| 婷婷在线影院| 亚洲九色| 中文字幕卡二和卡三的视频| 性感美女福利视频| 精品精品国产自在久久高清| 亚洲男人的天堂成人| 伊人久久大香线蕉综合高清| 亚洲最新在线| 亚洲第一色视频| 色91在线| 你懂的国产| 日本a级在线| 黄色大片视频| 韩国三级理论在线看中文字幕| 国产成人教育视频在线观看| 国产精品一级毛片不收费| 国产香港日本三级在线观看| brazzersvideosex欧美高清| 国产女人视频免费观看| 国模绪| 天天免费视频| 爱操综合| 2018天天夜夜| 视频在线免费观看| 国产亚洲第一| 琪琪see色原网一区二区| 国产精品青草久久| 日干夜操|