符合中小企业对网站设计、功能常规化式的企业展示型网站建设
本套餐主要针对企业品牌型网站、中高端设计、前端互动体验...
商城网站建设因基本功能的需求不同费用上面也有很大的差别...
手机微信网站开发、微信官网、微信商城网站...
这篇文章将为大家详细讲解有关redis集群的方法,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。
创新互联是一家集网站建设,甘井子企业网站建设,甘井子品牌网站建设,网站定制,甘井子网站建设报价,网络营销,网络优化,甘井子网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。
Redis Sharding集群
Redis Sharding是一种客户端Sharding分片技术。
Redis Sharding可以说是Redis Cluster出来之前,业界普遍使用的多Redis实例集群方法。主要思想是采用哈希算法将Redis数据的key进行散列,通过hash函数,特定的key会映射到特定的Redis节点上。
这样,客户端就知道该向哪个Redis节点操作数据,需要说明的是,这是在客户端完成的。
java redis客户端jedis,已支持Redis Sharding功能,即ShardedJedis以及结合缓存池的ShardedJedisPool。Jedis的Redis Sharding实现具有如下特点:
1、采用一致性哈希算法(consistent hashing)
将key和节点name同时哈希,然后进行映射匹配,采用的算法是MURMUR_HASH。一致性哈希主要原因是当增加或减少节点时,不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配,影响量小。更多一致性哈希算法介绍,可以参考:http://blog.csdn.net/cywosp/article/details/23397179/
2、虚拟节点
ShardedJedis会对每个Redis节点,根据名字虚拟化出160个虚拟节点进行散列。用虚拟节点做映射匹配,可以在增加或减少Redis节点时,key在各Redis节点移动更分配更均匀,而不是只有相邻节点受影响。如图,Redis节点1虚拟化成NODE1-1和NODE1-2,散列中哈希环上。这样当object1、object2散列时,选取最近节点NODE1-1和NODE1-2,而NODE1-1和NODE1-2又是NODE节点的虚拟节点,即实际存储在NODE节点上。
增加虚拟节点,可以保证平衡性,即每台Redis机器,存储的数据都差不多,而不是一台机器存储的数据较多,其它的少。
3、ShardedJedis支持keyTagPattern模式
抽取key的一部分keyTag做sharding,这样通过合理命名key,可以将一组相关联的key放入同一Redis节点,避免跨节点访问。即客户端将相同规则的key值,指定存储在同一Redis节点上。
添加或减少节点时?
Redis Sharding采用客户端Sharding方式,服务端的Redis还是一个个相对独立的Redis实例节点。同时,我们也不需要增加额外的中间处理组件,这是一种非常轻量、灵活的Redis多实例集群方案。
当然,这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容,当想要增加Redis节点时,尽管采用一致性哈希,那么不同的key分布到不同的Redis节点上。
当我们需要扩容时,增加机器到分片列表中。这时候客户端根据key算出来落到跟原来不同的机器上,这样如果要取某一个值,会出现取不到的情况。
对于这一种情况,一般的作法是取不到后,直接从后端数据库重新加载数据,但有些时候,击穿缓存层,直接访问数据库层,会对系统访问造成很大压力。
Redis作者给出了一个办法--presharding。
是一种在线扩容的方法,原理是将每一台物理机上,运行多个不同端口的Redis实例,假如三个物理机,每个物理机运行三个Redis实例,那么我们的分片列表中实际有9个Redis实例,当我们需要扩容时,增加一台物理机,步骤如下:
1、在新的物理机上运行Redis-server
2、该Redis-server从属于(slaveof)分片列表中的某一Redis-Server(假设叫RedisA)。
3、主从复制(Replication)完成后,将客户端分片列表中RedisA的IP和端口改为新物理机上Redis-Server的IP和端口。
4、停止RedisA
这样相当于将某一Redis-Server转移到了一台新机器上。但还是很依赖Redis本身的复制功能,如果主库快照数据文件过大,这个复制的过程也会很久,同时也会给主Redis带来压力,所以做这个拆分的过程最好选择业务访问低峰时段进行。
节点发生故障时
并不是只有增删Redis节点引起键值丢失问题,更大的障碍来自Redis节点突然宕机。
为不影响Redis性能,尽量不开启AOF和RDB文件保存功能,因此需架构Redis主备模式,主Redis宕机,备Redis留有备份,数据不会丢失。
Sharding演变成如下:
这样,我们的架构模式变成一个Redis节点切片包含一个主Redis和一个备Redis,主备共同组成一个Redis节点,通过自动故障转移,保证了节点的高可用性.
Redis Sentinel哨兵
提供了主备模式下Redis监控、故障转移等功能,达到系统的高可用性。
读写分离
高访问时量下,即使采用Sharding分片,一个单独节点还是承担了很大的访问压力,这时我们还需要进一步分解。
通常情况下,读常常是写的数倍,这时我们可以将读写分离,读提供更多的实例数。利用主从模式实现读写分离,主负责写,从负责只读,同时一主挂多个从。在Redis Sentinel监控下,还可以保障节点故障的自动监测。
关于redis集群的方法就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。