redis 主从 哨兵
数据库为什么要读写分离
写代码好多年了，大家先抛弃在代码框架里面各种花哨的设计之外，写的代码到最后无非就是为了增删查改数据库。一般项目数据库刚开始只是但一个库，随着数据量的增大，就开始优化数据库（抛开代码）首先添加索引 视图等等，时间长了数据更多还是不行，然后就开始创建主从数据库 实现读写分离，但是数据多了，还是不行，后面就有数据库横向 纵向拆分 （分布式数据）。
主从数据库的好处
1、减少主服务器压力。
2、提高读取性能。
3、热备份。
redis搭建主从（master-slaver）
本文redis版本为 windows 3.2.1
redis的主从也是在配置文件中配置的。
REPLICATION1、配置主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
