基于Redis的分布式缓存架构

基于Redis的分布式缓存架构目录一、预备知识Redis二、分布式理论三、

基于Redis的分布式缓存架构Redis推荐书<Redis设计与实现>网站

/en/latest/http://redis.io/Redis是完全开源免费的，遵守BSD协议，先进的key-value持久化产品。Redis优点支持丰富的数据结构支持

字符串(String),哈希(Map),列表(list),集合(sets)

和有序集合(sortedsets)等多种数据类型。支持更多的命令Redis支持数据持久化,rdb/aofredis单点的性能非常高效，可使用自带的性能测试工具benchmark进行测试，redis官方公布读写性能在10万tps。Redis协议/en/latest/topic/protocol.html消息头标识，消息行还有就行里可能还有个数据块大小描述.首先Redis是以行来划分，每行以\r\n行结束。每一行都有一个消息头，消息头共分为5种分别如下:(+)表示一个正确的状态信息，具体信息是当前行+后面的字符。(-)

表示一个错误信息，具体信息是当前行－后面的字符。(*)表示消息体总共有多少行，不包括当前行,*后面是具体的行数。($)表示下一行数据长度，不包括换行符长度\r\n,$后面则是对应的长度的数据。(:)表示返回一个数值，：后面是相应的数字节符。Redis典型使用场景

缓存

消息队列Redis典型使用场景-缓存SETkeyvalue[EXseconds][PXmilliseconds][NX|XX]将字符串值value关联到key。如果key已经持有其他值，SET

就覆写旧值，无视类型。对于某个原本带有生存时间（TTL）的键来说，当SET

命令成功在这个键上执行时，这个键原有的TTL将被清除。EXPIREkeyseconds为给定key设置生存时间，当key过期时(生存时间为0)，它会被自动删除。Redis典型使用场景-消息队列一般来说，消息队列有两种场景，一种是发布者订阅者模式，一种是生产者消费者模式。利用redis这两种场景的消息队列都能够实现。

定义：生产者消费者模式：生产者生产消息放到队列里，多个消费者同时监听队列，谁先抢到消息谁就会从队列中取走消息；即对于每个消息只能被最多一个消费者拥有。发布者订阅者模式：发布者生产消息放到队列里，多个监听队列的消费者都会收到同一份消息；即正常情况下每个消费者收到的消息应该都是一样的。/lhfcws/p/3732535.html分布式理论并发性：共享资源，采取ACID或Base原则，见：CAP定理。分布式系统设计遵循CAP定理，CAP是：Consistency(一致性),Availability(可用性),和Partitiontolerance(分区容错性)可靠性简称，CAP定理认为，CAP三种之中，只能同时满足其中两种。可扩展性Scalable是重要特点，通过扩展能够获得高性能高吞吐量低延迟Latency。可靠性/可用性:故障发现和处理以及恢复容错处理。在一个正常运作系统中存在一个时间比例的条件。如果一个用户不能访问系统比例增大，它被认为是不可用。可用性公式：Availability=uptime/(uptime+downtime)，容错failover是指一个系统在错误发生的情况下，仍然一切运行正常。表示这个系统是宽容错误的分布式理论主从复制

master提供服务（如读/写），slave进行备份，当master发生宕机的时候从slave恢复数据。redis提供了master/slave机制，slave节点设置slaveofmaster，就建立了与master的主/从复制，master会dump当前的快照dump.rdb，同时开启增量日志功能，然后传输给slave进行数据恢复，最后进行增量日志恢复。多机热备及HA

