安裝 redis 主從模式：
編寫配置文件：
安裝：
查看密碼：
連接 master：
連接 slave：
讀寫分離：
讀寫：
只讀：
錯誤 1：
解決：
參考： /helm/charts/issues/10666
參考： /kubernetes/infrastructure/redis/administration/kernel-settings/
參考： /helm/charts/tree/master/stable/redis/#user-content-host-kernel-settings
註意：Kubernetes 1.12+ 可以使用 securityContext.sysctls 來設置 pod 的 sysctl，而不需要 initContainer 了：
錯誤 2：
解決：
使用 initContainer 去修改 sysctl 的方案在生產環境正常，這裏卻報錯了，應該是 securityContext 或 PSP 的問題，這裏沒有啟用 PSP，那就剩下 securityContext 了：
我這裏嘗試寫入如下權限，最終都被修改掉了：
這裏暫時沒有找到解決方案，但是發現雖然報錯了，下面 sysctl 修改是生效了的，因為日誌不再報錯了
錯誤 3：
解決：
因為 bitnami/minideb:buster 鏡像裏沒有 sysctl
方法壹：替換鏡像
方法二：直接安裝包，但是這個比較慢
錯誤 4：
解決：
參考： /docker-library/redis/issues/55
參考： /prometheus/node_exporter/issues/703
註意：它將修改調度了容器的節點的內核設置，從而影響該節點上運行的其他容器。這就是為什麽您需要運行特權的 initContainer 或設置 securityContext.sysctls 的原因。
錯誤 5：
解決：
因為將宿主機的 /sys 掛載到容器內的路徑變成了 /host-sys
所以要修改路徑：
錯誤 6：
解決：
這裏暫時看不受影響
錯誤 7：
解決：
因為 master 掛掉了
錯誤 8：
解決：
Redis 提供兩種相對有效的備份方法：
利用 RDB 快照的持久化方式不是非常可靠，當運行 Redis 的計算機停止工作、意外掉電、意外殺掉了 Redis 進程那麽最近寫入 Redis 的數據將會丟。對於某些應用這或許不成問題，但對於持久化要求非常高的應用場景快照方式不是理想的選擇。
利用 AOF 文件是壹個替代方案，用以最大限度的持久化數據。同樣，可以通過配置文件來開閉 AOF。
打開 AOF 持久化功能後，Redis 處理完每個事件後會調用 write(2) 將變化寫入 kernel 的 buffer，如果此時 write(2) 被阻塞，Redis 就不能處理下壹個事件。
Linux 規定執行 write(2) 時，如果對同壹個文件正在執行 fdatasync(2) 將 kernel buffer 寫入物理磁盤，或者有 system wide sync 在執行，write(2) 會被 Block 住，整個 Redis 被 Block 住。
如果系統 IO 繁忙，比如有別的應用在寫盤，或者 Redis 自己在 AOF rewrite 或 RDB snapshot(雖然此時寫入的是另壹個臨時文件，雖然各自都在連續寫，但兩個文件間的切換使得磁盤磁頭的尋道時間加長），就可能導致 fdatasync(2) 遲遲未能完成從而 Block 住 write(2)，Block 住整個 Redis。
為了更清晰的看到 fdatasync(2) 的執行時長，可以使用下面命令跟蹤，但會影響系統性能：
Redis 提供了壹個自救的方式，當發現文件有在執行 fdatasync(2) 時，就先不調用 write(2)，只存在 cache 裏，免得被 Block。但如果已經超過兩秒都還是這個樣子，則會硬著頭皮執行 write(2)，即使 redis 會被 Block 住。
此時那句要命的 log 會打印：Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
之後用 redis-cli INFO 可以看到 aof_delayed_fsync 的值被加 1。
因此，對於 fsync 設為 everysec 時丟失數據的可能性的最嚴謹說法是：
如果有 fdatasync 在長時間的執行，此時 redis 意外關閉會造成文件裏不多於兩秒的數據丟失。
如果 fdatasync 運行正常，redis 意外關閉沒有影響，只有當操作系統 crash 時才會造成少於 1 秒的數據丟失。
方法壹：關閉 AOF
如果采用 redis 主從 + sentinel 方式的話，主節點掛了從節點會自己提升為主點，主節點恢復後全量同步壹次數據就可以了，關系也不是太大
方法二：修改系統配置
原來是 AOF rewrite 時壹直埋頭的調用 write(2)，由系統自己去觸發 sync。默認配置 vm.dirty_background_ratio=10，也就是占用了 10% 的可用內存才會開始後臺 flush
而我的服務器有 8G 內存，很明顯壹次 flush 太多數據會造成阻塞，所以最後果斷設置了sysctl vm.dirty_bytes=33554432(32M) 問題解決
錯誤 9：
解決：
看著是啟動的時候加載 AOF 文件到內存，然後被 liveness 殺掉了
隨著命令不斷寫入 AOF，文件會越來越大，為了解決這個問題，redis 引入了 AOF 重寫機制壓縮文件。文件能縮小的原因是：
AOF 重寫可以手動觸發和自動觸發：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 16mb
所以這裏處理下，控制 AOF 文件大小：
註意：這裏依舊沒能解決問題，文件依舊很大，而且會造成大量的磁盤 IO，最終導致 redis 失去響應
徹底解決：
之後 dump.rdb 文件壹直穩定在 255M