手動搭建Redis集群和MySQL主從同步(非Docker) · PHP筆記

## 什么是Redis集群[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E4%BB%80%E4%B9%88%E6%98%AFRedis%E9%9B%86%E7%BE%A4) * ### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E7%AE%80%E4%BB%8B "簡介")簡介[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E7%AE%80%E4%BB%8B) Redis是一個快速高效的NoSQL型數據庫，由于其基于內存存儲、單線程、多路IO復用的特性，其QPS可以達到驚人的100000+（官方數據），但是即使有這么高的速度，在中國這么大的網民基數環境下，也存在著性能瓶頸。首先拋開服務器故障不談，Redis集群首先可以使Redis性能得到線性提高，這是毋庸置疑的，其次Redis集群除了解決了效率問題，還可以解決服務器宕機造成的數據丟失問題，當某個Redis節點宕機，剩下的節點會繼續工作，并不會影響整體集群的使用，從而實現**高可用**。 * ### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#Redis%E5%8D%95%E6%9C%BA%E6%A8%A1%E5%BC%8F%E6%9C%89%E4%BB%80%E4%B9%88%E9%97%AE%E9%A2%98 "Redis單機模式有什么問題")Redis單機模式有什么問題[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#Redis%E5%8D%95%E6%9C%BA%E6%A8%A1%E5%BC%8F%E6%9C%89%E4%BB%80%E4%B9%88%E9%97%AE%E9%A2%98) * #### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%8D%95%E6%9C%BA%E6%95%85%E9%9A%9C "單機故障")單機故障[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%8D%95%E6%9C%BA%E6%95%85%E9%9A%9C) 在單機模式下的Redis，我們的應用中所有需要緩存的數據都依賴一臺Redis服務器，應用的流量小可能看不出什么問題，但是隨著應用越來越大，流量越來越大，如果出現服務器宕機或者斷電的狀況，那么我們的應用整個一個緩存層在一段時間內（重啟）都將不復存在，先不談基于Redis的分布式Session可能造成的問題，如果恰好遇上流量高峰，這些流量直接打在數據庫上，我們知道數據庫的IO效率遠不及Redis，這將大大提高應用負載，容易出現數據庫服務器的宕機，從而造成應用的宕機。由此看來，單機版Redis如果出現故障，將有可能引起一系列的連鎖反應，造成不可逆的損失。 * #### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%AE%B9%E9%87%8F%E7%93%B6%E9%A2%88 "容量瓶頸")容量瓶頸[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%AE%B9%E9%87%8F%E7%93%B6%E9%A2%88) 我們知道Redis是基于內存存儲的一個NoSQL數據庫，基于內存也是其**高速高效**的原因之一。雖然容量瓶頸在實際生產中并不常見（通常有意識地將搭載Redis的機器內存容量加高），但是不排除在某些極端條件下Redis會將一臺機器的內存耗盡，造成數據丟失，甚至服務器宕機。 * #### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E6%80%A7%E8%83%BD%E7%93%B6%E9%A2%88 "性能瓶頸")性能瓶頸[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E6%80%A7%E8%83%BD%E7%93%B6%E9%A2%88) 簡介中提到，雖然Redis在官方文檔中提到可以達到約100000+QPS，但是**首先**在日常環境的測試中，我們可能并達不到文檔中宣稱的QPS，換言之，這可能也就是一種理論值，就像是4G的理論網速在10-100Mbps，折合下載速度1.5M/s-10M/s，但在日常生活中我們極少甚至從來沒有達到過這個速度過，一樣的道理。**其次**，在中國巨大的網民基數下，單機Redis滿足日常需求尚且捉襟見肘，如果碰上像雙十一、雙十二、春運這些特殊的環境，單臺Redis顯然會有性能不足的現象發生。 * ### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#Redis%E9%9B%86%E7%BE%A4%E7%9A%84%E4%B8%89%E7%A7%8D%E6%A8%A1%E5%BC%8F "Redis集群的三種模式")Redis集群的三種模式[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#Redis%E9%9B%86%E7%BE%A4%E7%9A%84%E4%B8%89%E7%A7%8D%E6%A8%A1%E5%BC%8F) * #### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E4%B8%BB%E4%BB%8E%E6%A8%A1%E5%BC%8F "主從模式")主從模式[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E4%B8%BB%E4%BB%8E%E6%A8%A1%E5%BC%8F) 主從模式是最簡單的一種Redis集群模式，首先其思想就是一臺Redis服務器作為**主服務器（Master）**，一臺或多臺服務器作為**從服務器（Slave）**。當以此種方式部署集群時，集群有如下特點： 1. Master可以進行讀寫操作，當寫操作導致數據發生變化時，將自動同步給Slave，Slave通常是只讀的，并且接受從Master同步過來的數據。 2. **一臺Master可以有多臺Slave，但每臺Slave只能有一個Master**。 3. 某臺Slave宕機不影響其他Slave和Master的讀寫，重新啟動后會將數據重新從Master同步過來。 4. **Master宕機后不影響Slave的讀，但該集群不再提供對Redis的寫入功能**。 5. Master宕機后不會從Slave中選舉主節點。在此種模式下，我們可以對Redis集群做**容災備份**和**讀寫分離**，但是要注意，容災備份并不能拯救你的誤操作，因為無論增刪改，Redis都將其作為寫，同步到每個Slave節點上，所以**容災**，是指不可預知的錯誤導致數據丟失，這種情況下可以從Slave節點中找到原數據的備份，從而進行數據恢復。而讀寫分離就比較好理解了，上文中提到，Master節點可以讀寫，而Slave節點通常只進行讀操作，索性直接將所有的讀操作都轉移到Slave節點上，這樣可以減輕Master節點的IO壓力。 ![](https://img.kancloud.cn/47/f9/47f91fe78ee478e25b7dbccb690c3fdf_763x671.png) [手動搭建Redis集群和MySQL主從同步(非Docker)](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#) # 手動搭建Redis集群和MySQL主從同步(非Docker) [Redis](javascript:void(0);)[MySQL](javascript:void(0);)[主從同步](javascript:void(0);)[集群](javascript:void(0);)[分布式](javascript:void(0);)[高可用](javascript:void(0);) 字數統計:6.9k閱讀時長:25 min 2019/11/08211分享 * ![](data:image/gif;base64,R0lGODdhcgByAIAAAAAAAP///ywAAAAAcgByAAAC/4yPqcvtD6OctNqLs968+w+G4kiW5omm6sq2bgXE8jwbNG3LSpwj9cIL/H4+QO52oyCRR6ZQlwgGmwwplHiwLrGQKdAY0YKH4GIz+Syivbty2N2WiKnp6HjbyzrZduWdnMf1JAj4Rbd0+HcF9yBmFQilFqn3aDioSFa5xujgeAfJ58V39nnZuWh2WSmHWTrXp1eFUycomQeKOuGJi4slihdrajdKO0ssS8pbjHarOqtsa7npd4rc4BnqttWaXa3LGRx3zc34i+jcPe63renqDglfHN9Oes7K/i6vT7+fz49/rIMvYK8k/Zo36cUXc3sUtRmIMKAHe/qaRQSYKJk6Sv+57j2rWCcVNoK5mFnSKBHWKo4WQ4YLlq2WsJEpva3MCCuVyHIfo9EE53HnK5kHZ5acVMhayy5IHRolVjSTO4ZLX9b8htNkIqja/CVE53Si013DwubsR8fgoqtq4zUz+a+pzoUk234rVFQjwrQuA+J72zNDu3SAT3GVJbOwwKk85/r9WlXrWbaNAscsZRizMLuDA2uQfLmqz66X40r+zHjaZpfKDk/uyFpwamNm0yU9C3glZa4QlzXVDdlZy4Gn3yCW65tq3+Cqo9UDepenarLPqZc9nhkDoYa9SDckyjw4X6bH+WWnu4mhcrK7wU2HPp5jeu/rW4mW5iSy5+V8O+v/jc3BSHPZJQ40/VhHmXZrHZUXWtcZ5U18CdKFUm1ducUShBtJCJ9xZW2j1l/j+IceMKg9xE6IKY7IWHkmRgcQOQV9+N2KKhbnUYzVmXXjgiDSSFGAX9U3lGUM0jYjhqgR9tRYRnYmFYf3nbfXa8CReB97s61zIUi5aYYXcta89x+XpWmm4nBHoagkWEsOSZuLN2kYmpduLnaOeWDFmOSDIk4o55rL8VnjeX92yOZLKPYpFEZ05ncgohlmiSR0P83XXVQ8ViZOlBpWGORrY4oJQ2NN4gQqpAUC6NuApTLVHH8qkTSnmZK6uihsDWa64JSVJVbiaATKZ6pjyGkpIIze/3155qpf7pTqcwoSJ514q10Vpoi4KuscsVSymuilcFpw23x1XvlimTAZySWz9vkJpo3e4rcdNfO6ht2pD6rZX5fk0oemovD22VujxgrZnbFYJhcwXO69q2DCVh3Z6JwOjwqsi/rVymqDBQv3aMYscnzbth6TiinDIISq2LMCf5znb/vZiq+s/Sbq7owsbxgpryd3qzN391q7Kok/HTxpq8SiyyinNOZr8ElJQz3ozE4P262BrooMs6rcbqQpRYfGrGnUttrU5Y87Hn1tvPFldm6loMmLc4Y6XjA3sl5rS+HAdI8Qc5qrtSns4CoDLrS0hnOc1bgg5/gi3+rNxnSch6S3J7m8k/Oas6CxksfzY1vBuZ2nagIqMNIYQzwvZ6S+jRXImy8tM9nF2p0u3u/OvmOPBFfb+wZa8jsxtB0Lmqu6rFRIfMsOhhtwqqgPD5K5x8qNPItZO01m1clKHDi4SYu8rcT5Mtlp9u9Nbynr0Ds7q57r3wpkjbxFDzbKHaYMue33+2o2m41sUwopoAEPiMAEKnCBDGygAx8IwQhKcIIUFEEBAAA7) ## [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%89%8D%E8%A8%80 "前言")前言[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%89%8D%E8%A8%80) 一直都想自己動手搭建一個Redis集群和MySQL的主從同步，當然不是依靠Docker的一鍵部署（雖然現在企業開發用的最多的是這種方式），所以本文就算是一個教程類文章吧，但在動手搭建之前，會先聊聊理論的東西，以便于大家有一個**集群**和**主從同步**的概念，如果有同學不了解Redis和MySQL，可以看一下我之前的兩篇文章。 [Redis由淺入深深深深深剖析](http://blog.objectspace.cn/2019/09/16/Redis%E7%94%B1%E6%B5%85%E5%85%A5%E6%B7%B1%E6%B7%B1%E6%B7%B1%E6%B7%B1%E6%B7%B1%E5%89%96%E6%9E%90/) [【從入門到入土】令人脫發的數據庫底層設計](http://blog.objectspace.cn/2019/09/04/[%E4%BB%8E%E5%85%A5%E9%97%A8%E5%88%B0%E5%85%A5%E5%9C%9F]%E4%BB%A4%E4%BA%BA%E8%84%B1%E5%8F%91%E7%9A%84%E6%95%B0%E6%8D%AE%E5%BA%93%E5%BA%95%E5%B1%82%E8%AE%BE%E8%AE%A1/) ## [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E4%BB%80%E4%B9%88%E6%98%AFRedis%E9%9B%86%E7%BE%A4 "什么是Redis集群")什么是Redis集群[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E4%BB%80%E4%B9%88%E6%98%AFRedis%E9%9B%86%E7%BE%A4) * ### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E7%AE%80%E4%BB%8B "簡介")簡介[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E7%AE%80%E4%BB%8B) Redis是一個快速高效的NoSQL型數據庫，由于其基于內存存儲、單線程、多路IO復用的特性，其QPS可以達到驚人的100000+（官方數據），但是即使有這么高的速度，在中國這么大的網民基數環境下，也存在著性能瓶頸。首先拋開服務器故障不談，Redis集群首先可以使Redis性能得到線性提高，這是毋庸置疑的，其次Redis集群除了解決了效率問題，還可以解決服務器宕機造成的數據丟失問題，當某個Redis節點宕機，剩下的節點會繼續工作，并不會影響整體集群的使用，從而實現**高可用**。 * ### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#Redis%E5%8D%95%E6%9C%BA%E6%A8%A1%E5%BC%8F%E6%9C%89%E4%BB%80%E4%B9%88%E9%97%AE%E9%A2%98 "Redis單機模式有什么問題")Redis單機模式有什么問題[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#Redis%E5%8D%95%E6%9C%BA%E6%A8%A1%E5%BC%8F%E6%9C%89%E4%BB%80%E4%B9%88%E9%97%AE%E9%A2%98) * #### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%8D%95%E6%9C%BA%E6%95%85%E9%9A%9C "單機故障")單機故障[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%8D%95%E6%9C%BA%E6%95%85%E9%9A%9C) 在單機模式下的Redis，我們的應用中所有需要緩存的數據都依賴一臺Redis服務器，應用的流量小可能看不出什么問題，但是隨著應用越來越大，流量越來越大，如果出現服務器宕機或者斷電的狀況，那么我們的應用整個一個緩存層在一段時間內（重啟）都將不復存在，先不談基于Redis的分布式Session可能造成的問題，如果恰好遇上流量高峰，這些流量直接打在數據庫上，我們知道數據庫的IO效率遠不及Redis，這將大大提高應用負載，容易出現數據庫服務器的宕機，從而造成應用的宕機。由此看來，單機版Redis如果出現故障，將有可能引起一系列的連鎖反應，造成不可逆的損失。 * #### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%AE%B9%E9%87%8F%E7%93%B6%E9%A2%88 "容量瓶頸")容量瓶頸[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%AE%B9%E9%87%8F%E7%93%B6%E9%A2%88) 我們知道Redis是基于內存存儲的一個NoSQL數據庫，基于內存也是其**高速高效**的原因之一。雖然容量瓶頸在實際生產中并不常見（通常有意識地將搭載Redis的機器內存容量加高），但是不排除在某些極端條件下Redis會將一臺機器的內存耗盡，造成數據丟失，甚至服務器宕機。 * #### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E6%80%A7%E8%83%BD%E7%93%B6%E9%A2%88 "性能瓶頸")性能瓶頸[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E6%80%A7%E8%83%BD%E7%93%B6%E9%A2%88) 簡介中提到，雖然Redis在官方文檔中提到可以達到約100000+QPS，但是**首先**在日常環境的測試中，我們可能并達不到文檔中宣稱的QPS，換言之，這可能也就是一種理論值，就像是4G的理論網速在10-100Mbps，折合下載速度1.5M/s-10M/s，但在日常生活中我們極少甚至從來沒有達到過這個速度過，一樣的道理。**其次**，在中國巨大的網民基數下，單機Redis滿足日常需求尚且捉襟見肘，如果碰上像雙十一、雙十二、春運這些特殊的環境，單臺Redis顯然會有性能不足的現象發生。 * ### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#Redis%E9%9B%86%E7%BE%A4%E7%9A%84%E4%B8%89%E7%A7%8D%E6%A8%A1%E5%BC%8F "Redis集群的三種模式")Redis集群的三種模式[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#Redis%E9%9B%86%E7%BE%A4%E7%9A%84%E4%B8%89%E7%A7%8D%E6%A8%A1%E5%BC%8F) * #### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E4%B8%BB%E4%BB%8E%E6%A8%A1%E5%BC%8F "主從模式")主從模式[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E4%B8%BB%E4%BB%8E%E6%A8%A1%E5%BC%8F) 主從模式是最簡單的一種Redis集群模式，首先其思想就是一臺Redis服務器作為**主服務器（Master）**，一臺或多臺服務器作為**從服務器（Slave）**。當以此種方式部署集群時，集群有如下特點： 1. Master可以進行讀寫操作，當寫操作導致數據發生變化時，將自動同步給Slave，Slave通常是只讀的，并且接受從Master同步過來的數據。 2. **一臺Master可以有多臺Slave，但每臺Slave只能有一個Master**。 3. 某臺Slave宕機不影響其他Slave和Master的讀寫，重新啟動后會將數據重新從Master同步過來。 4. **Master宕機后不影響Slave的讀，但該集群不再提供對Redis的寫入功能**。 5. Master宕機后不會從Slave中選舉主節點。在此種模式下，我們可以對Redis集群做**容災備份**和**讀寫分離**，但是要注意，容災備份并不能拯救你的誤操作，因為無論增刪改，Redis都將其作為寫，同步到每個Slave節點上，所以**容災**，是指不可預知的錯誤導致數據丟失，這種情況下可以從Slave節點中找到原數據的備份，從而進行數據恢復。而讀寫分離就比較好理解了，上文中提到，Master節點可以讀寫，而Slave節點通常只進行讀操作，索性直接將所有的讀操作都轉移到Slave節點上，這樣可以減輕Master節點的IO壓力。 [![Redis主從](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/Redis%E4%B8%BB%E4%BB%8E.png)](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/Redis%E4%B8%BB%E4%BB%8E.png) **主從模式的工作原理（全量同步）**: Redis**全量同步**一般**發生在Slave初始化階段**，但其實在任何時候Slave都可以向Master發起全量同步的請求，這時Slave需要將Master上的所有數據都復制一份。 1. Slave連接主服務器，發送SYNC命令。 2. Master接收到SYNC命令后，開始執行BGSAVE命令生成RDB文件并使用緩沖區記錄此后執行的所有寫命令。 3. Master執行完BGSAVE后，向所有從服務器發送RDB文件，并在發送期間繼續記錄被執行的寫命令。 4. Slave收到RDB文件后丟棄所有舊數據，載入收到的RDB。 5. Master快照發送完畢后開始向Slave發送緩沖區中的寫命令。 6. Slave完成對RDB的載入，開始接收命令請求，并執行來自Master緩沖區的寫命令。 **主從模式的工作原理（增量同步）**: Redis**增量同步**一般發生在**Slave已經初始化完成，開始正常連接Master的階段** 1. Master接收到寫請求，將寫命令發送到Slave。 2. Slave執行接收到的些命令。 **注**：如果多個Slave同時宕機重啟，那么就會同時向Master發送SYNC命令，那么有可能會造成Master節點的IO劇增，有可能會引起宕機。 * #### [](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%93%A8%E5%85%B5%EF%BC%88Sentinel%EF%BC%89%E6%A8%A1%E5%BC%8F "哨兵（Sentinel）模式")哨兵（Sentinel）模式[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#%E5%93%A8%E5%85%B5%EF%BC%88Sentinel%EF%BC%89%E6%A8%A1%E5%BC%8F) 上文中介紹了Redis主從復制模式下的集群策略，**當Master宕機后，不會從Slave節點中選舉出Master**，所以該集群喪失了寫的能力，我們只能人工去將Slave節點晉升為Master節點，同時要通知應用方更新Master節點的IP地址，對于這種故障處理的方式在現在的環境下通常是不可接受的。所以從Redis2.8開始，Redis正式提供了哨兵模式的架構（故障轉移），來解決這個問題。 **哨兵模式的工作特點**： 1. 哨兵模式是建立在主從模式的基礎上，當Master節點宕機之后，哨兵會從Slave節點中選擇一個節點作為Master，并修改它們的配置文件，使其他的Slave指向新的Master。 2. 當原先宕機的Master節點重新啟動時，他將不再是Master，而是作為新Master的一個Slave節點存在。 3. 哨兵節點是一個特殊的Redis節點（不存儲數據），本質上也是一個進程，所以也有掛掉的可能，所以哨兵也存在集群模式。 **哨兵模式工作原理**： 1. 每隔10秒，每個哨兵節點會向Master和Slave節點發送info命令獲取最新的拓撲結構。 2. 每隔1秒，每個哨兵節點會向Master和Slave節點還有其它哨兵節點發送ping命令做心跳檢測，看看是否存在不可達的節點。 3. **主觀下線**，如果某個哨兵向一個節點發出的心跳檢測沒有得到響應，那么該哨兵認為該節點已經下線。 4. **客觀下線**，當哨兵主觀下線的節點是主節點時，哨兵會向其他的哨兵詢問對主節點的判斷，當下線判斷超過一定個數時，那么哨兵會認為主節點確實已經下線，那么會對主節點進行客觀下線的判定。 5. **故障轉移**，當Master節點客觀下線時，哨兵會從Slave節點中選擇一個節點作為Master節點，選擇規則是**選擇與主節點復制相似度最高的節點**，選擇完成后會將其余的Slave節點指向新的Master節點，并監控原來的Master節點，當它回復后作為新Master節點的Slave存在，并且同步新Master節點的數據。 6. **選舉領導者哨兵節點**：當主節點被判斷客觀下線以后，各個哨兵節點會進行協商，選舉出一個領導者哨兵節點，并由該領導者節點對其進行故障轉移操作。 7. 當使用sentinel模式的時候，客戶端不用直接連接Redis，而是連接哨兵的ip和port，由哨兵來提供具體的可提供服務的Redis實現，這樣當master節點掛掉以后，哨兵就會感知并將新的master節點提供給使用者。 ![](https://img.kancloud.cn/a0/64/a06426dad480f46d7fdb2a5575bd369c_681x490.png) #### Cluster模式[](http://blog.objectspace.cn/2019/11/08/%E6%89%8B%E5%8A%A8%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4%E5%92%8CMySQL%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5(%E9%9D%9EDocker)/#Cluster%E6%A8%A1%E5%BC%8F) 在上文的哨兵模式中，哨兵引入了主節點的自動故障轉移，進一步提高了Redis的高可用性。但是哨兵的**缺陷**同樣很明顯：哨兵無法對Slave進行自動故障轉移，在讀寫分離場景下，Slave故障會導致讀服務不可用，需要我們對Slave做額外的監控、切換操作。此外，哨兵仍然沒有解決寫操作無法負載均衡、及存儲能力受到單機限制的問題。 Redis Cluster模式是Redis3.0之后推薦的一種解決方案，其是由多個主節點群組成的分布式服務器群，它具有復制、高可用和分片的特性。另外，Redis Cluster集群不需要哨兵也能完成節點移除和故障轉移的功能。需要將每個節點設置為集群模式，這種集群模式沒有中心節點，可水平擴展，且集群配置非常簡單。 **Cluster集群模式工作特點**： 1. 多個Redis節點互聯，數據共享。 2. 所有的節點都是主從模式，其中Slave不提供服務，只提供備用。 3. 不支持同時處理多個Key，因為需要分發到多個節點上。 4. 支持在線增加、刪除節點。 5. 客戶端可以連接任何一個Master節點進行讀寫。 **Cluster集群模式工作原理**： 1. Redis Cluster有固定的16384個hash slot(**槽**)，對每個key計算CRC16值，然后對16384取模，可以獲取key對應的hash slot。每個master都會持有部分slot，比如有3個master，那么可能每個master持有5000多個hash slot，在redis cluster寫入數據的時候，其實是你可以將請求發送到任意一個master上去執行。但是，每個master都會計算這個key對應的CRC16值，然后對16384個hashslot取模，找到key對應的hashslot，找到hashslot對應的master。 2. **主觀下線**(pfail)：集群中的每個節點都會定期向其他節點發送ping消息，如果在一段時間內一直通信失敗，則發送節點方認為接收節點存在故障，把接收節點標為主觀下線(pfail)狀態。 3. **客觀下線**(fail)：當某個節點判斷另一個節點主觀下線后，相應的節點狀態就會在集群中進行傳播，如果集群中所有節點都將它標為主觀下線，那么該節點為客觀下線，并通知該節點的Slave進行**故障轉移**操作。 4. **故障轉移**：在某個節點客觀下線后，該節點的從節點開始故障轉移流程，首先進行資格檢查，每個從節點檢查與主節點的斷開時間，超過一定時間的取消選舉資格，然后同樣在所有從節點中尋找復制偏移量最大的節點先開始進行選舉，**只有持有槽的主節點才有投票權**，當從節點收集到過半的票數時，即晉升為Master，隨即通知Slave當前Master變為自己。 ![](https://img.kancloud.cn/7f/dc/7fdc12f3aecae8981be604bf65006eef_776x476.png)