243_Redis_事務(wù)_內(nèi)存回收_分配算法

Redis事務(wù)

Redis事務(wù)概念

Redis 事務(wù)的本質(zhì)是一組命令的集合。事務(wù)支持一次執(zhí)行多個(gè)命令，一個(gè)事務(wù)中所有命令都會(huì)被序列化。在事務(wù)執(zhí)行過(guò)程，會(huì)按照順序串行化執(zhí)行隊(duì)列中的命令，其他客戶端提交的命令請(qǐng)求不會(huì)插入到事務(wù)執(zhí)行命令序列中

綜述redis事務(wù)就是一次性、順序性、排他性的執(zhí)行一個(gè)隊(duì)列中的一系列命令。

Redis事務(wù)沒(méi)有隔離級(jí)別的概念

批量操作在發(fā)送 EXEC 命令前被放入隊(duì)列緩存，并不會(huì)被實(shí)際執(zhí)行！

Redis不保證原子性

Redis中，單條命令是原子性執(zhí)行的，但事務(wù)不保證原子性，且沒(méi)有回滾。事務(wù)中任意命令執(zhí)行失敗，其余的命令仍會(huì)被執(zhí)行

Redis事務(wù)的三個(gè)階段

開(kāi)始事務(wù) Multi

命令入隊(duì)? 具體命令

執(zhí)行事務(wù)? exec/discard

Redis事務(wù)相關(guān)命令

從輸入Multi命令開(kāi)始，輸入的命令都會(huì)依次進(jìn)入命令隊(duì)列中，但不會(huì)執(zhí)行，直到輸入Exec后，Redis會(huì)將之前的命令隊(duì)列中的命令依次執(zhí)行

組隊(duì)的過(guò)程中可以通過(guò)discard來(lái)放棄組隊(duì)

組隊(duì)中某個(gè)命令出現(xiàn)了報(bào)告錯(cuò)誤，執(zhí)行時(shí)整個(gè)的所有隊(duì)列都會(huì)被取消

如果執(zhí)行階段某個(gè)命令報(bào)出了錯(cuò)誤，則只有報(bào)錯(cuò)的命令不會(huì)被執(zhí)行，而其他的命令都會(huì)執(zhí)行，不會(huì)回滾

watch key1 key2 ... #監(jiān)視一或多個(gè)key,如果在事務(wù)執(zhí)行之前，被監(jiān)視的key被其他命令改動(dòng)，則事務(wù)被打斷(類似樂(lè)觀鎖) multi # 標(biāo)記一個(gè)事務(wù)塊的開(kāi)始（ queued ） exec # 執(zhí)行所有事務(wù)塊的命令 （ 一旦執(zhí)行exec后，之前加的監(jiān)控鎖都會(huì)被取消掉 ） discard # 取消事務(wù)，放棄事務(wù)塊中的所有命令 unwatch # 取消watch對(duì)所有key的監(jiān)控

127.0.0.1:6379> MULTI OK 127.0.0.1:6379> set user bob QUEUED 127.0.0.1:6379> incr user QUEUED 127.0.0.1:6379> set user2 alex QUEUED 127.0.0.1:6379> exec / discard #exec后才真正執(zhí)行 1) OK 2) (error) ERR value is not an integer or out of range 3) OK 127.0.0.1:6379> get user2 "alex"

Watch 監(jiān)控

悲觀鎖：

悲觀鎖(Pessimistic Lock)， 每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人會(huì)修改，所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖，這樣別人想拿到這個(gè)數(shù)據(jù)就會(huì)block直到它拿到鎖。 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)里面就用到了很多這種鎖機(jī)制，比如行鎖，表鎖等，讀鎖，寫(xiě)鎖等，都是在操作之前先上鎖

樂(lè)觀鎖

樂(lè)觀鎖(Optimistic Lock) 每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改，所以不會(huì)上鎖 但是在更新的時(shí)候會(huì)判斷一下再此期間別人有沒(méi)有去更新這個(gè)數(shù)據(jù)，可以使用版本號(hào)等機(jī)制， 樂(lè)觀鎖適用于多讀的應(yīng)用類型，這樣可以提高吞吐量， 樂(lè)觀鎖策略：提交版本必須大于記錄當(dāng)前版本才能執(zhí)行更新

Watch 本質(zhì)是樂(lè)觀鎖, 但是watch可以用來(lái)解決并發(fā)修改的方法

會(huì)在事務(wù)開(kāi)始之前 頂住 一個(gè)或多個(gè)變量,

當(dāng)事務(wù)執(zhí)行時(shí)(服務(wù)收到exec) 就要順序執(zhí)行指令，

Redis檢查頂住的變量,如果該變量被修改, exec會(huì)返回null 告訴客戶端執(zhí)行失敗

內(nèi)存回收機(jī)制

Redis不會(huì)立即回收內(nèi)存給操作系統(tǒng)，操作系統(tǒng)是以頁(yè)為單位回收內(nèi)存的, 只要這個(gè)頁(yè)上還有一個(gè)key 這個(gè)頁(yè)就不能回收, 所以無(wú)法立即回收內(nèi)存頁(yè), 但會(huì)重新使用這些尚未回收的空閑內(nèi)存

