一台服务器可以挂两个磁盘阵列吗？

可以的。

磁盘阵列一般有两种形式：本地raid磁盘组和插件阵列机柜。

本机raid磁盘组，通常两个磁盘组成raid1，放系统和应用程序，其他磁盘组成raid5，放数据库和其他生产数据，大多数卡可以做一个以上的阵列，虽然一台机器可以容纳一个或多个阵列卡需要，唯一的限制是案件的硬盘驱动器笼，波的低端，nas，是这种形式的。

可以在服务器上安装多个hba卡，可以通过sas，SCSI，、fc电缆连接多个具有相同端口的阵列柜。例如，西安的一个客户有一台IBMx3650m3机器。

安装了lsi的sashba卡连接ds3200sas阵列机柜，后来客户给机器增加了qlogic8gbfchba卡和v3500阵列机柜，以扩大容量。

扩展资料：

原则：

磁盘阵列作为独立系统或通过网络直接连接到主机外部的主机。磁盘阵列有多个端口，可以连接到不同的主机或端口。主机连接阵列中的不同端口可以提高传输速度。

正如PC机使用单磁盘内部集成缓存一样，在磁盘阵列中为了加快与主机的交互，存在一定数量的缓冲内存。主机与磁盘阵列的缓存进行交互，而缓存与特定磁盘的数据进行交互。

在应用程序，一些常见的数据通常需要阅读，根据内部磁盘阵列算法，找出这些经常读取数据，存储在缓存中，加快主机读取数据的速度，没有其他的缓存数据，主机读取，通过直接从磁盘读取数组传递给主机。

服务器集群：
服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。
服务器负载均衡：
负载均衡
（Load
Balancing）
建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
分布式服务器：
所谓分布式资源共享服务器就是指数据和程序可以不位于一个服务器上，而是分散到多个服务器，以网络上分散分布的地理信息数据及受其影响的数据库 *** 作为研究对象的一种理论计算模型服务器形式。分布式有利于任务在整个计算机系统上进行分配与优化，克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷，解决了网络GIS
中存在的数据异构、数据共享、运算复杂等问题，是地理信息系统技术的一大进步。
这个三种架构都是常见的服务器架构，集群的主要是IT公司在做，可以保障重要数据安全；负载均衡主要是为了分担访问量，避免临时的网络堵塞，主要用于电子商务类型的网站；分布式服务器主要是解决跨区域，多个单个节点达到高速访问的目前，一般是类似CDN的用途的话，会采用分布式服务器。
纯手工打字，希望可以帮的到你！

   由于Redis Cluster（集群）采用哈希分区规则，所以先介绍下常见的哈希分区规则。常见的哈希规则： 节点取余分区规则、一致性哈希分区（Consistent hashing）、虚拟槽（Virtual slot）分区。

   使用特定的数据，如Redis的键或用户ID，再根据节点（运行在集群模式下的Redis服务器）的数量N使用公式：hash(key) % N计算出hash值，用来决定数据存储在哪个节点上。例如，将20个数据存储在4个节点上：

  一致性哈希分区实现思路是为系统中的每个节点分配一个token，范围是0~2 32 -1，这些token构成一个哈希环。数据读写执行节点查找 *** 作时，先根据key计算出哈希值，然后顺时针找到第一个遇到的token节点。

  一致性哈希分区的缺点：

   Redis Cluster采用的就是虚拟槽分区。 虚拟槽分区巧妙的使用了哈希空间，使用分散度良好的哈希函数将所有的数据映射到一个固定范围的整数集合中，整数定义为槽（slot）。这个范围一般远远大于节点数，这是为了消除哈希的倾斜性，便于数据拆分和扩展。例如Redis Cluster槽的范围是0~16383。槽是集群内数据管理和迁移的基本单位，每个节点都会负责一定数量的槽。
  如在Redis中，假设有5个节点，每个节点平均负责3276个槽。

  (1) 常见的哈希分区规则有：节点取余分区、一致性哈希分区和虚拟槽分区。
  (2) Redis Cluster数据分区规则采用虚拟槽方式，所有的键映射到16384个槽中，每个节点负责一部分槽和相关数据，实现数据和请求的负载均衡。
   本文完

  注：本文参考《Redis开发与运维》，如发现错误，请指正！

Kafka在⼀定数量的服务器上对主题分区进⾏复制。
当集群中的⼀个broker宕机后系统可以⾃动故障转移到其他可⽤的副本上，不会造成数据丢失。
--replication-factor 3 1leader+2follower

Follower分区像普通的Kafka消费者⼀样，消费来⾃Leader分区的消息，并将其持久化到⾃⼰的⽇志中。
允许Follower对⽇志条⽬拉取进⾏批处理。
同步节点定义：

下图中
分区P1的Leader是0，ISR是0和1
分区P2的Leader是2，ISR是1和2
分区P3的Leader是1，ISR是0，1，2。

