數據庫為什么要讀寫分離
寫代碼好多年了，大家先拋棄在代碼框架里面各種花哨的設計之外，寫的代碼到最后無非就是為了增刪查改數據庫。一般項目數據庫剛開始只是但一個庫，隨着數據量的增大，就開始優化數據庫（拋開代碼）首先添加索引 視圖等等，時間長了數據更多還是不行，然后就開始創建主從數據庫 實現讀寫分離，但是數據多了，還是不行，后面就有數據庫橫向 縱向拆分 （分布式數據）。
主從數據庫的好處
1、減少主服務器壓力。
2、提高讀取性能。
3、熱備份。
redis搭建主從（master-slaver）
本文redis版本為 windows 3.2.1
redis的主從也是在配置文件中配置的。
REPLICATION
1、配置主redis
bind 127.0.0.1
port 11111
requirepass 123456 （密碼我隨便寫的）
masterauth 123456 這個也需要的，主變成從的，會用的
配置完后啟動redis服務。
2、配置從redis
bind 127.0.0.1
port 12111
requirepass 123456 （密碼我隨便寫的）
slaveof 127.0.0.1 11111
masterauth 123456
配置完后啟動redis服務
3、主redis添加數據測試
redis哨兵（sentinel）
Sentinel（哨兵）是Redis 的高可用性解決方案：由一個或多個Sentinel 實例 組成的Sentinel 系統可以監視任意多個主服務器，以及這些主服務器屬下的所有從服務器，並在被監視的主服務器進入下線狀態時，自動將下線主服務器屬下的某個從服務器升級為新的主服務器。
例如：
在Server1 掉線后：
升級Server2 為新的主服務器：
哨兵配置
1、關於配置文件
哨兵配置，也是通過配安文件配置的。但是我們redis安裝包里面沒有配置文件項。后來通過查找資料，這個配置文件要自己創建或者在源碼項目中找到這個配置文件。
https://github.com/tporadowski/redis
2、配置文件介紹
注：1、關於配置文件，一定要下載對應的版本，不然會報錯。比如，下載的安裝包是3.2.1，那么就應該在對應的源碼里找哨兵的配置文件。（曾經用的3.2.1的包，用的3.0的配置文件，出的BUG根本找不出問題）
2、網上看了很多windows配置哨兵的，都是3.0以下版本的，對3.2.1不可用。
# Example sentinel.conf # *** IMPORTANT *** # # By default Sentinel will not be reachable from interfaces different than # localhost, either use the 'bind' directive to bind to a list of network # interfaces, or disable protected mode with "protected-mode no" by # adding it to this configuration file. # # Before doing that MAKE SURE the instance is protected from the outside # world via firewalling or other means. # # For example you may use one of the following: # # bind 127.0.0.1 192.168.1.1 # # protected-mode no # port <sentinel-port> # The port that this sentinel instance will run on port 26379 # sentinel announce-ip <ip> # sentinel announce-port <port> # # The above two configuration directives are useful in environments where, # because of NAT, Sentinel is reachable from outside via a non-local address. # # When announce-ip is provided, the Sentinel will claim the specified IP address # in HELLO messages used to gossip its presence, instead of auto-detecting the # local address as it usually does. # # Similarly when announce-port is provided and is valid and non-zero, Sentinel # will announce the specified TCP port. # # The two options don't need to be used together, if only announce-ip is # provided, the Sentinel will announce the specified IP and the server port # as specified by the "port" option. If only announce-port is provided, the # Sentinel will announce the auto-detected local IP and the specified port. # # Example: # # sentinel announce-ip 1.2.3.4 # dir <working-directory> # Every long running process should have a well-defined working directory. # For Redis Sentinel to chdir to /tmp at startup is the simplest thing # for the process to don't interfere with administrative tasks such as # unmounting filesystems. dir /tmp # sentinel monitor <master-name> <ip> <redis-port> <quorum> # # Tells Sentinel to monitor this master, and to consider it in O_DOWN # (Objectively Down) state only if at least <quorum> sentinels agree. # # Note that whatever is the ODOWN quorum, a Sentinel will require to # be elected by the majority of the known Sentinels in order to # start a failover, so no failover can be performed in minority. # # Slaves are auto-discovered, so you don't need to specify slaves in # any way. Sentinel itself will rewrite this configuration file adding # the slaves using additional configuration options. # Also note that the configuration file is rewritten when a # slave is promoted to master. # # Note: master name should not include special characters or spaces. # The valid charset is A-z 0-9 and the three characters ".-_". sentinel monitor mymaster 127.0.0.1 6379 2 # sentinel auth-pass <master-name> <password> # # Set the password to use to authenticate with the master and slaves. # Useful if there is a password set in the Redis instances to monitor. # # Note that the master password is also used for slaves, so it is not # possible to set a different password in masters and slaves instances # if you want to be able to monitor these instances with Sentinel. # # However you can have Redis instances without the authentication enabled # mixed with Redis instances requiring the authentication (as long as the # password set is the same for all the instances requiring the password) as # the AUTH command will have no effect in Redis instances with authentication # switched off. # # Example: # # sentinel auth-pass mymaster MySUPER--secret-0123passw0rd # sentinel down-after-milliseconds <master-name> <milliseconds> # # Number of milliseconds the master (or any attached slave or sentinel) should # be unreachable (as in, not acceptable reply to PING, continuously, for the # specified period) in order to consider it in S_DOWN state (Subjectively # Down). # # Default is 30 seconds. sentinel down-after-milliseconds mymaster 30000 # sentinel parallel-syncs <master-name> <numslaves> # # How many slaves we can reconfigure to point to the new slave simultaneously # during the failover. Use a low number if you use the slaves to serve query # to avoid that all the slaves will be unreachable at about the same # time while performing the synchronization with the master. sentinel parallel-syncs mymaster 1 # sentinel failover-timeout <master-name> <milliseconds> # # Specifies the failover timeout in milliseconds. It is used in many ways: # # - The time needed to re-start a failover after a previous failover was # already tried against the same master by a given Sentinel, is two # times the failover timeout. # # - The time needed for a slave replicating to a wrong master according # to a Sentinel current configuration, to be forced to replicate # with the right master, is exactly the failover timeout (counting since # the moment a Sentinel detected the misconfiguration). # # - The time needed to cancel a failover that is already in progress but # did not produced any configuration change (SLAVEOF NO ONE yet not # acknowledged by the promoted slave). # # - The maximum time a failover in progress waits for all the slaves to be # reconfigured as slaves of the new master. However even after this time # the slaves will be reconfigured by the Sentinels anyway, but not with # the exact parallel-syncs progression as specified. # # Default is 3 minutes. sentinel failover-timeout mymaster 180000 # SCRIPTS EXECUTION # # sentinel notification-script and sentinel reconfig-script are used in order # to configure scripts that are called to notify the system administrator # or to reconfigure clients after a failover. The scripts are executed # with the following rules for error handling: # # If script exits with "1" the execution is retried later (up to a maximum # number of times currently set to 10). # # If script exits with "2" (or an higher value) the script execution is # not retried. # # If script terminates because it receives a signal the behavior is the same # as exit code 1. # # A script has a maximum running time of 60 seconds. After this limit is # reached the script is terminated with a SIGKILL and the execution retried. # NOTIFICATION SCRIPT # # sentinel notification-script <master-name> <script-path> # # Call the specified notification script for any sentinel event that is # generated in the WARNING level (for instance -sdown, -odown, and so forth). # This script should notify the system administrator via email, SMS, or any # other messaging system, that there is something wrong with the monitored # Redis systems. # # The script is called with just two arguments: the first is the event type # and the second the event description. # # The script must exist and be executable in order for sentinel to start if # this option is provided. # # Example: # # sentinel notification-script mymaster /var/redis/notify.sh # CLIENTS RECONFIGURATION SCRIPT # # sentinel client-reconfig-script <master-name> <script-path> # # When the master changed because of a failover a script can be called in # order to perform application-specific tasks to notify the clients that the # configuration has changed and the master is at a different address. # # The following arguments are passed to the script: # # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> # # <state> is currently always "failover" # <role> is either "leader" or "observer" # # The arguments from-ip, from-port, to-ip, to-port are used to communicate # the old address of the master and the new address of the elected slave # (now a master). # # This script should be resistant to multiple invocations. # # Example: # # sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
bind
默認的哨兵只能從本地主機訪問就是local本地（127.0.0.1），或者用bind指令設置一個網絡列表，禁用protected mode（protected mode no），確保防火牆暢通。
Sentinel運行的主機，不設置默認為local本地（127.0.0.1）。
建議設置為127.0.01
port
當前Sentinel服務運行的端口
sentinel announce-ip <ip>
sentinel announce-port <port>
以上兩個配置指令在環境中非常有用，由於NAT, Sentinel可以通過非本地地址從外部訪問。
不需要外部訪問就不用設置。
dir <working-directory>
每個長時間運行的進程都應該有一個定義良好的工作目錄。對於Redis Sentinel來說，在啟動過程中，設置子目錄是最簡單的方法，它不會干擾諸如卸載文件系統之類的管理任務。
一定要設置一個目錄。（3.2.1默認的是E:\\）
sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2:Sentinel去監視一個名為mymaster的主redis實例，這個主實例的IP地址為本機地址127.0.0.1，端口號為6379，而將這個主實例判斷為失效至少需要2個 Sentinel進程的同意，只要同意Sentinel的數量不達標，自動failover就不會執行。建議master-name一個master寫一個名字，可以幾個哨兵都是監控一個master，那么這幾個哨兵設置的name是一樣的。
sentinel myid
哨兵的ID，每一個哨兵ID都不能一樣。這個一樣要改。
sentinel auth-pass <master-name> <password>
master的密碼。如果主master設置了密碼，這里就要設置。 slaver默認的使用這個密碼。
sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 5000:指定了Sentinel認為Redis實例已經失效所需的毫秒數。當 實例超過該時間沒有返回PING，或者直接返回錯誤，那么Sentinel將這個實例標記為主觀下線。只有一個 Sentinel進程將實例標記為主觀下線並不一定會引起實例的自動故障遷移：只有在足夠數量的Sentinel都將一個實例標記為主觀下線之后，實例才會被標記為客觀下線，這時自動故障遷移才會執行
sentinel parallel-syncs
sentinel parallel-syncs mymaster 1：指定了在執行故障轉移時，最多可以有多少個從Redis實例在同步新的主實例，在從Redis實例較多的情況下這個數字越小，同步的時間越長，完成故障轉移所需的時間就越長
sentinel failover-timeout
sentinel failover-timeout mymaster 15000：如果在該時間（ms）內未能完成failover（故障轉移 ）操作，則認為該failover失敗
還有一些翻譯不動了。
哨兵的日志文件默認追加在配置文件的末尾。如下。
redis哨兵配置下載 由於安裝程序比較大請去官網下載redis安裝包 並在下面每個文件夾中復制一份，配置文件不要覆蓋。
一個master，兩個slaver，三個sentinel
啟動過程
1、啟動master。在RedisMaster11111文件夾中。這個是master
二、啟動兩個slaver
三、啟動三個sentinel（這里啟動的是一個cmd窗口，也可以自己寫代碼 把他變成windows服務）
四、測試，
通過windows服務，關閉開啟master服務，查看哨兵監控情況（根據設置的監控時間，需要等一下），以及開啟slaver客戶端查看info replication情況
感念介紹
Sentinel的作用
A、Master 狀態監測
B、如果Master 異常，則會進行Master-slave 轉換，將其中一個Slave作為Master，將之前的Master作為Slave
C、Master-Slave切換后，master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變，即master_redis.conf中會多一行slaveof的配置（變成從的）， sentinel.conf的監控目標會隨之調換
Sentinel的工作方式
1)：每個Sentinel以每秒鍾一次的頻率向它所知的Master，Slave以及其他 Sentinel 實例發送一個 PING 命令
2)：如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被 Sentinel 標記為主觀下線。
3)：如果一個Master被標記為主觀下線，則正在監視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master的確進入了主觀下線狀態。
4)：當有足夠數量的 Sentinel（大於等於配置文件指定的值）在指定的時間范圍內確認Master的確進入了主觀下線狀態， 則Master會被標記為客觀下線
5)：在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有Master，Slave發送 INFO 命令
6)：當Master被 Sentinel 標記為客觀下線時，Sentinel 向下線的 Master 的所有 Slave 發送 INFO 命令的頻率會從 10 秒一次改為每秒一次
7)：若沒有足夠數量的 Sentinel 同意 Master 已經下線， Master 的客觀下線狀態就會被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回復， Master 的主觀下線狀態就會被移除。
主觀下線和客觀下線
1. 主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 實例對服務器做出的下線判斷。
2. 客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷， 並且通過 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服務器下線判斷。
客觀下線條件只適用於主服務器： 對於任何其他類型的 Redis 實例， Sentinel 在將它們判斷為下線前不需要進行協商， 所以從服務器或者其他 Sentinel 永遠不會達到客觀下線條件。
只要一個 Sentinel 發現某個主服務器進入了客觀下線狀態， 這個 Sentinel 就可能會被其他 Sentinel 推選出， 並對失效的主服務器執行自動故障遷移操作。
https://www.cnblogs.com/jaycekon/p/6237562.html
http://www.cnblogs.com/Xrinehart/p/3502198.html
http://www.redis.cn/topics/sentinel.html
http://bbs.redis.cn/forum.php?mod=viewthread&tid=715