大数据互联网架构阶段 Redis（二）

Redis(二)

零、目录

将缓存引入电商项目
主从复制
哨兵模式
集群容忍度
CAP理论

十、将缓存引入电商项目

使用Spring框架维护Jedis池对象

引入一个配置文件 application-redis.config

<beans xmlns="http://www.springframework.org/schema/beans"xmlns:context="http://www.springframework.org/schema/context" xmlns:p="http://www.springframework.org/schema/p"xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.0.xsdhttp://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.0.xsdhttp://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-4.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-4.0.xsdhttp://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-4.0.xsd"><!-- 构建连接池配置信息 --><bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig"><!-- 最大连接数 --><property name="maxTotal" value="${redis.maxTotal}" /></bean><bean id="jedisShardInfo1" class="redis.clients.jedis.JedisShardInfo"><constructor-arg index="0" value="${redis.node1.ip}" /><constructor-arg index="1" value="${redis.node1.port}"type="int" /></bean><!-- bean id="jedisShardInfo2" class="redis.clients.jedis.JedisShardInfo"><constructor-arg index="0" value="${redis.node2.ip}" /><constructor-arg index="1" value="${redis.node2.port}"type="int" /></bean><bean id="jedisShardInfo3" class="redis.clients.jedis.JedisShardInfo"><constructor-arg index="0" value="${redis.node3.ip}" /><constructor-arg index="1" value="${redis.node3.port}"type="int" /></bean--><!-- 定义集群连接池 --><bean id="shardedJedisPool" class="redis.clients.jedis.ShardedJedisPool"destroy-method="close"><constructor-arg index="0" ref="jedisPoolConfig" /><constructor-arg index="1"><list><ref bean="jedisShardInfo1" /><!--ref bean="jedisShardInfo2" /><ref bean="jedisShardInfo3" /--></list></constructor-arg></bean></beans>

需要加载配置文件，在application.xml（Spring核心配置文件中配置加载application-redis.xml中所需要的配置信息）

redis.maxTotal=200
redis.node1.ip=106.75.85.179
redis.node1.port=6379
redis.node2.ip=106.75.85.179
redis.node2.port=6380
redis.node3.ip=106.75.85.179
redis.node3.port=6381

使用注解自动注入shardedjedidpool对象，即可使用。

十一、主从复制

当前redis结构可用性非常低，当其中某个结点宕机之后，数据不可查，需要机器重启后才能恢复。
解决不可用问题需要引入高可用的结构（高可用，即使宕机任然不影响当前功能）
具体实现，引入三台机器，将主节点的数据全部复制。（主从复制，数据备份）
当主节点（master）宕机之后，从节点（slave）能够顶替主节点来接收接下来的求情，这种结构就叫做高可用
分布式架构中，必不可少高可用特性
主从结构：
1. redis可以提供主从复制的结构
2. redis提供的主从结构支持多级复制
3. 在redis中配置了主从结构之后，主节点的数据操作（赠、删、改）将实时同步到从节点中
4. 操作：
  1. 准备主节点、从节点的配置文件
  2. 分别编辑配置文件的bind（注掉）、 port （不要与其他端口冲突即可）、 protected-modo no 、 diamonize yes（后台守护）、 pid文件（pidfile_与端口对应）
  3. 分别启动这三个redis文件对应的reids服务
  4. 再打开三个终端，分别开启redis客户端（redis-cli -p 端口号）执行info replication ，查看信息
  5. 在客户端中操作，实现一主两从结构 6382（主）、 6383 、 6384（从），需要在6383 、和6384 的客户端执行 slaveof 127.0.0.1（主节点主机IP ，如果在同一台机器中，最好使用内网地址）主节点端口
  6. 从节点挂接主节点完成之后，查看三个客户端的info replication信息中的role等信息，查看是否挂载成功
    1. 主节点信息
    2. 从节点信息

十二、哨兵模式

完成上面的操作（构建一主两从结构）之后，测试该结构的高可用
1. 把直接点kill（或在主节点的客户端shutdown）掉，查看某一个从节点是否主动担任了主节点的角色，并且将另一个从节点挂载在自己身上继续完成主从复制（主从结构的目的）
2. 操作：
  1. 在主节点6382的客户端中执行shutdown ，模拟主节点宕机，
  2. 观察从节点的info replication ，发现角色并没有任何转变，高可用并没有启动