解决单点问题。一个服务在多个节点上启动，但只有一个节点提供服务，其它节点上的应用为就绪状态，如果提供服务的节点应用宕机，从其它节点上的应用中选举一个新的应用提供服务，一般用zookeeper实现。失效宕机(fail）

节点宕机或不能提供服务了，要进行一定的处理，如集群自动检测宕机后通知其它节点，进行一些配置修改等等。失效转移(failover)

通俗地说，即当A无法为客户服务时，系统能够自动地切换，使B能够及时地顶上继续为客户提供服务，且客户感觉不到这个为他提供服务的对象已经更换。

分布式缓存理论高性能4w+tps动态扩展性:支持弹性扩展,通过动态增加或减少节点应对变化的数据访问负载,提供可预测的性能与扩展性;同时,最大限度地提高资源利用率;高可用性:可用性包含数据可用性与服务可用性两方面.基于冗余机制实现高可用性,无单点失效(singlepointoffailure),支持故障的自动发现,透明地实施故障切换,不会因服务器故障而导致缓存服务中断或数据丢失.动态扩展时自动均衡数据分区,同时保障缓存服务持续可用;分布式群集读/写，侧重解决读的问题，写存在数据一致性问题一致性Hash算法

/cywosp/article/details/23397179基于Redis的分布式缓存分布式缓存系统网络架构图基于Redis的分布式缓存分布式缓存系统架构图基于Redis的分布式缓存client负载均衡器(LVS)IP04clientIP01MonitorZookeepermdb-mastermdb-mastermdb-slavemdb-slaveListenerJdk7IP02IP03IP04MonitorZookeepermdb-mastermdb-mastermdb-slavemdb-slaveListenerMonitorZookeepermdb-mastermdb-mastermdb-slavemdb-slaveListenerJdk7Jdk7Jdk7Web控制台TomcatMysql基于Redis的分布式缓存流程基于Redis的分布式缓存Redis群集存储使用sharding(分片)一致性Hash算法群集管理及监测Zookeeper(redis配置元数据存储与群集协调)Monitor组件(监测节点状态与群集管理)Redis群集命令处理Listener(redis监听客户请求，分片，命令转发与处理)

通讯Sockect（节点通讯）Jms（命令）

业务数据批量入群集datax基于Redis的分布式缓存Sharding分片

对于海量数据的存储，原来单节点存储满足不了需求的时候就要使用多节点进行数据的存储了，sharding分片技术就是用来解决多节点存储数据的问题。使用(一致性)Hash算法分片。Memcached中使用客户端模块进行分片，本系统使用服务端的listener模块进行分片。

对于redis来说，jedis.set(key,value)操作，服务端listener模块对key进行hash，使用的是改进的FNVHash1，然后对集群中的redis大小取余得到index,再定位到真正的redis，具体如下步骤：

key=zhangsan

inthashcode=FNVHash1(key)=

1555196908intclusterSize=6redis集群数组[24,23,29,30,34,33]，那么集群大小为6intindex=1555196908%6=4

取redis的id=34[24,23,29,30,34,33][4]就可以定位到具体的redis了

基于Redis的分布式缓存Redis主/备设计

redis设计为1主1备，分开存储，同时写主/备，读主,failover时进行主/备切换，保证服务可用性。Monitor

HA

只有1个monitor进程提供服务，其它节点monitor热备，如果主宕机，由zookeeper选出新的leader进行服务，相当master，monitor作用包括加载redis节点信息，监测集群状态，更新集群状态，发送命令给ListenerListener集群部署Listener作用是监听Redis客户端请求，并进行转发与处理，写主/备，failover时redis主/备切换。Redis存储功能目前开启了rdb基于Redis的分布式缓存Zookeeper功能

1.实现多机热备。Monitor是多机热备的，3台节点都启了应用，但只有一个节点真正提供服务，如果这个提供服务的节点宕机了，通过zookeerp的leader选择出新的节点提供服务。2.集群元数据管理。元数据主要是整个集群的redis配置信息，如3台机器，每台机器上2主2备，一共12个redis进程，redis之间的主/备逻辑关系及所属的listener信息，这些元数据以json格式保存在zookeeper的baseinfo与listenerData节点上。

3.monitor提供服务过程中一些数据，如集群状态，zookeeper列表，monitor列表，listener列表，redis列表，要发送的消息等数据。基于Redis的分布式缓存Zookeeper存储基于Redis的分布式缓存Redis客户端修改了Jedis2.4.jar的通讯协议，使之适应分布式集群。

publicstaticfinalbytePOUND_BYTE=‘#’;自定义的,集群标志 publicstaticfinalb