內(nèi)存分配算法

Redis使用jemalloc （facebook）庫(kù)來(lái)管理內(nèi)存, 可以切換tcmalloc（Google）庫(kù)

通過(guò)info memory 查看內(nèi)存情況

127.0.0.1:6379> info memory # Memory used_memory:725896 used_memory_human:708.88K used_memory_rss:684880 used_memory_rss_human:668.83K used_memory_peak:743832 used_memory_peak_human:726.40K used_memory_peak_perc:97.59% used_memory_overhead:711694 used_memory_startup:660224 used_memory_dataset:14202 used_memory_dataset_perc:21.63% allocator_allocated:1043496 allocator_active:327155712 allocator_resident:339738624 total_system_memory:0 total_system_memory_human:0B used_memory_lua:37888 used_memory_lua_human:37.00K used_memory_scripts:0 used_memory_scripts_human:0B number_of_cached_scripts:0 maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction allocator_frag_ratio:313.52 allocator_frag_bytes:326112216 allocator_rss_ratio:1.04 allocator_rss_bytes:12582912 rss_overhead_ratio:0.00 rss_overhead_bytes:-339053744 mem_fragmentation_ratio:1.00 mem_fragmentation_bytes:0 mem_not_counted_for_evict:112 mem_replication_backlog:0 mem_clients_slaves:0 mem_clients_normal:49950 mem_aof_buffer:112 mem_allocator:jemalloc-5.2.1-redis active_defrag_running:0 lazyfree_pending_objects:0

指標(biāo)

含義

used_memory

由 Redis 分配器分配的內(nèi)存總量，包含了redis進(jìn)程內(nèi)部的開(kāi)銷和數(shù)據(jù)占用的內(nèi)存，以字節(jié)（byte）為單位，即當(dāng)前redis使用內(nèi)存大小。

used_memory_human

已更直觀的單位展示分配的內(nèi)存總量。

used_memory_rss

向操作系統(tǒng)申請(qǐng)的內(nèi)存大小，與 top 、 ps等命令的輸出一致，即redis使用的物理內(nèi)存大小。

used_memory_rss_human

已更直觀的單位展示向操作系統(tǒng)申請(qǐng)的內(nèi)存大小。

used_memory_peak

redis的內(nèi)存消耗峰值(以字節(jié)為單位)，即歷史使用記錄中redis使用內(nèi)存峰值。

used_memory_peak_human

以更直觀的格式返回redis的內(nèi)存消耗峰值

used_memory_peak_perc

使用內(nèi)存達(dá)到峰值內(nèi)存的百分比，used_memory/ used_memory_peak) *100%，即當(dāng)前redis使用內(nèi)存/歷史使用記錄中redis使用內(nèi)存峰值*100%

used_memory_overhead

Redis為了維護(hù)數(shù)據(jù)集的內(nèi)部機(jī)制所需的內(nèi)存開(kāi)銷，包括所有客戶端輸出緩沖區(qū)、查詢緩沖區(qū)、AOF重寫(xiě)緩沖區(qū)和主從復(fù)制的backlog。

used_memory_startup

Redis服務(wù)器啟動(dòng)時(shí)消耗的內(nèi)存

used_memory_dataset

數(shù)據(jù)實(shí)際占用的內(nèi)存大小，即used_memory-used_memory_overhead

used_memory_dataset_perc

數(shù)據(jù)占用的內(nèi)存大小的百分比，100%*(used_memory_dataset/(used_memory-used_memory_startup))

total_system_memory

整個(gè)系統(tǒng)內(nèi)存

total_system_memory_human

以更直觀的格式顯示整個(gè)系統(tǒng)內(nèi)存

used_memory_lua

Lua腳本存儲(chǔ)占用的內(nèi)存

used_memory_lua_human

以更直觀的格式顯示Lua腳本存儲(chǔ)占用的內(nèi)存

maxmemory

Redis實(shí)例的最大內(nèi)存配置

maxmemory_human

以更直觀的格式顯示Redis實(shí)例的最大內(nèi)存配置

maxmemory_policy

當(dāng)達(dá)到maxmemory時(shí)的淘汰策略

mem_fragmentation_ratio

碎片率，used_memory_rss/ used_memory。ratio指數(shù)>1表明有內(nèi)存碎片，越大表明越多，<1表明正在使用虛擬內(nèi)存，虛擬內(nèi)存其實(shí)就是硬盤(pán)，性能比內(nèi)存低得多，這是應(yīng)該增強(qiáng)機(jī)器的內(nèi)存以提高性能。一般來(lái)說(shuō)，mem_fragmentation_ratio的數(shù)值在1 ~ 1.5之間是比較健康的。詳解

mem_allocator

內(nèi)存分配器

active_defrag_running

表示沒(méi)有活動(dòng)的defrag任務(wù)正在運(yùn)行，1表示有活動(dòng)的defrag任務(wù)正在運(yùn)行（defrag:表示內(nèi)存碎片整理）詳解

lazyfree_pending_objects

0表示不存在延遲釋放的掛起對(duì)象

Redis

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。