⽣产者和消费者的请求都由Leader副本来处理。Follower副本只负责消费Leader副本的数据和Leader保持同步。
对于P1，如果0宕机会发⽣什么？
Leader副本和Follower副本之间的关系并不是固定不变的，在Leader所在的broker发⽣故障的时候，就需要进⾏
分区的Leader副本和Follower副本之间的切换，需要选举Leader副本。
如何选举？
如果某个分区所在的服务器除了问题，不可⽤，kafka会从该分区的其他的副本中选择⼀个作为新的Leader。之后
所有的读写就会转移到这个新的Leader上。现在的问题是应当选择哪个作为新的Leader。
只有那些跟Leader保持同步的Follower才应该被选作新的Leader。
Kafka会在Zookeeper上针对每个Topic维护⼀个称为ISR（in-sync replica，已同步的副本）的集合，该集合中是
⼀些分区的副本。
只有当这些副本都跟Leader中的副本同步了之后，kafka才会认为消息已提交，并反馈给消息的⽣产者。
如果这个集合有增减，kafka会更新zookeeper上的记录。
如果某个分区的Leader不可⽤，Kafka就会从ISR集合中选择⼀个副本作为新的Leader。
显然通过ISR，kafka需要的冗余度较低，可以容忍的失败数⽐较⾼。
假设某个topic有N+1个副本，kafka可以容忍N个服务器不可⽤。
为什么不⽤少数服从多数的⽅法
少数服从多数是⼀种⽐较常⻅的⼀致性算发和Leader选举法。
它的含义是只有超过半数的副本同步了，系统才会认为数据已同步；
选择Leader时也是从超过半数的同步的副本中选择。
这种算法需要较⾼的冗余度，跟Kafka⽐起来，浪费资源。
譬如只允许⼀台机器失败，需要有三个副本；⽽如果只容忍两台机器失败，则需要五个副本。
⽽kafka的ISR集合⽅法，分别只需要两个和三个副本。
如果所有的ISR副本都失败了怎么办？
此时有两种⽅法可选，

向已经部署好的Kafka集群⾥⾯添加机器，我们需要从已经部署好的Kafka节点中复制相应的配置⽂件，然后把⾥
⾯的broker id修改成全局唯⼀的，最后启动这个节点即可将它加⼊到现有Kafka集群中。
问题：新添加的Kafka节点并不会⾃动地分配数据，⽆法分担集群的负载，除⾮我们新建⼀个topic。
需要⼿动将部分分区移到新添加的Kafka节点上，Kafka内部提供了相关的⼯具来重新分布某个topic的分区。
在重新分布topic分区之前，我们先来看看现在topic的各个分区的分布位置：

在node11搭建Kafka：
拷⻉JDK并安装

此处不需要zookeeper，切记！！！

让配置⽣效：
/etc/profile
拷⻉node1上安装的Kafka

修改node11上Kafka的配置：

启动Kafka：

注意观察node11上节点启动的时候的ClusterId，看和zookeeper节点上的ClusterId是否⼀致，如果是，证明node11和node1在同⼀个集群中。
node11启动的Cluster ID：

zookeeper节点上的Cluster ID：

然后使⽤ kafka-reassign-partitionssh ⼯具⽣成reassign plan

Proposed partition reassignment configuration下⾯⽣成的就是将分区重新分布到broker 1上的结果。我们将这些内容保存到名为resultjson⽂件⾥⾯（⽂件名不重要，⽂件格式也不⼀定要以json为结尾，只要保证内容是json即可），然后执⾏这些reassign plan：

执⾏计划：

这样Kafka就在执⾏reassign plan，我们可以校验reassign plan是否执⾏完成：

查看主题的细节：

分区的分布的确和 *** 作之前不⼀样了，broker 1上已经有分区分布上去了。使⽤ kafka-reassign�partitionssh ⼯具⽣成的reassign plan只是⼀个建议，⽅便⼤家⽽已。其实我们⾃⼰完全可以编辑⼀个reassignplan，然后执⾏它，如下：

将上⾯的json数据⽂件保存到my-topics-to-executejson⽂件中，然后也是执⾏它：

等这个reassign plan执⾏完，我们再来看看分区的分布：

我们可以在新建主题的时候，⼿动指定主题各个Leader分区以及Follower分区的分配情况，即什么分区副本在哪
个broker节点上。
随着系统的运⾏，broker的宕机重启，会引发Leader分区和Follower分区的⻆⾊转换，最后可能Leader⼤部分都
集中在少数⼏台broker上，由于Leader负责客户端的读写 *** 作，此时集中Leader分区的少数⼏台服务器的⽹络I/O，
CPU，以及内存都会很紧张。
Leader和Follower的⻆⾊转换会引起Leader副本在集群中分布的不均衡，此时我们需要⼀种⼿段，让Leader的分
布重新恢复到⼀个均衡的状态。
执⾏脚本：

上述脚本执⾏的结果是：创建了主题tp_demo_03，有三个分区，每个分区两个副本，Leader副本在列表中第⼀个指定的brokerId上，Follower副本在随后指定的brokerId上。

