一个Cluster包含多台（至少二台）拥有共享数据存储空间的服务器。任何一台服务器运行一个应用时，应用数据被存储在共享的数据空间内。每台服务器的操作系统和应用程序文件存储在其各自的本地储存空间上。
Cluster内各节点服务器通过一内部局域网相互通讯。当一台节点服务器发生故障时，这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。当一个应用服务发生故障时，应用服务将被重新启动或被另一台服务器接管。当以上任一故障发生时，客户将能很快连接到新的应用服务上。
集群的硬件配置
镜像服务器双机
集群中镜像服务器双机系统是硬件配置最简单和价格最低廉的解决方案，通常镜像服务的硬件配置需要两台服务器，在每台服务器有独立操作系统硬盘和数据存贮硬盘，每台服务器有与客户端相连的网卡，另有一对镜像卡或完成镜像功能的网卡。
镜像服务器具有配置简单，使用方便，价格低廉诸多优点，但由于镜像服务器需要采用网络方式镜像数据，通过镜像软件实现数据的同步，因此需要占用网络服务器的CPU及内存资源，镜像服务器的性能比单一服务器的性能要低一些。
有一些镜像服务器集群系统采用内存镜像的技术，这个技术的优点是所有的应用程序和网络操作系统在两台服务器上镜像同步，当主机出现故障时，备份机可以在几乎没有感觉的情况下接管所有应用程序。因为两个服务器的内存完全一致，但当系统应用程序带有缺陷从而导致系统宕机时，两台服务器会同步宕机。这也是内存镜像卡或网卡实现数据同步，在大数据量读写过程中两台服务器在某些状态下会产生数据不同步，因此镜像服务器适合那些预算较少、对集群系统要求不高的用户。
硬件配置范例：
网络服务器 两台
服务器操作系统硬盘 两块
服务器数据存贮硬盘 视用户需要确定
服务器镜像卡（部分软件可使用标准网卡） 两块
网络服务网卡 两块三、双机与磁盘阵列柜
与镜像服务器双机系统相比，双机与磁盘阵列柜互联结构多出了第三方生产的磁盘阵列柜，目前，豪威公司、精业公司等许多公司都生产有磁盘阵列柜，在磁盘阵列柜中安装有磁盘阵列控制卡，阵列柜可以直接将柜中的硬盘配置成为逻辑盘阵。磁盘阵列柜通过SCSI电缆与服务器上普通SCSI卡相连，系统管理员需直接在磁盘柜上配置磁盘阵列。
双机与磁盘阵列柜互联结构不采用内存镜像技术，因此需要有一定的切换时间（通常为60？D？D180秒），它可以有郊的避免由于应用程序自身的缺陷导致系统全部宕机，同时由于所有的数据全部存贮在中置的磁盘阵列柜中，当工作机出现故障时，备份机接替工作机，从磁盘阵列中读取数据，所以不会产生数据不同步的问题，由于这种方案不需要网络镜像同步，因此这种集群方案服务器的性能要比镜像服务器结构高出很多。
双机与磁盘阵列柜互联结构的缺点是在系统当中存在单点错的缺陷，所谓单点错是指当系统中某个部件或某个应用程序出现故障时，导致所有系统全部宕机。在这个系统中磁盘阵列柜是会导致单点错，当磁盘阵列柜出现逻辑或物理故障时，所有存贮的数据会全部丢失，因此，在选配这种方案时，需要选用一个品质与售后服务较好的产品。
硬件配置范例：
网络服务器 两台
服务器操作系统硬盘 两块
第三方生产的磁盘阵列柜 一台
磁盘柜专用SCSI电线 两根
磁盘阵列柜数据存贮硬盘 视用户需求确定
网络服务网卡 两块
除此之外，一些厂商还有更优秀的技术的解决方案，比如 HP.
HP双机双控容错系统
HP NetServer为双机双控容错系统提供了高品质和高可靠的硬件基础……
HP双机双控容错系统结合了HP服务器产品的安全可靠性与Cluster技术的优点，相互配合二者的优势。
硬件配置范例：
HP L系统的网络服务器 两台
服务器操作系统硬盘 两块
HP硬盘存贮柜（SS/6，RS/8，RS/12） 一台
磁盘柜专用SCSI集群适配电缆 两根
磁盘柜数据存贮硬盘 视用户需求确定
HP集群专用阵列卡 两块
网络服务网卡 两块五、HP光纤通道双机双控集群系统
光纤通道是一种连接标准，可以作为SCSI的一种替代解决方案，光纤技术具有高带宽、抗电磁干扰、传输距离远、质量高、扩展能力强等特性，目前在FC-AL仲裁环路上可接入126个设备。
光纤设备提供了多种增强的连接技术，大大方便了用户使用。服务器系统可以通过光缆远程连接，最大可跨越10公里的距离。它允许镜像配置，这样可以改善系统的容错能力。服务器系统的规模将更加灵活多变。SCSI每条通道最多可连接15个设备，而光纤仲裁环路最多可以连接126个设备。
光纤集群系统组成：
HP光纤集群系统硬件设备包括有两台HP服务器（需支持光纤卡，目前有LC2000、LH3000、LH4、 LH6000、LT6000、LXr8000、LXR8500）及光纤适配卡，可以使用RS/12FC光纤磁盘阵列柜，需另加一对或两对网卡用于心跳检测和与客户端连接。在配置过程中还需另外选配光纤卡到光纤存贮设备的光纤电缆。
硬件配置：
HPL系统的网络服务器 两台
服务器操作系统硬盘 两块
HP光纤阵列存贮柜（RS/12FC） 一台
光纤磁盘柜专用光纤电缆 两根
光纤磁盘柜数据存贮硬盘 视用户需求确定
HP光纤适配卡 两块
网络服务网卡 两块
集群的软件配置
基于NT平台的集群软件
Microsoft的MSCS，也有许多第三方的专业软件公司开发的集群软件，如豪威的DATAWARE，VIN CA公司的STANDBY SERVER，NSI公司的DOUBLE-TAKE.
MS WolfPack的特点
MS WolfPack是MS Cluster server的别称，是 微软针对Cluster技术研制开发的双机软件。它集成在NT SERVER上，支持由二台机器组成的双机系统，提供一种高可用且易管理的应用环境。
主要特点：
自动检测和修复服务器或应用程序的错误
可实现对服务器中应用程序的切换
可通过TCP/IP连接各种客户端，如MS-DOS、WINDOWS 3.X/9X/NT，Apple Macintosh、UNIX等
生产主机无需人工干涉即可自动恢复数据并接管任务
易管理性：
可自动审核服务器和应用程序的工作状态
可建立高可用性的应用程序、文件共享、打印请求等
可灵活设置应用程序和数据的恢复策略
简单操作即可进行应用程序的离线，重新再线，服务器间的迁移。
目前，WINDOWS 2000 Advanced Server与WINDOWS 2000 DataCenter Server都集成有更先进集群技术。
其它的网络操作系统平台上也有许多集群软件，比如：
基于novell平台的集群软件有Novell HA Server、Novell SFT III
基于sco UNIX平台的集群软件有Sentinel集群软件
基于Linux平台的集群软件有TurboCluster
集群技术的发展趋势
集群技术随着服务器硬件系统与网络操作系统的发展将会在可用性、高可靠性、系统冗余等方面逐步提高。未来的集群可以依靠集群文件系统实现对系统中的所有文件、设备和网络资源的全局访问，并且生成一个完整的系统映像。这样，无论应用程序在集群中的哪台服务器上，集群文件系统允许任何用户（远程或本地）都可以对这个软件进行访问。任何应用程序都可以访问这个集群任何文件。甚至在应用程序从一个节点转移到另一个节点的情况下，无需任何改动，应用程序就可以访问系统上的文件。
不难，硬件用路由器，软件嘛，操作系统用WIN2003 server enterprise 企业版，推荐一并安装R2升级包，所有机器组局域网，用一台千兆网卡做域控，架设流媒体服务器，其他机做为域成员加入进来，内网IP各用各的，外网用端口映射到一个IP，用域控做网络流量负载平衡，域控机器配置要强，如果你网络流量大，建议用专业级服务器，至强+2Gb+SCSI硬盘之类，看你环境要求了，如果必要可以上双至强，再用一台512mb内存的p4 2.0G以上机做备份域控，这样主域控上下线或重启或出故障不影响域内成员正常工作，备份域控凑合就可以了，按我上面的要求就行，当然，有钱可以用好的如果你安全性要求高，建议路由前端用普通P4+512Mb内存机器架ISA2004 server组防火墙，配置的好效果比一般的硬件防火墙要好，完全不影响网络环境运行，域内成员可以裸奔不怕毒和黑
至于域内成员机，如果仅全力供应片源，当前主流家用机型就够用了
服务器建议用hp 360G系列，目前价位不算高，性价比还不错，售后很好，如果你对建网不怎么了解，可以让他们帮你装，买他们的服务器就是要利用他们的人力资源嘛
路由器可以选用飞鱼星4200以上机型，电信网通双WAN口，是可以提供150～250台机器的大型网吧专用的，内置参数非常丰富
另外再多罗嗦几句，板卡不要买七彩虹的，我上过当，七彩虹本身是咨讯公司，没有任何板卡生产能力，都是同德代工的，以为它的出货量大，就选了它，结果广告上的指标参数和实际产品根本不同，水份太多太多了，售后也很烂，特此建议……
楼下别再抄袭我了，每天都被抄走好几个200分最佳，实在是郁闷！
通常，为了提高网站响应速度，总是把热点数据保存在内存中而不是直接从后端数据库中读取。Redis是一个很好的Cache工具。大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，在这种情况下，如何正确架构Redis呢？首先，无论我们是使用自己的物理主机，还是使用云服务主机，内存资源往往是有限制的，scale up不是一个好办法，我们需要scale out横向可伸缩扩展，这需要由多台主机协同提供服务，即分布式多个Redis实例协同运行。
其次，目前硬件资源成本降低，多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相对较小的内存高效。因此，实际使用中，通常一台机器上同时跑多个Redis实例。
方案
1.Redis官方集群方案 Redis Cluster
Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。
Redis
Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类似前面讲的pre
sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简
单，就是CRC16后16384取模。
Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个
slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实
现中，还处于半自动状态，需要人工介入。
Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。
为
了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失
效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似前篇文章提到的Redis
Sharding场景下服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。
Redis
Cluster的新节点识别能力、故障判断及故障转移能力是通过集群中的每个node都在和其它nodes进行通信，这被称为集群总线(cluster
bus)。它们使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是
16379。nodes之间的通信采用特殊的二进制协议。
对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个
node进行操作，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这
有点儿像浏览器页面的302 redirect跳转。
Redis Cluster是Redis 3.0以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。
2.Redis Sharding集群
Redis 3正式推出了官方集群技术，解决了多Redis实例协同服务问题。Redis Cluster可以说是服务端Sharding分片技术的体现，即将键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通，共同对外承担一致服务。
多Redis实例服务，比单Redis实例要复杂的多，这涉及到定位、协同、容错、扩容等技术难题。这里，我们介绍一种轻量级的客户端Redis Sharding技术。
Redis
Sharding可以说是Redis
Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定
的key会映射到特定的Redis节点上。这样，客户端就知道该向哪个Redis节点操作数据。Sharding架构如图：
庆幸的是，java redis客户端驱动jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。
Jedis的Redis Sharding实现具有如下特点：
采
用一致性哈希算法(consistent
hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类
似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。
2.
为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟
化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点
时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。
3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。
Redis Sharding采用客户端Sharding方式，服务端Redis还是一个个相对独立的Redis实例节点，没有做任何变动。同时，我们也不需要增加额外的中间处理组件，这是一种非常轻量、灵活的Redis多实例集群方法。
当然，Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性哈希，毕竟还是会有key匹配不到而丢失，这时需要键值迁移。
作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。有没有其它手段改善这种情况？
Redis
作者给出了一个比较讨巧的办法--presharding，即预先根据系统规模尽量部署好多个Redis实例，这些实例占用系统资源很小，一台物理机可部
署多个，让他们都参与sharding，当需要扩容时，选中一个实例作为主节点，新加入的Redis节点作为从节点进行数据复制。数据同步后，修改
sharding配置，让指向原实例的Shard指向新机器上扩容后的Redis节点，同时调整新Redis节点为主节点，原实例可不再使用。
presharding
是预先分配好足够的分片，扩容时只是将属于某一分片的原Redis实例替换成新的容量更大的Redis实例。参与sharding的分片没有改变，所以也
就不存在key值从一个区转移到另一个分片区的现象，只是将属于同分片区的键值从原Redis实例同步到新Redis实例。
并不是只有增
删Redis节点引起键值丢失问题，更大的障碍来自Redis节点突然宕机。在《Redis持久化》一文中已提到，为不影响Redis性能，尽量不开启
AOF和RDB文件保存功能，可架构Redis主备模式，主Redis宕机，数据不会丢失，备Redis留有备份。
这样，我们的架构模式变
成一个Redis节点切片包含一个主Redis和一个备Redis。在主Redis宕机时，备Redis接管过来，上升为主Redis，继续提供服务。主
备共同组成一个Redis节点，通过自动故障转移，保证了节点的高可用性。则Sharding架构演变成：
Redis Sentinel提供了主备模式下Redis监控、故障转移功能达到系统的高可用性。
高访问量下，即使采用Sharding分片，一个单独节点还是承担了很大的访问压力，这时我们还需要进一步分解。通常情况下，应用访问Redis读操作量和写操作量差异很大，读常常是写的数倍，这时我们可以将读写分离，而且读提供更多的实例数。
可以利用主从模式实现读写分离，主负责写，从负责只读，同时一主挂多个从。在Sentinel监控下，还可以保障节点故障的自动监测。
3.利用代理中间件实现大规模Redis集群
上面分别介绍了多Redis服务器集群的两种方式，它们是基于客户端sharding的Redis Sharding和基于服务端sharding的Redis Cluster。
客户端sharding技术其优势在于服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。其不足之处在于：
由于sharding处理放到客户端，规模进步扩大时给运维带来挑战。
服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。
连接不能共享，当应用规模增大时，资源浪费制约优化。
服务端sharding的Redis Cluster其优势在于服务端Redis集群拓扑结构变化时，客户端不需要感知，客户端像使用单Redis服务器一样使用Redis集群，运维管理也比较方便。
不过Redis Cluster正式版推出时间不长，系统稳定性、性能等都需要时间检验，尤其在大规模使用场合。
能不能结合二者优势？即能使服务端各实例彼此独立，支持线性可伸缩，同时sharding又能集中处理，方便统一管理？本篇介绍的Redis代理中间件twemproxy就是这样一种利用中间件做sharding的技术。
twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后(如sharding)，再转发给后端真正的Redis服务器。也就是说，客户端不直接访问Redis服务器，而是通过twemproxy代理中间件间接访问。
参照Redis Sharding架构，增加代理中间件的Redis集群架构如下：
twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可避免单点压力或故障。
twemproxy又叫nutcracker，起源于twitter系统中redis/memcached集群开发实践，运行效果良好，后代码奉献给开源社区。其轻量高效，采用C语言开发，工程网址是：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis
twemproxy后端不仅支持redis，同时也支持memcached，这是twitter系统具体环境造成的。
由于使用了中间件，twemproxy可以通过共享与后端系统的连接，降低客户端直接连接后端服务器的连接数量。同时，它也提供sharding功能，支持后端服务器集群水平扩展。统一运维管理也带来了方便。
当然，也是由于使用了中间件代理，相比客户端直连服务器方式，性能上会有所损耗，实测结果大约降低了20%左右。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）