Redis持久化方案詳解
Redis的資料回寫機制
Redis的資料回寫機制分同步和非同步兩種,
- 同步回寫即SAVE命令,主程序直接向磁盤迴寫資料。在資料大的情況下會導致系統假死很長時間,所以一般不是推薦的。
- 非同步回寫即BGSAVE命令,主程序fork後,複製自身並通過這個新的程序回寫磁碟,回寫結束後新程序自行關閉。由於這樣做不需要主程序阻塞,系統不會假死,一般預設會採用這個方法。
個人感覺方法2採用fork主程序的方式很拙劣,但似乎是唯一的方法。記憶體中的熱資料隨時可能修改,要在磁碟上儲存某個時間的記憶體映象必須要凍結。凍結就會導致假死。 fork一個新的程序之後等於複製了當時的一個記憶體映象,這樣主程序上就不需要凍結,只要子程序上操作就可以了。
在小記憶體的程序上做一個fork,不需要太多資源,但當這個程序的記憶體空間以G為單位時,fork就成為一件很恐怖的操作。何況在16G記憶體的主機上fork 14G記憶體的程序呢?肯定會報記憶體無法分配的。更可氣的是,越是改動頻繁的主機上fork也越頻繁,fork操作本身的代價恐怕也不會比假死好多少。
找到原因之後,直接修改/etc/sysctl.conf核心引數vm.overcommit_memory= 1
sysctl -p
Linux核心會根據引數vm.overcommit_memory引數的設定決定是否放行。
- 如果 vm.overcommit_memory = 1,直接放行
- vm.overcommit_memory = 0:則比較 此次請求分配的虛擬記憶體大小和系統當前空閒的實體記憶體加上swap,決定是否放行。
- vm.overcommit_memory= 2:則會比較程序所有已分配的虛擬記憶體加上此次請求分配的虛擬記憶體和系統當前的空閒實體記憶體加上swap,決定是否放行。
Redis持久化實踐及災難恢復模擬
參考資料:
Redis Persistence http://redis.io/topics/persistence
Google Groups https://groups.google.com/forum/?fromgroups=#!forum/redis-db
一、對Redis持久化的探討與理解
目前Redis持久化的方式有兩種: RDB 和 AOF
首先,我們應該明確持久化的資料有什麼用,答案是用於重啟後的資料恢復。
Redis是一個記憶體資料庫,無論是RDB還是AOF,都只是其保證資料恢復的措施。
所以Redis在利用RDB和AOF進行恢復的時候,都會讀取RDB或AOF檔案,重新載入到記憶體中。
RDB就是Snapshot快照儲存,是預設的持久化方式。
可理解為半持久化模式,即按照一定的策略週期性的將資料儲存到磁碟。
對應產生的資料檔案為dump.rdb,通過配置檔案中的save引數來定義快照的週期。
下面是預設的快照設定:
save 900 1 #當有一條Keys資料被改變時,900秒重新整理到Disk一次 save 300 10 #當有10條Keys資料被改變時,300秒重新整理到Disk一次 save 60 10000 #當有10000條Keys資料被改變時,60秒重新整理到Disk一次
Redis的RDB檔案不會壞掉,因為其寫操作是在一個新程序中進行的。
當生成一個新的RDB檔案時,Redis生成的子程序會先將資料寫到一個臨時檔案中,然後通過原子性rename系統呼叫將臨時檔案重新命名為RDB檔案。
這樣在任何時候出現故障,Redis的RDB檔案都總是可用的。
同時,Redis的RDB檔案也是Redis主從同步內部實現中的一環。
第一次Slave向Master同步的實現是:
Slave向Master發出同步請求,Master先dump出rdb檔案,然後將rdb檔案全量傳輸給slave,然後Master把快取的命令轉發給Slave,初次同步完成。
第二次以及以後的同步實現是:
Master將變數的快照直接實時依次傳送給各個Slave。
但不管什麼原因導致Slave和Master斷開重連都會重複以上兩個步驟的過程。
Redis的主從複製是建立在記憶體快照的持久化基礎上的,只要有Slave就一定會有記憶體快照發生。
可以很明顯的看到,RDB有它的不足,就是一旦資料庫出現問題,那麼我們的RDB檔案中儲存的資料並不是全新的。
從上次RDB檔案生成到Redis停機這段時間的資料全部丟掉了。
AOF(Append-Only File)比RDB方式有更好的持久化性。
由於在使用AOF持久化方式時,Redis會將每一個收到的寫命令都通過Write函式追加到檔案中,類似於MySQL的binlog。
當Redis重啟是會通過重新執行檔案中儲存的寫命令來在記憶體中重建整個資料庫的內容。
對應的設定引數為:
$ vim /opt/redis/etc/redis_6379.conf
appendonly yes #啟用AOF持久化方式 appendfilename appendonly.aof #AOF檔案的名稱,預設為appendonly.aof # appendfsync always #每次收到寫命令就立即強制寫入磁碟,是最有保證的完全的持久化,但速度也是最慢的,一般不推薦使用。 appendfsync everysec #每秒鐘強制寫入磁碟一次,在效能和持久化方面做了很好的折中,是受推薦的方式。 # appendfsync no #完全依賴OS的寫入,一般為30秒左右一次,效能最好但是持久化最沒有保證,不被推薦。
AOF的完全持久化方式同時也帶來了另一個問題,持久化檔案會變得越來越大。
比如我們呼叫INCR test命令100次,檔案中就必須儲存全部的100條命令,但其實99條都是多餘的。
因為要恢復資料庫的狀態其實檔案中儲存一條SET test 100就夠了。
為了壓縮AOF的持久化檔案,Redis提供了bgrewriteaof命令。
收到此命令後Redis將使用與快照類似的方式將記憶體中的資料以命令的方式儲存到臨時檔案中,最後替換原來的檔案,以此來實現控制AOF檔案的增長。
由於是模擬快照的過程,因此在重寫AOF檔案時並沒有讀取舊的AOF檔案,而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的AOF檔案。
對應的設定引數為:
$ vim /opt/redis/etc/redis_6379.conf
no-appendfsync-on-rewrite yes #在日誌重寫時,不進行命令追加操作,而只是將其放在緩衝區裡,避免與命令的追加造成DISK IO上的衝突。 auto-aof-rewrite-percentage 100 #當前AOF檔案大小是上次日誌重寫得到AOF檔案大小的二倍時,自動啟動新的日誌重寫過程。 auto-aof-rewrite-min-size 64mb #當前AOF檔案啟動新的日誌重寫過程的最小值,避免剛剛啟動Reids時由於檔案尺寸較小導致頻繁的重寫。
到底選擇什麼呢?下面是來自官方的建議:
通常,如果你要想提供很高的資料保障性,那麼建議你同時使用兩種持久化方式。
如果你可以接受災難帶來的幾分鐘的資料丟失,那麼你可以僅使用RDB。
很多使用者僅使用了AOF,但是我們建議,既然RDB可以時不時的給資料做個完整的快照,並且提供更快的重啟,所以最好還是也使用RDB。
因此,我們希望可以在未來(長遠計劃)統一AOF和RDB成一種持久化模式。
在資料恢復方面:
RDB的啟動時間會更短,原因有兩個:
一是RDB檔案中每一條資料只有一條記錄,不會像AOF日誌那樣可能有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了。
另一個原因是RDB檔案的儲存格式和Redis資料在記憶體中的編碼格式是一致的,不需要再進行資料編碼工作,所以在CPU消耗上要遠小於AOF日誌的載入。
二、災難恢復模擬
既然持久化的資料的作用是用於重啟後的資料恢復,那麼我們就非常有必要進行一次這樣的災難恢復模擬了。
據稱如果資料要做持久化又想保證穩定性,則建議留空一半的實體記憶體。因為在進行快照的時候,fork出來進行dump操作的子程序會佔用與父程序一樣的記憶體,真正的copy-on-write,對效能的影響和記憶體的耗用都是比較大的。
目前,通常的設計思路是利用Replication機制來彌補aof、snapshot效能上的不足,達到了資料可持久化。
即Master上Snapshot和AOF都不做,來保證Master的讀寫效能,而Slave上則同時開啟Snapshot和AOF來進行持久化,保證資料的安全性。
首先,修改Master上的如下配置:
$ sudo vim /opt/redis/etc/redis_6379.conf
#save 900 1 #禁用Snapshot #save 300 10 #save 60 10000 appendonly no #禁用AOF
接著,修改Slave上的如下配置:
$ sudo vim /opt/redis/etc/redis_6379.conf
save 900 1 #啟用Snapshot save 300 10 save 60 10000 appendonly yes #啟用AOF appendfilename appendonly.aof #AOF檔案的名稱 # appendfsync always appendfsync everysec #每秒鐘強制寫入磁碟一次 # appendfsync no no-appendfsync-on-rewrite yes #在日誌重寫時,不進行命令追加操作 auto-aof-rewrite-percentage 100 #自動啟動新的日誌重寫過程 auto-aof-rewrite-min-size 64mb #啟動新的日誌重寫過程的最小值
分別啟動Master與Slave
$ /etc/init.d/redis start
啟動完成後在Master中確認未啟動Snapshot引數
redis 127.0.0.1:6379> CONFIG GET save
1) "save"
2) ""
然後通過以下指令碼在Master中生成25萬條資料:
[email protected]:/opt/redis/data/6379$ cat redis-cli-generate.temp.sh
#!/bin/bash REDISCLI="redis-cli -a slavepass -n 1 SET" ID=1 while(($ID<50001)) do INSTANCE_NAME="i-2-$ID-VM" UUID=`cat /proc/sys/kernel/random/uuid` PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`\ CREATED=`date "+%Y-%m-%d %H:%M:%S"` $REDISCLI vm_instance:$ID:instance_name "$INSTANCE_NAME" $REDISCLI vm_instance:$ID:uuid "$UUID" $REDISCLI vm_instance:$ID:private_ip_address "$PRIVATE_IP_ADDRESS" $REDISCLI vm_instance:$ID:created "$CREATED" $REDISCLI vm_instance:$INSTANCE_NAME:id "$ID" ID=$(($ID+1)) done
[email protected]:/opt/redis/data/6379$ ./redis-cli-generate.temp.sh
在資料的生成過程中,可以很清楚的看到Master上僅在第一次做Slave同步時建立了dump.rdb檔案,之後就通過增量傳輸命令的方式給Slave了。
dump.rdb檔案沒有再增大。
[email protected]:/opt/redis/data/6379$ ls -lh
total 4.0K
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb
而Slave上則可以看到dump.rdb檔案和AOF檔案在不斷的增大,並且AOF檔案的增長速度明顯大於dump.rdb檔案。
[email protected]:/opt/redis/data/6379$ ls -lh
total 24M
-rw-r--r-- 1 root root 15M Sep 27 12:06 appendonly.aof
-rw-r--r-- 1 root root 9.2M Sep 27 12:06 dump.rdb
等待資料插入完成以後,首先確認當前的資料量。
redis 127.0.0.1:6379> info
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:27623 run_id:e00757f7b2d6885fa9811540df9dfed39430b642 uptime_in_seconds:1541 uptime_in_days:0 lru_clock:650187 used_cpu_sys:69.28 used_cpu_user:7.67 used_cpu_sys_children:0.00 used_cpu_user_children:0.00 connected_clients:1 connected_slaves:1 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33055824 used_memory_human:31.52M used_memory_rss:34717696 used_memory_peak:33055800 used_memory_peak_human:31.52M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:0 changes_since_last_save:250000 bgsave_in_progress:0 last_save_time:1348677645 bgrewriteaof_in_progress:0 total_connections_received:250007 total_commands_processed:750019 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:246 vm_enabled:0 role:master slave0:10.6.1.144,6379,online db1:keys=250000,expires=0
當前的資料量為25萬條key,佔用記憶體31.52M。
然後我們直接Kill掉Master的Redis程序,模擬災難。
[email protected]:/opt/redis/data/6379$ sudo killall -9 redis-server
我們到Slave中檢視狀態:
redis 127.0.0.1:6379> info
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:13003 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 uptime_in_seconds:1627 uptime_in_days:0 lru_clock:654181 used_cpu_sys:29.69 used_cpu_user:1.21 used_cpu_sys_children:1.70 used_cpu_user_children:1.23 connected_clients:1 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33047696 used_memory_human:31.52M used_memory_rss:34775040 used_memory_peak:33064400 used_memory_peak_human:31.53M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:1 changes_since_last_save:3308 bgsave_in_progress:0 last_save_time:1348718951 bgrewriteaof_in_progress:0 total_connections_received:4 total_commands_processed:250308 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:694 vm_enabled:0 role:slave aof_current_size:17908619 aof_base_size:16787337 aof_pending_rewrite:0 aof_buffer_length:0 aof_pending_bio_fsync:0 master_host:10.6.1.143 master_port:6379 master_link_status:down master_last_io_seconds_ago:-1 master_sync_in_progress:0 master_link_down_since_seconds:25 slave_priority:100 db1:keys=250000,expires=0
可以看到master_link_status的狀態已經是down了,Master已經不可訪問了。
而此時,Slave依然執行良好,並且保留有AOF與RDB檔案。
下面我們將通過Slave上儲存好的AOF與RDB檔案來恢復Master上的資料。
首先,將Slave上的同步狀態取消,避免主庫在未完成資料恢復前就重啟,進而直接覆蓋掉從庫上的資料,導致所有的資料丟失。
redis 127.0.0.1:6379> SLAVEOF NO ONE
OK
確認一下已經沒有了master相關的配置資訊:
redis 127.0.0.1:6379> INFO
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:13003 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 uptime_in_seconds:1961 uptime_in_days:0 lru_clock:654215 used_cpu_sys:29.98 used_cpu_user:1.22 used_cpu_sys_children:1.76 used_cpu_user_children:1.42 connected_clients:1 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33047696 used_memory_human:31.52M used_memory_rss:34779136 used_memory_peak:33064400 used_memory_peak_human:31.53M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:1 changes_since_last_save:0 bgsave_in_progress:0 last_save_time:1348719252 bgrewriteaof_in_progress:0 total_connections_received:4 total_commands_processed:250311 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:1119 vm_enabled:0 role:master aof_current_size:17908619 aof_base_size:16787337 aof_pending_rewrite:0 aof_buffer_length:0 aof_pending_bio_fsync:0 db1:keys=250000,expires=0
在Slave上覆制資料檔案:
[email protected]:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *
appendonly.aof
dump.rdb
將data.tar上傳到Master上,嘗試恢復資料:
可以看到Master目錄下有一個初始化Slave的資料檔案,很小,將其刪除。
[email protected]:/opt/redis/data/6379$ ls -l
total 4
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb
[email protected]:/opt/redis/data/6379$ sudo rm -f dump.rdb
然後解壓縮資料檔案:
[email protected]:/opt/redis/data/6379$ sudo tar xf /home/dongguo/data.tar
[email protected]:/opt/redis/data/6379$ ls -lh
total 29M
-rw-r--r-- 1 root root 18M Sep 27 01:22 appendonly.aof
-rw-r--r-- 1 root root 12M Sep 27 01:22 dump.rdb
啟動Master上的Redis;
[email protected]:/opt/redis/data/6379$ sudo /etc/init.d/redis start
Starting Redis server...
檢視資料是否恢復:
redis 127.0.0.1:6379> INFO
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:16959 run_id:6e5ba6c053583414e75353b283597ea404494926 uptime_in_seconds:22 uptime_in_days:0 lru_clock:650292 used_cpu_sys:0.18 used_cpu_user:0.20 used_cpu_sys_children:0.00 used_cpu_user_children:0.00 connected_clients:1 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33047216 used_memory_human:31.52M used_memory_rss:34623488 used_memory_peak:33047192 used_memory_peak_human:31.52M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:0 changes_since_last_save:0 bgsave_in_progress:0 last_save_time:1348680180 bgrewriteaof_in_progress:0 total_connections_received:1 total_commands_processed:1 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:0 vm_enabled:0 role:master db1:keys=250000,expires=0
可以看到25萬條資料已經完整恢復到了Master上。
此時,可以放心的恢復Slave的同步設定了。
redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379
OK
檢視同步狀態:
redis 127.0.0.1:6379> INFO
redis_version:2.4.17 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.5 process_id:13003 run_id:9b8b398fc63a26d160bf58df90cf437acce1d364 uptime_in_seconds:2652 uptime_in_days:0 lru_clock:654284 used_cpu_sys:30.01 used_cpu_user:2.12 used_cpu_sys_children:1.76 used_cpu_user_children:1.42 connected_clients:2 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:33056288 used_memory_human:31.52M used_memory_rss:34766848 used_memory_peak:33064400 used_memory_peak_human:31.53M mem_fragmentation_ratio:1.05 mem_allocator:jemalloc-3.0.0 loading:0 aof_enabled:1 changes_since_last_save:0 bgsave_in_progress:0 last_save_time:1348719252 bgrewriteaof_in_progress:1 total_connections_received:6 total_commands_processed:250313 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:12217 vm_enabled:0 role:slave aof_current_size:17908619 aof_base_size:16787337 aof_pending_rewrite:0 aof_buffer_length:0 aof_pending_bio_fsync:0 master_host:10.6.1.143 master_port:6379 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 slave_priority:100 db1:keys=250000,expires=0
master_link_status顯示為up,同步狀態正常。
在此次恢復的過程中,我們同時複製了AOF與RDB檔案,那麼到底是哪一個檔案完成了資料的恢復呢?
實際上,當Redis伺服器掛掉時,重啟時將按照以下優先順序恢復資料到記憶體:
1. 如果只配置AOF,重啟時載入AOF檔案恢復資料;
2. 如果同時 配置了RDB和AOF,啟動是隻載入AOF檔案恢復資料;
3. 如果只配置RDB,啟動是將載入dump檔案恢復資料。
也就是說,AOF的優先順序要高於RDB,這也很好理解,因為AOF本身對資料的完整性保障要高於RDB。
在此次的案例中,我們通過在Slave上啟用了AOF與RDB來保障了資料,並恢復了Master。
但在我們目前的線上環境中,由於資料都設定有過期時間,採用AOF的方式會不太實用,過於頻繁的寫操作會使AOF檔案增長到異常的龐大,大大超過了我們實際的資料量,這也會導致在進行資料恢復時耗用大量的時間。
因此,可以在Slave上僅開啟Snapshot來進行本地化,同時可以考慮將save中的頻率調高一些或者呼叫一個計劃任務來進行定期bgsave的快照儲存,來儘可能的保障本地化資料的完整性。
在這樣的架構下,如果僅僅是Master掛掉,Slave完整,資料恢復可達到100%。
如果Master與Slave同時掛掉的話,資料的恢復也可以達到一個可接受的程度。
相關推薦
Redis持久化方案詳解
Redis的資料回寫機制 Redis的資料回寫機制分同步和非同步兩種, 同步回寫即SAVE命令,主程序直接向磁盤迴寫資料。在資料大的情況下會導致系統假死很長時間,所以一般不是推薦的。 非同步回寫即BGSAVE命令,主程序fork後,複製自身並通過這個新的程序回寫磁碟,回寫
redis持久化原理詳解
一、 Redis 提供了不同級別的持久化方式: Redis提供了兩種方式對資料進行持久化,分別是RDB和AOF。 RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存。 AOF持久化方式記錄每次對伺服器寫的操作,當伺服器重啟的時候會重新執行這些命令來恢復原始的資
Redis持久化儲存詳解(一)
開發十年,就只剩下這套架構體系了! >>>
Redis高可用詳解:持久化技術及方案選擇
本文將先說明上述幾種技術分別解決了Redis高可用的什麼問題,然後詳細介紹Redis的持久化技術,主要是RDB和AOF兩種持久化方案。在介紹RDB和AOF方案時,不僅介紹其作用及操作方法,同時還會介紹持久化實現的一些原理細節及需要注意的問題。最後,介紹在實際使用中持久化方案的
Redis高可用詳解:持久化技術及方案選擇 (推薦)--轉載自程式設計迷思部落格www.cnblogs.com/kismetv/p/8654978.html
一、Redis高可用概述 在介紹Redis高可用之前,先說明一下在Redis的語境中高可用的含義。 我們知道,在web伺服器中,高可用是指伺服器可以正常訪問的時間,衡量的標準是在多長時間內可以提供正常服務(99.9%、99.99%、99.999% 等等)。但是在Redis語境中,高可用的含義似乎要寬泛一些,除
Redis 設計與實現之RDB 和 AOF 兩種持久化模式詳解
在執行情況下, Redis 以資料結構的形式將資料維持在記憶體中, 為了讓這些資料在 Redis 重啟之後仍然可用, Redis 分別提供了 RDB 和 AOF 兩種持久化模式。 在 Redis 執行時, RDB 程式將當前記憶體中的資料庫快照儲存到磁碟檔案中, 在 Red
第一行程式碼——第六章:資料儲存全方案——詳解持久化技術
目錄: 6.1 持久化技術簡介 6.2 檔案儲存 6.2.1 將資料儲存到檔案中 6.2.2 從檔案中讀出資料 6.3 SharedPreferences 儲存 6.3.1 將資料儲存到SharedPreferences中 6.3.2 從SharedPreferenc
高併發架構系列:Redis併發競爭key的解決方案詳解
需求由來 1.Redis高併發的問題 Redis快取的高效能有目共睹,應用的場景也是非常廣泛,但是在高併發的場景下,也會出現問題:快取擊穿、快取雪崩、快取和資料一致性,以及今天要談到的快取併發競爭。 這裡的併發指的是多個redis的client同時set key引起的併發問題。
高併發架構系列:Redis快取和MySQL資料一致性方案詳解
一、需求起因 在高併發的業務場景下,資料庫大多數情況都是使用者併發訪問最薄弱的環節。所以,就需要使用redis做一個緩衝操作,讓請求先訪問到redis,而不是直接訪問MySQL等資料庫。 這個業務場景,主要是解決讀資料從Redis快取,一般都是按照下圖的流程來進行業務操作。 讀取快取步驟
第二行程式碼學習筆記——第六章:資料儲存全方案——詳解持久化技術
本章要點 任何一個應用程式,總是不停的和資料打交道。 瞬時資料:指儲存在記憶體當中,有可能因為程式關閉或其他原因導致記憶體被回收而丟失的資料。 資料持久化技術,為了解決關鍵性資料的丟失。 6.1 持久化技術簡介 資料持久化技術:指那些記憶體中的瞬時
資料儲存全方案--詳解持久化技術
持久化技術提供了一種機制可以讓資料在瞬時狀態和持久化狀態之間進行轉換。 Android中的資料持久化技術主要有: 1. 檔案儲存 2. SharedPreference 儲存 3. 資料庫儲存 1 檔案儲存 不會對儲存內容進行任何格式化處理
高並發架構系列:Redis緩存和MySQL數據一致性方案詳解
異步 中產 主從 推送 行業 全量 src 超時 最終 一、需求起因在高並發的業務場景下,數據庫大多數情況都是用戶並發訪問最薄弱的環節。所以,就需要使用redis做一個緩沖操作,讓請求先訪問到redis,而不是直接訪問MySQL等數據庫。這個業務場景,主要是解決讀數據從Re
redis命令monitor詳解
monitor 窗口 inf 做了 命令 linux blog linux中 技術分享 通過monitor這個命令可以查看數據庫在當前做了什麽操作,對於管理redis數據庫有這很大的幫助 如圖示,在redis客戶端進行操作顯示info,另一個窗口打
接口自動化測試方案詳解
system earch ply 找我 發現 safari todo 文件中 timestamp 前言 去年,我們進行了項目的拆分,拆分後的各個子系統也都逐步的改成了通過接口進行數據的交換,接口測試也被提上日程。經過一段時間的探索,接口自動化測試方案越來越完善,今天給大
傳美雲商系統軟件方案詳解
ext mage 系統 做到 function ice 一個 集成 現在 傳美雲商系統是通過頤和果園讓公眾所知道的,頤和果園是做水果生鮮食品市場的,運用傳美雲商這個軟件為什麽能打通互聯網市場?究其主要原因是因新零售正在發生日新月異的變化! 任何新零售都需要數據的支撐。辦公室
Yii2 教程 - yii2-redis 擴展詳解
鍵值 lob hostname var 包括 blog 很多 框架 username 該教程已被合並到《Yii2 權威指南中文版》中!Yiichina 教程地址為《yii2-redis 擴展詳解》! 一、簡介 yii2-redis 擴展為 Yii2 框架提供了 redi
企業級代碼上線方案詳解
代碼上線 代碼備份 軟鏈接 中小型企業代碼上線準則 (1)上線說明****對於重要的升級上線來說先有運維人員備份所有重要數據,然後經過開發人員測試和內部測試成功後直接上傳的站點目錄,出現問題後采用歷史代碼回滾策略。而對普通升級來說,先備份必要數據,然後代碼在開發人員和內外網測試成功後可直接上線。(
前端模塊化開發解決方案詳解
暴露 可見 返回 異步加載 def 今天 htm 硬盤 業務邏輯 一、模塊化開發方案 前端發展到今天,已經有不少模塊化的方案,比如 CommonJS(常用在服務器端,同步的,如nodejs) AMD(常用在瀏覽器端,異步的,如requirejs)(Asynchronous
Redis持久化方案RDB和AOF(理論)
redis持久化 RDB AOF redis和memcache的區別是什麽? 簡單來說,如果沒有持久化的redis,就和memcache一樣了,相當於一個緩存數據庫。redis是如何解決數據持久化的? redis有兩種持久化方案:RDB(Redis DataBases)和AOF(App
電商購物直播app開發解決方案詳解
分享 進入 發的 購物平臺 發出 阿裏巴巴 通過 出了 內嵌 最近有很多小夥伴咨詢電商直播app開發,在傳統的秀場直播競爭力逐漸下降的今天,“直播+”爆發出了無窮的“小宇宙”。在眾多“直播+”解決方案中,“直播+電商”是目前比較完善的解決方案,像阿裏巴巴旗下的淘寶直播,以及