然后模拟broker0宕机的情况：

是否有⼀种⽅式，可以让Kafka⾃动帮我们进⾏修改？改为初始的副本分配？
此时，⽤到了Kafka提供的⾃动再均衡脚本： kafka-preferred-replica-electionsh
先看介绍：

该⼯具会让每个分区的Leader副本分配在合适的位置，让Leader分区和Follower分区在服务器之间均衡分配。
如果该脚本仅指定zookeeper地址，则会对集群中所有的主题进⾏ *** 作，⾃动再平衡。
具体 *** 作：

执⾏ *** 作：

查看 *** 作的结果：

恢复到最初的分配情况。
之所以是这样的分配，是因为我们在创建主题的时候：

在逗号分割的每个数值对中排在前⾯的是Leader分区，后⾯的是副本分区。那么所谓的preferred replica，就是排在前⾯的数字就是Leader副本应该在的brokerId。

实际项目中，我们可能由于主题的副本因子设置的问题，需要重新设置副本因子。
或者由于集群的扩展，需要重新设置副本因子。
topic⼀旦使用又不能轻易删除重建，因此动态增加副本因子就成为最终的选择。

说明：kafka 10版本配置⽂件默认没有defaultreplicationfactor=x， 因此如果创建topic时，不指定–replication-factor 想， 默认副本因⼦为1 我们可以在⾃⼰的 serverproperties 中配置上常⽤的副本因⼦，省去⼿动调整。例如设置defaultreplicationfactor=3， 详细内容可参考官⽅⽂档 >磁盘分区是用分区编辑器在磁盘上划分几个逻辑部分。 一旦磁盘被分成几个分区，不同种类的目录和文件可以存储在不同的分区。分区越多，异地越多，可以更精细的区分文件的性质，存放在不同的地方，按照更细分的性质来管理文件；但是太多的分区会成为一个问题。空间管理、访问权限和目录搜索的方式取决于安装在分区上的文件系统。当更改大小的能力取决于分区上安装的文件系统时，需要仔细考虑分区的大小。硬盘分区本质上是硬盘的一种格式，然后你就可以用硬盘保存各种信息了。创建分区时，硬盘的物理参数已经设置好，主引导记录(MBR)和引导记录备份的存储位置也已经指定。对于文件系统和其他 *** 作系统，管理硬盘所需的信息是通过高级格式，即format命令来实现的。事实上，您可以只创建一个分区，并使用全部或部分硬盘空间。但无论分多少个分区，无论使用SCSI硬盘还是IDE硬盘，都必须将硬盘的主分区设置为活动分区，才能通过硬盘启动系统。

一个硬盘最多只能划分为4个主分区，或者是3个主分区加上一个扩展分区。

这是因为在硬盘的开头，也就是0磁头（head）、0柱（cyliner）、0面（side）、0磁道（track）、0扇区（sector）总共512字节存放着硬盘最重要的信息MBR（Master
 Boot Record，主引导记录）和分区的相关信息，由于记录空间只有那么大，所以也只能记录这4个分区的信息。

mbr 格式限制 主分区+逻辑分区 <=4，1个逻辑分区可分成若干逻辑分区 <=4，gpt 格式磁盘基本无限制。

其实完全可以只创建一个分区使用全部或部分的硬盘空间。但不论划分了多少个分区，也不论使用的是SCSI硬盘还是IDE硬盘，必须把硬盘的主分区设定为活动分区，才能够通过硬盘启动系统。

扩展资料：

硬盘分区之后，会形成3种形式的分区状态；即主分区、扩展分区和非DOS分区。
DOS分区
在硬盘中非DOS分区(Non-DOS Partition)是一种特殊的分区形式，它是将硬盘中的一块区域单独划分出来供另一个 *** 作系统使用，对主分区的 *** 作系统来讲，是一块被划分出去的存储空间。只有非DOS分区的 *** 作系统才能管理和使用这块存储区域。
主分区
主分区则是一个比较单纯的分区，通常位于硬盘的最前面一块区域中，构成逻辑C磁盘。其中的主引导程序是它的一部分，此段程序主要用于检测硬盘分区的正确性，并确定活动分区，负责把引导权移交给活动分区的DOS或其他 *** 作系统。此段程序损坏将无法从硬盘引导，但从软区或光区之后可对硬盘进行读写。
扩展分区
而扩展分区的概念是比较复杂的，极容易造成硬盘分区与逻辑磁盘混淆；分区表的第四个字节为分区类型值，正常的可引导的大于32mb的基本DOS分区值为06，扩展的DOS分区值是05。如果把基本DOS分区类型改为05则无法启动系统 ，并且不能读写其中的数据。
如果把06改为DOS不识别的类型如efh，则DOS认为该分区不是DOS分区，当然无法读写。很多人利用此类型值实现单个分区的加密技术，恢复原来的正确类型值即可使该分区恢复正常。

参考资料：

中关村网-硬盘分区时最多能划分几个主分区

---