如何理解集群自有好处在？
许多以浮游生物或小型无脊椎动物或其他小型鱼类为食而又生活在较靠外海区域的鱼类，往往有大规模集群现象。白天它们像结构严密的集团军到处游动，群里的所有成员都几乎以同样的速度，彼此间保持着大致同样的间隔距离，并沿着同一个方向向前运动，说快都快，说慢都慢，说拐弯都一起拐弯，就像是一条鱼一样，步调那么一致。有些鱼是为了繁衍后代而集群，也有些鱼为了洄游，或游向产卵场或游向越冬场，而集结在一起，成千上万条甚至上百万条鱼浩浩荡荡向前挺进。有人在北海见到一个鲱鱼的大群，在海面前后延伸有15～17千米长，5千米宽，简直像鱼的海洋。鱼群中每个成员所处的位置时时都在变。它们没有固定的领头鱼。如果突然改变了方向，就往往使后军或侧军作前军，原来的前军就成为侧军或后军。在群的边缘上的成员趋于向中心移动，另一部分成员就会暴露在边缘上。渔民在围捕鲐鱼时往往就利用鱼的这一习性，发现鱼群后立即下网然后分乘小艇用石头去拦截鱼，只要往鱼群前方丢一块石头，鱼群就立即转向，这样就会逐渐把鱼群赶进网口里。群鱼集群鱼的眼睛往往有一个广角视野，特别在侧面视野很宽，这有利于它瞻前顾后、左右照顾。除视觉获得的信息外，它还有一个敏感的侧线器官，能根据水流的微妙变化探知群中相邻成员的游速和方向。鱼类的胸鳍主要用于运动中的平衡、制动和转向等，而群游鱼的胸鳍是相对固定、不大活动的，所以每个成员都不能依靠胸鳍使自己停步不前或节节后退或周围徘徊。只能向前游，就像是往前走动的一大群人的情况一样，群体中的任何一个人想中途停留或转身回走都是困难的，只能顺着大流往前走。鱼群中的鱼只有游泳的空间而无彼此间转向的空间，任何一条鱼想不和其他鱼冲突而任意绕圈子是不可能的。群鱼狂舞鱼群对群中的成员有一定的保护作用。捕食者一般都较它的猎物体魄大、游速快，若是不在群中而是单独行动，被捕食者碰到，往往很难幸免。若一个大群碰到捕食者，往往会使它有老虎啃天不知如何下口之势。当鱼群和一个捕食者遭遇时，立即分成两半，避开捕食者，在其两侧远远地绕过去，到其后方重新汇合。若捕食者转回来，鱼群以同样的方式重复。若一个大型的捕食者在未被发觉的情况下突然冲入鱼群，鱼群就会像爆炸一样，都以最大速度朝不同方向游开，给捕食者前面留下一个空荡荡的水面。小型鱼在适当刺激条件下，可以在1／20秒的时间内达到它的最大游速。即使在这种虎口逃生的情况下，也从未发现有不同个体间互相碰撞的现象，就像是每条鱼都有某种感觉知道它的邻居受到攻击时将往哪里跑一样。即使捕食者能在鱼群中捕到鱼吃，位于群中的个体被捕食的几率要比其单个行动时低得多。若一条凶猛的鱼一次吃10条鱼就饱，遇到一个上万条鱼组成的大群，每条鱼被捕食的几率只有1／1000，鱼群越大，几率就越低。有些大洋型洄游鱼类如金枪鱼也集结成群，主要是为了繁殖，而不是为了预防更大的捕食者，因为它几乎再无比它大的敌害，而且当遇到猎物群时，结集成群也有利于每个成员吃饱肚子。金枪鱼群在捕食时表现出极强的合作精神，当它们遇到要捕食的鱼群时，立即分成两队以抛物线形从两侧包抄过去，把鱼群围在当中，以瓮中捉鳖之势，从容捕食。有些草食性珊瑚礁鱼类集群的目的也是为了取食，当它们闯进某些鱼的控制范围去觅食时，必然遭到领主的驱赶。但领主不可能同时把整群鱼都赶走，当它赶那边一些鱼时，这边一些鱼就抓紧时间吃，再回来赶这边一些鱼时，被赶走的鱼又回来吃。
集群的关系
1.中国几种数字集群技术中国主要应用的几种数字集群技术包括欧洲的TETRA，美国的iDEN，以及国内自主知识产权的GoTa和GT800。（1）TETRATETRA是由欧洲电信标准协会（ETSI）推荐的标准。TETRA系统是一个空中接口信令开放的系统，并大量借鉴了GSM的概念。它基于TDMA方式，在25kb/s带宽内分4个信道，采用较先进的ACELP语音编码方式和（π/4）QPSK数字调制技术。它支持连续覆盖和大区覆盖，并且支持脱网直通和端到端加密功能。TETRA系统在调度功能上是比较完善的，所以它非常适合做专网，尤其是军队、武警、公检法等单位。（2）iDENiDEN是由摩托罗拉公司推出的，它也采用TDMA制式，在25kHz的信道上分6个时隙（已经开发出25kHz带宽上分成12个时隙）。它的VSELP语音编码和16QAM调制技术都比较先进。iDEN系统的起源设计就是作共网用的，所以它是集指挥调度、双工互连、分组数据和短消息于一体的工作方式。iDEN系统是以调度为主的，又是根据公网考虑设计的系统，所以它的基本调度系统功能包括：组呼通话、私密通话、通话提示、来电显示。调度的先进功能包括：优先级、紧急呼叫、状态信息、多组扫描、区域限制、孤立站运行、调度台等。iDEN系统也有虚拟网功能，通过虚拟专网（VPN），最终用户可以管理其终端用户的终端配置，包括开户，增加新业务，更改调度私密号、组号、电话号码，重新编组以及随时取得详细通话清单和使用统计等。（3）GoTaGoTa（全球开放式集群架构）是由中兴公司自主研发，基于CDMA1X技术面向新技术演进的数字集群通信系统，目标是满足共网集群需要，兼顾专网集群应用。GoTa系统基于CDMA多址方式，它采用16QAM和QPSK的调制方式和QCELP语音编码技术，频分双工，上下行各1.25MHz带宽，间隔45MHz。GoTa的空中接口在cdma2000技术基础上进行了优化和改造，核心网采用独立的分组数据域，基于A8/A9和A10/A11标准接口，可以公开并标准化。GoTa具有一定的技术优势，解决了基于CDMA技术实现集群业务的关键技术。在处理通信连接时也采用了共享的方式，减少网络处理呼叫的时延。GoTa具有快速接入、高信道效率和频谱使用率、较高的用户私密性、易扩展和支持业务种类多等技术优点。在GoTa系统的设计中充分考虑了数字集群通信共网的特点，面向移动运营商开发设计，充分考虑了移动商务用户的需求，可以用一部终端将集群调度业务、普通语音业务、分组数据业务、众多增值业务（短信、定位）等多种通信服务集成于一个网络中。GoTa系统的灵活性高、性价比优异和功能全面等特征，为运营商开辟出更多的赢利空间。（4）GT800GT800系统是由华为公司研发的基于GSM技术的数字集群系统。GT800是基于GPRS和GSMR技术开发的系统，其第二阶段将与TD-SCDMA技术结合。华为公司研发GT800系统是面向国内数字集群市场需求，参考现有数字集群系统的业务特性，尤其是在快速呼叫、群组业务、优先级控制、安全保密、故障弱化方面进行了大量工作，可提供满足国内专业移动通信需求的完整集群调度业务。同时，为满足用户对高速数据业务的需求，GT800通过GPRS技术，实现可变速率的数据传输功能。GT800的第二阶段通过引入TD-SCDMA，进一步提供最高速率为2Mb/s的数据业务。GT800可以提供广泛的业务，包括基本通话、短信、集群调度、优先级抢占、快速接续以及基于位置的路由等，同时还提供基于GPRS的数据业务。GT800适合集群通信的共网运营，也适合民航、铁道、水利、市政、交通、建筑、抢险救灾、矿区等专业部门自建专网。2.3G网络的PoC业务 3G网络的PoC业务标准主要由OMA来制定，并基于3GPP和3GPP2的IMS网络架构。（1）PoC业务概念和业务特征PoC是一种双向、即时、多方通信方式，允许用户与一个或多个用户进行通信。该业务类似移动对讲业务——用户按键与某个用户通话或广播到一个群组的参与者那里，接收方收听到这个发言声音后，可以没有任何动作，例如不应答这个呼叫，或者在听到发送方声音之前，被通知并且必须接收该呼叫。在该初始语音完成后，其他参与者可以响应该语音消息。PoC通信是半双工的，每次最多只能有一个人发言，其他人接听。PoC的业务特性包括：●PoC群组可以是预先定义的，也可以是临时建立（Adhoc）方式的，或者类似聊天室的方式，用户自行加入聊天组。●用户通过请求发言权实现发言，发言权的控制有一套严格控制机制。●发言权由PoC业务实体授予，如果在一段时间（业务提供商设置）之后用户没有发言，发言权将会超时而失效。●PoC业务实体可以在其他被叫用户接受会话邀请之前，先给发起用户发送指示，如果没有用户接收到媒体流，PoC参与者可以获得提示。●PoC可以与互联网现有类似语音性质的业务进行交互，如在线游戏，包括音频功能的即时消息等。在PoC体系结构中，对用户的发言权控制是非常重要的概念。发言权控制主要是在用户平面来完成，基于RTP/RTCP，同时OMA又定义了RTCP的一种APP应用，称为TBCP协议，从而实现了PoC媒体流的分发和发言权的控制。对于会话的信令控制主要是应用SIP/SDP，实现SIP注册、路由和安全方面的管理，从而保证PoC会话的完成。（2）IMS对PoC的支持I MS对PoC的支持主要实现在PoC业务的注册和安全、SIP信令路由、SIP信令压缩、地址解析、对标识隐藏的管理以及计费等功能。在IMS的注册中，首先用户建立PDP上下文，通过GPRS请求或者DNS解析过程发现IMS中的P-CSCF。P-CSCF把注册请求转发给I-CSCF，通过I-CSCF问询HSS而找到S-CSCF。在S-CSCF中实现注册过程。在这个过程中PoC用户和S-CSCF通过AKA算法实现双方的认证和鉴权。当用户注册和鉴权成功后，PoC用户可以发起组呼请求。在会话邀请的SIP消息头Contact的Tag中添加“+g.poc.talkburst”或者“+g.poc.groupad”，从而标明这是一个PoC群组会话。P-CSCF把呼叫邀请转发给I-CSCF，问询归属的S-CSCF的地址，从而把邀请转发给S-CSCF。S-CSCF通过从HSS下载的iFC（初始过虑规则），根据业务触发点，把会话邀请转交给响应的PoCserver。PoCserver进行会话控制，并通过IMS把会话邀请转发给组内其他用户，在经过媒体授权和协商后，组呼可以建立。PoC业务的计费基于IMS的计费框架，可以根据事件计费、组会话计费、发言计费等。另外PoC业务还应用了IMS中的SIP信令压缩功能，信令压缩是为了节约链路资源，减少延时，在PoCClient和P-CSCF上实现SIP信令的压缩和解压缩。同时IMS还支持对其他用户或部分用户实现用户标识隐藏。另外，在IMS中考虑到PoC会话媒体承载响应时间和媒体QoS平衡，使用了SIP信令的QoS等级。 1.技术差异数字集群要求前后向资源共享，即在一个小区覆盖范围内所有同组集群用户共同占用一个无线和有线信道。一个信道承载的用户数对于集群手机数量是没有限制的，这样可以极大的增加资源的承载能力。单信道资源情况下，理论上可以支持无穷多个集群手机进行调度。而PoC中每一个用户要占用独立的无线和有线资源，也就意味着资源占用在业务实现时有多少用户进入组呼，就要占用多少信道资源，对于PTT来说要成倍地增加资源占用。如果只有一个无线信道，则PoC业务就不能提供，至少要提供2个无线信道才能保证一对一的PoC呼叫。2.关键指标差异数字集群和PoC最根本的差异就是其关键指标——接续时延的差异。PoC的接续时间一般都在2-3秒以上，有时候甚至达到10秒以上，如果用户较多、使用频率增加或网络信号较差，接续时间会更长。而数字集群的接续时间都被控制在1秒或者更短的时间之内，这也是数字集群一直没有被移动公网所取代的根本原因，也是其核心的竞争力。国外几种数字集群网络的时延指标都在1秒之内，一般的组建立时延400ms～700ms、PTT<300ms，一般一次组呼建立和维持时间分布在5-12s即结束，而PoC基本不能满足这种要求。3.市场定位不同数字集群的市场定位分为两种：一是专业用户市场，二是公众用户市场。专业的数字集群用户一般估计为移动用户的10%左右，按照中国3亿移动用户估算，也有3000万用户的数字集群市场空间。PoC业务面对的主要是个人用户，主导的语音和综合业务是其创造收入的主要来源，而语音和综合业务也是目前全球移动运营商面对竞争压力最大的业务。4.利润率不同首先，数字集群由于服务对象以政府、单位等集团客户为主，对于价格不是十分敏感；其次，专业的集群调度业务所产生的任何收入都是在几乎没有竞争下产生的，同时调度业务主要在网内实现，不存在网间结算成本；另外由于专业需要，产品的可取代性很低，这些用户的忠诚度很高，离网率很低，这些都为数字集群运营商节约一定的运营成本。而基于移动公网的PoC业务与运营商其他业务相比基本上都是雷同的，具有可取代的特点，所以PoC业务的经营活动和产品都面临市场的有力竞争，产品、业务价格不断下降，利润率不高，结算成本也占据了很大的比例，这些直接导致了产品、业务定价时必须考虑的承受底线。5.覆盖重点不同数字集群客户主要以工作为主，需要在工作区域进行有效覆盖，比如市区室外覆盖、工作区域的重点区域覆盖，同时对于农村等偏远区域集群用户基本上没有覆盖需要，数字集群的这种简单覆盖要求完全可以利用成熟的无线通信手段予以满足，比如所有的基站都支持大区制建网，这样就在很大程度上节约了系统投资，对于局部重点区域的覆盖手段也很成熟，如政府大楼，工厂总部等等，只需要较低的成本就能满足覆盖要求。对于突发情况带来的调度需求，通过孤立站运行和脱网直通就可以满足需要，但是这种情况比例极低。对于PoC业务来说由于用户的移动性很大，分布很广，可以说凡是有人存在的地方都需要进行覆盖，所以要求大量的网络投入，即使仅仅考虑基本的覆盖，粗略估计至少也是数字集群网络的2-4倍覆盖投入。6.容量需求不同根据市场占有率的分析，即使按照10%的比例进行考虑，足以说明数字集群对容量的要求不高，所以在建设数字集群网络初期的时候根本不必考虑容量的压力，可以理解为在容量上数字集群系统只需要移动公网10%的容量资源，就可以正常运行并满足数字集群用户的容量要求，这对于建设一个数字集群网来说无疑是一大优势。而对于PoC业务来说，为了保证容量需求，移动运营商不得不使用小区制规划建网，通过降低基站发射功率，下调俯仰角，降低基站天线高度等方式，增加基站密度，提高区域用户容量。
Redis Cluster集群
redis的搭建可以查看我的上一篇文章： http://www.jianshu.com/p/6356356abebb 搭建redis cluster环境最少需要3个主节点，这里参考官网的示例创建6个节点，其中为3个主节点，3从节点，对应的redis节点IP和端口如下： 下面是一个最少选项的集群的配置文件 创建一个新的目录， 并创建六个以端口号为名字的子目录， 稍后我们在将每个目录中运行一个 Redis 实例： 命令如下: 在文件夹 7000 至 7005 中， 各创建一个 redis.conf 文件， 文件的内容可以使用上面的示例配置文件， 但记得将配置中的端口号和nodes.conf（同一服务器相同名字有冲突）从 7000 改为与文件夹名字相同的号码。 启动cluster实例 实例打印的日志显示， 因为 nodes.conf 文件不存在， 所以每个节点都为它自身指定了一个新的 ID ： 实例会一直使用同一个 ID ， 从而在集群中保持一个独一无二（unique）的名字. 进入redis目录，用如下命令创建集群。 安装ruby即可 缺少rubygems组件，使用yum安装 提示不能加载redis，是因为缺少redis和ruby的接口，使用gem 安装 在执行集群命令 至此集群模式搭建完成。 使用redis-cli命令进入集群环境，进入集群模式需要带上 -c ，不带则表示进入7000端口的普通redis。 集群 节点 槽(slot) 键 参考地址： https://redis.io/topics/cluster-tutorial
Redis-Cluster集群
在哨兵模式中，仍然只有一个 master 节点。当并发写请求较大时，哨兵模式并不能缓解写压力。 在redis-cluster集群中，每一个主节点可以添加多个从节点，主节点和从节点遵循主从模式的特性。 当用户需要处理更多的读请求时，添加从节点可以扩展系统的读性能。 redis集群的主节点内置了类似Sentinel的节点故障检测和自动故障转移功能。当集群中的某个主节点下线时，集群中的其他在线主节点发现了以后，会对已下线的主节点进行故障转移。集群进行故障转移的方法和Sentient进行故障转移的方法基本一致，不同的是，在集群里面，故障转移是由集群中其他在线的主节点负责进行的，所以集群中不需要使用Sentinel。 redis-cluster集群将键存储空间分割为16384个槽位(slot)，事实上集群最大节点数量是16384个【官方建议最大节点数量不超过1000个节点】。 所有主节点都负责16384个哈希槽中的一部分，当16384个槽都有某个节点在负责处理时，集群进入上线状态，并开始处理客户端发送的数据命令请求。 一个slot槽位可以存放多个数据，key的槽位计算公式：HASH_SLOT = CRC16(key) mod 16384 由于Redis集群无中心节点，请求会随机发给任意主节点。 主节点只会处理自己负责槽位的命令请求，其他槽位的命令请求，该主节点会返回客户端一个转向错误。 客户端根据错误中包含的地址和端口重新向正确的负责的主节点发起命令请求。 系统：CentOS7 Redis: 5.0.9 Redis节点 注意： 配置文件主要修改： 执行结果 按照之前的配置修改并启动，使用以下命令将其加入集群： 添加完新节点后，需要对新添加的主节点进行hash槽重新分配，这样该主节点才能存储数据，redis共有16384个槽。 删除从节点192.168.164.13:7000，node_id:cb21c351b3d2378976bf7d215553d0e04d7fad43 执行结果 存在slot的主节点无法直接删除，所以我们需要先移动主节点192.168.164.13:7001的slot至其他三个主节点 查看集群节点信息 删除主节点 执行结果 查看集群信息
Redis Cluster集群的搭建
搭建集群工作需要以下三个步骤：
1）准备节点。
2）节点握手。
3）分配槽。
Redis集群一般由多个节点组成，节点数量至少为6个才能保证组成完整高可用的集群。每个节点需要开启配置cluster-enabled yes，让Redis运行在集群模式下。建议为集群内所有节点统一目录，一般划分三个目录：conf、data、log，分别存放配置、数据和日志相关文件。把6个节点配置统一放在conf目录下，集群相关配置如下：
其他配置和单机模式一致即可，配置文件命名规则redis-{port}.conf，准备好配置后启动所有节点。
Cluster集群启动过程如下图：
每个节点目前只能识别出自己的节点信息，可以执行cluster nodes命令获取集群节点状
态。
节点握手是指一批运行在集群模式下的节点通过Gossip协议彼此通信，达到感知对方的过程。节点握手是集群彼此通信的第一步，由客户端发起命令：cluster meet{ip}{port}
cluster meet命令是一个异步命令，执行之后立刻返回。内部发起与目标节点进行握手通信，握手通信过程：
1）节点6379本地创建6380节点信息对象，并发送meet消息。
2）节点6380接受到meet消息后，保存6379节点信息并回复pong消息。
3）之后节点6379和6380彼此定期通过ping/pong消息进行正常的节点通
信。
分别执行meet命令让其他节点加入到集群中，
最后执行cluster nodes命令确认6个节点都彼此感知并组成集群。
节点建立握手之后集群还不能正常工作，这时集群处于下线状态，所有的数据读写都被禁止，通过cluster info命令可以获取集群当前状态。
Redis集群把所有的数据映射到16384个槽中。每个key会映射为一个固定的槽，只有当节点分配了槽，才能响应和这些槽关联的键命令。通过cluster addslots命令为节点分配槽。这里利用bash特性批量设置槽（slots），命令如下：
执行cluster info查看集群状态，如下所示：
当前集群状态是OK，集群进入在线状态。所有的槽都已经分配给节点，执行cluster nodes命令可以看到节点和槽的分配关系：
集群模式下，Reids节点角色分为主节点和从节点。首次启动的节点和被分配槽的节点都是主节点，从节点负责复制主节点槽信息和相关的数据。使用cluster replicate{nodeId}命令让一个节点成为从节点。其中命令执行必须在对应的从节点上执行，nodeId是要复制主节点的节点ID，命令如下：
Redis集群模式下的主从复制使用了之前介绍的Redis复制流程，依然支持全量和部分复制。复制（replication）完成后，整个集群的结构如图：
集群搭建需要很多步骤当集群节点众多时，必然会加大搭建集群的复杂度和运维成本。因此Redis官方提供了redis-trib.rb工具方便我们快速搭建集群。
redis-trib.rb是采用Ruby实现的Redis集群管理工具。内部通过Cluster相关命令帮我们简化集群创建、检查、槽迁移和均衡等常见运维操作，使用之前需要安装Ruby依赖环境。
1、安装Ruby：
2、安装rubygem redis依赖：
3、安装redis-trib.rb：
4、安装完Ruby环境后，执行redis-trib.rb命令确认环境是否正确，输出如
下：
首先我们跟之前内容一样准备好节点配置并启动：
启动好6个节点之后，使用redis-trib.rb create命令完成节点握手和槽分配过程，命令如下：
--replicas参数指定集群中每个主节点配备几个从节点，这里设置为1。
如果部署节点使用不同的IP地址，redis-trib.rb会尽可能保证主从节点不分配在同一机器下，因此会重新排序节点列表顺序。节点列表顺序用于确定主从角色，先主节点之后是从节点。创建过程中首先会给出主从节点角色分配的计划，当我们同意这份计划之后输入yes，redis-trib.rb开始执行节点握手和槽分配操作。
集群完整性指所有的槽都分配到存活的主节点上，只要16384个槽中有一个没有分配给节点则表示集群不完整。可以使用redis-trib.rb check命令检测之前创建的集群是否成功，check命令只需要给出集群中任意一个节点地址就可以完成整个集群的检查工作，命令如下：
