开发者学堂课程【Redis 数据库入门：Redis_ 集群 _Twitter_Twemproxy 模式_1】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/15/detail/61
Redis_集群_Twitter_Twemproxy模式_1
内容介绍
一、Redis 主从复制
二、Redis 哨兵
三、Redis Twemproxy
一、Redis 主从复制
1.主从复制 Replication
（1）一个 Redis 服务可以有多个该服务的复制品，这个 Redis 服务称为 Master，其他复制品称为 Slaves
只要网络连接正常， Master 会一直将自己的数据更新同步给 Slaves，保持主从同步
只有 Master 可以执行写命令， Slaves 只能执行读命令
- 从服务器执行客户端发送的读命令，比如 GET、LRANGE、SMEMMBERS、HGET ZRANGE 等等。
客户端可以连接 Slaves 执行读请求，来降低 Master 的读压力
2.主从复制创建
- redis-server--slaveof<master-ip><masterport， 配置前服务称为某 Redis 服务的 Slave
#redis-server--port6380--slaveof1270.016379
- SLAVEOFhostport 命令，将当前服务器状态从 Master 修改为别的服务器的 Slave
redis>SLAVEOF 192168116379，将服务器转换为 Slave
redis>SLAVEOF NO ONE，将服务器重新恢复到 Master，不会丢弃已同步数据
- 配置方式:启动时，服务器读取配置文件，并自动成为指定服务器的从服务器
slaveof<masterip> <masterport>
slaveof1270.0.16379
3.主从复制演示
- redis-server--slaveof<masterip><master-port>
- #redis-server--port6380--slaveof 127.0.0.16379
- #redis-cli-p6380-n0
- 测试 Master 和 Slave 的读写
4.主从复制问题
- 一个 Master 可以有多个 Slaves
- Slave 下线，只是读请求的处理性能下降
- Master 下线，写请求无法执行
- 其中一台 Slave 使用 SLAVEOFno one 命令成为Master ，
其它 Slaves 执行 SLAVEOF 命令指向这个新的 Master ，从它这里同步数据
以上过程是手动的，能够实现自动，这就需要 Sentinel 哨兵，实现故障转移 Failover 操作
二、Redis 哨兵
1. 高可用 Sentinel
- 官方提供的高可用方案，可以用它管理多个 Redis 服务实例
- 编译后产生 redis-sentinel 程序文件
- Redis Sentinel 是一个分布式系统，可以在一个架构中运行多
Sentinel 进程
2. 启动 Sentinel
- 将 src 目录下产生 redis-sentinel 程序文件复制到 $REDIS HOME/bin
- 启动一个运行在 Sentinel 模式下的 Redis 服务实例
redis-sentinel
redis-server/path/to/sentinelconf--sentinel
- Redis Sentinel 是一个分布式系统，可以在一个架构中运行多个Sentinel 进程
3. 监控 Monitoring
- Sentinel 会不断检查 Master 和 Slaves 是否正常
- 每一个Sentinel可以监控任意多个 Master 和该 Master 下的 Slaves
4.Sentinel 网络
（1）监控同一个 Master 的 Sentinel 会自动连接，组成一个分布式的 Sentinel 网络，互相通信并交换彼此关于被监视服务器的信息
下图中3个 Sentinel 监控着 S1和它的2个 Slave。
（2）服务器下线
- 当一个 sentinel 认为被监视的服务器已经下线时，它会向网络中的其他 Sentinel 进行确认，判断该服务器是否真的已经下线
- 如果下线的服务器为主服务器，那么 sentinel 网络将对下线主服务器进行自动故障转移，通过将下线主服务器的某个从服务器提升为新的主服务器，并让其从服务器转为复制新的主服务器，以此来让系统重新回到上线的状态
（3）服务器下线后重新上线
5.Sentinel 配置文件
- 至少包含一个监控配置选项，用于指定被监控 Master 的相关信息
- Sentinel monitor<name><ip><port><quorum>，例如
sentinel monitor mymaster 1270.0163792
监视 mymaster 的主服务器，服务器 ip 和端口，将这个主服务器判断为下线失效至少需要2个 Sentinel 同意，如果多数 Sentinel 同意才会执行故障转移
- Sentinel 会根据 Master 的配置自动发现 Master 的 Slaves
- Sentinel 默认端口号为26379
6.Sentinel 实验
7.Sentinel 总结
- 主从复制，解决了读请求的分担，从节点下线，会使得读请求能力有所下降
- Master 只有一个，写请求单点问题
- Sentinel 会在 Master 下线后自动执行 Failover 操作，提升一台 Slave 为 Master ，并让其他 Slaves 重新成为新 Master 的 SlavesI
- 主从复制+哨兵 Sentinel 只解决了读性能和高可用问题，但是没有解决写性能问题
三、Redis Twemproxy
1.问题引出
- 主从对写压力没有分担
- 解决思路就是，使用多个节点分担，将写请求分散到不同节点处理
- 分片 Sharding: 多节点分担的思路就是关系型数据库处理大表的水平切分思路
2.Twemproxy
- Twitter 开发，代理用户的读写请求
- Twitter 开发的代理服务器，他兼容 Redis 和 Memcached，允许用户将多个 redis 服务器添加到一个服务器池(pool)里面，并通过用户选择的散列函数和分布函数，将来自客户端的命令请求分发给服务器池中的各个服务器
- 通过使用 twemproxv 我们可以将数据库分片到多台 redis 服务器上面，并使用这些服务器来分担系统压力以及数据库容量:在服务器硬件条件相同的情况下，对于一个包含 N 台 redis 服务器的池来说，池中每台平均1/N 的客户端命令请求
- 向池里添加更多服务器可以线性的扩展系统处理命令请求的能力，以及系统能够保存的数据量
