看到有人討論redis與mysql一致性的問題，思考一下。
單主一從或多從，相對單節點來說，優點：
缺點也很明顯：
要做到秒級容災切換，雙主是個很好的選擇，也可以附加多從，做到讀寫分離。但雙主無法迴避的乙個問題是資料的一致性，也就引出了雙主的不同用法。
1.3.1 雙主單寫
其中乙個主節點只做高可用容災備份，不進行寫操作，在另乙個主節點掛掉後，可以快速提供服務，確保系統可用。
1.3.2 雙主雙寫
可解決單主節點的寫瓶頸問題，但易發生資料衝突，可由一些配置來解決部分問題，如配置乙個節點自增單數，乙個節點自增雙數，解決插入資料衝突問題；還可以業務層新增邏輯，做資料路由，單數資料與雙數資料去不同節點去寫等等。需要在效能與複雜性之間做乙個取捨。
kv儲存——資料複雜度不高，記憶體資料庫——讀寫效率高但資料穩定性不高（相對），當然現在redis也支援集群，類似mysql主從，資料穩定性上相對高了不少。適合當快取與mysql配合使用。
包括幾種場景
這種情況處理起來簡單，因為mysql中資料是正常的，不會有併發性問題
未快取需要從mysql中查詢資料，存入redis
快取需要更新
資料業務邏輯上已過期，但redis中還存在，需要從redis中刪除，再從mysql中同步資料
邏輯稍微複雜一點，如果先更新mysql，redis有可能被其他執行緒取走舊資料，所以需要先更新redis再更新mysql，但要考慮mysql更新失敗的情況處理。
redis 高可用切換 Redis高可用使用方法二
redis高可用使用方法一 redis高可用使用方法三 之前是主從模式下,但如果考慮到主從切換時，對於開發者來說需要更換配置檔案，是乙個不明智的選擇 而官方提供了哨兵模式 當然在官方不提供的前提下方式是有多種解決的 dns，四層等 一 哨兵的配置 cd redis 4.0.12 切換到之前解壓的目錄...
Redis的高可用
1.持久化 主要作用是資料備份，將資料儲存在硬碟，保證資料不會因程序退出而丟失 2.複製 哨兵和集群都是在複製的基礎上實現高可用的，複製主要實現了資料的多機備份，以及對於讀操作的負載均衡和簡單的故障恢復 缺陷 故障恢復無法自動化，寫操作無法負載均衡，儲存能力受到單機的限制 3.哨兵 在複製的基礎上，...
Redis高可用架構
官網 解壓 tar zxvf redis 5.0.5.tar.gz 切換目錄 cd redis 3.2.9,執行編譯命令 make 切換到 redis 3.2.9 src 目錄執行命令 vim redis.conf protected mode no bind 127.0.0.1 daemonize...