于是redis中引入了哨兵模式
哨兵是redis启动的进程，一个哨兵进程可以挂载一个主从的结构，来管理当前主从结构的高可用,多个哨兵进程可以挂载多个主从结构,多个哨兵可以挂载一个主从
哨兵进程通过连接主从执行info命令,判断当前主从结构是否正常,当发现主节点宕机,将会启动内部逻辑,将从节点中的slave-priority数值较高的节点启动替换主节点,将其他的从节点挂接到新的主节点上完成高可用主从替换
哨兵集群启动后，整个架构就是高可用的最终模式
哨兵模式+主从复制的最终模式
操作步骤：
1. 修改启动哨兵的配置文件 sentinel.cong
  1. bind注释掉，在测试中不需要绑定指定的ip ，任何ip都可以访问
  2. protected-mode no 关闭保护模式（不需要密码了）
  3. 哨兵的默认端口是26379 ，我们这里使用三个哨兵做示例，所以使用26379 、 26380 、 26381 三个端口
  4. 修改监听主从的挂接配置
    1. sentinel monitor ：开始监听主从结构中的主节点
    2. mymaster ：给监听的主从结构起个名字
    3. ip ：主节点的所在的ip
    4. port ：主节点的端口号
    5. 2 ：哨兵启动后投票选举新的主节点的最少哨兵的数量，配置成1
  5. 修改选举新节点失败时的时间延迟（第一轮选举和第二轮选举的时间间隔）
  6. 复制配置好的哨兵配置文件，并修改哨兵自己的的端口 26380 、 26381
  7. 想要实现的效果：高可用结构启动之后，当主节点宕机之后，从节点主动变为主节点。
  8. 开启需要监听的主从结构，开启所有哨兵进程、开始监听主从结构开启命令： redis-sentinel 哨兵的配置文件
  9. 测试： shutdown掉主节点，看看哨兵是否启动高可用new-epoch :逻辑时间数，当前的日志步数
  10. 将宕机的主节点重启，发现哨兵将刚启动的旧的主节点作为现在的主节点的从节点提供服务
  11. 宕掉一个哨兵后再视图宕掉一个主节点，这时剩余的两个哨兵会进行投票选举，如果单个从结点投票过半，则被晋升为主节点。
  12. 注意：当原本只有两个哨兵时，宕掉一个之后，一个哨兵投票始终无法票数过半，导致陷入死循环，导致一直在投票。所以最好启动奇数个哨兵
在Jedis中也是支持哨兵模式的， api配置内容就从配置具体的redis信息,到配置哨兵的节点信息和端口,3.0以后的redis引入了集群的技术,导致哨兵的高可用不在单独使用集群里就包含了哨兵的高可用,包含了主从结构

十三、集群容忍度：

选举过半原则导致，集群容忍度概念的引出

2个哨兵,多少算过半(2个)--,允许宕机的个数0,集群容忍度0,
3个哨兵,2个过半没允许,宕机的个数是1,容忍度1
4个哨兵,3个过半,宕机个数允许1,容忍度1
2n个选举法人,2n-1个选举法人的容忍度一样

十二、 CAP理论

随着数据量存储增长需求，业务的多元化，分布式结构必不可少， CAP理论始终是分布式公认的基础理论之一。
C ： consistency（一致性）
A ： avalibility（可用性）
P ： partition（分区） – tolerence to paetition（分区容忍度）
分区：
1. 一个系统中，多个系统组成网络本来应该是互通的，但是可能因为某种原因导致某两个或某几个结点间的数据通信断开，导致整个系统被分割成为了几个独立的数据区域（分区）。分区是一种常态。
2. 当分区出现时，就需要考虑数据的一致性。
一致性：
1. 数据在某个查看的时间点上保持整体一致
2. 如果在修改数据时，对于查看数据的客户端要求数据一致，则必须加锁，实现数据整体性
3. 如果在修改数据时，对弈查看数据的客户端不要求数据一致，则没有体现数据的一致性
分区容忍度：
1. 如果对数据一致性要求高的话，分区容忍度高，一致性需要执行（即加锁）
2. 如果对数据一致性要求低，则分区容忍度低
3. 如果要求数据一致性高（加锁）的查看数据的人，在一段时间（修改数据的一段时间）内无法进行查看数据
可用性：
1. 请求在一段时间都有回应（请求时立即返回请求数据）
总结：
1. 分区是常态（始终是存在的），而一致性和可用性相互矛盾只能满足其一，不可能达到三者共存的状态。
2. cp理论：分区容忍度高，数据一致性高，可用性降低
3. ap理论：分区容忍度低，数据一致性低，可用性提升
4. 分区导致一致性的要求，要求高，可用性低，要求低，可用性高。
随中数据量存储增长的需求，数据多元化