Redis RDB-Persistenz ziemlich langsam

Meine zwei Knoten in einem Redis-Cluster haben eine unterschiedliche Persistenzleistung. Der Master-Knoten ist beim Speichern von Daten auf der Festplatte immer viel schneller als der Slave-Knoten. Hier ist die Persistenzinfo für Meister ：

[fred@redis_master temp]$ redis-cli -h 192.168.1.151 -p 8382 192.168.1.151:8382> info persistence # Persistence loading:0 rdb_changes_since_last_save:1206 rdb_bgsave_in_progress:0 rdb_last_save_time:1529636130 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:28 rdb_current_bgsave_time_sec:-1 aof_enabled:0 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:-1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_last_write_status:ok 192.168.1.151:8382> 

Und unten ist die Info für den Sklaven:

[fred@redis_slave temp]$ redis-cli -h 192.168.2.151 -p 8381 192.168.2.151:8381> info persistence # Persistence loading:0 rdb_changes_since_last_save:4850 rdb_bgsave_in_progress:0 rdb_last_save_time:1529635749 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:50 rdb_current_bgsave_time_sec:-1 aof_enabled:0 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:-1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_last_write_status:ok 192.168.2.151:8381> 

Es ist ersichtlich, dass der Master 28 Sekunden für "rdb_last_bgsave_time_sec" ausgegeben hat, während der Slave 50s verbrachte, was den Slave-Knoten wirklich verlangsamt hat. Ich vermute, dass dies höchstwahrscheinlich etwas mit der Leistung der Festplatte zu tun hat. Deshalb habe ich die folgenden Tests durchgeführt:

[fred@redis_master temp]$ time dd if=/dev/zero of=test.dbf bs=8k count=5000 oflag=direct 5000+0 records in 5000+0 records out 40960000 bytes (41 MB) copied, 0.329285 s, 124 MB/s  real 0m0.331s user 0m0.006s sys 0m0.119s  [fred@redis_slave temp]$ time dd if=/dev/zero of=test.dbf bs=8k count=5000 oflag=direct 5000+0 records in 5000+0 records out 40960000 bytes (41 MB) copied, 88.126 s, 465 kB/s  real 1m28.127s user 0m0.008s sys 0m0.210s 

Anscheinend hat der Slave deutlich mehr Zeit als der Master aufgewendet, um nur eine 41-MB-Datei zu erstellen. Kann ich einfach schließen, dass die langsame Persistenz des Slave-Knotens vollständig auf die schlechte Festplatte zurückzuführen ist? Gibt es eine andere effektivere Möglichkeit, dieses Problem der Persistenz zu beheben?

Ich werde es schätzen, wenn jemand helfen kann.