联系人：张生
手机：11602851401
电话：400-123-4657
传真：+86-123-4567
E-mail:admin@youweb.com
Q Q：1234567890
地址：黑龙江省哈尔滨市庐江县超来大楼42号
有状态服务后台服务可以划分为两类，有状态和无状态。高可用对于无状态的应用来说是比力简朴的，无状态的应用，只需要通过F5或者任何署理的方式就可以很好的解决。
后文形貌的主要是针对有状态的服务举行分析。服务端举行状态维护主要是通过磁盘或内存举行生存，好比MySQL数据库，redis等内存数据库。除了这两种类型的维护方式，另有jvm的内存的状态维持，但jvm的状态生命周期通常很短。
高可用的一些解决方案高可用，从生长来看，大致经由了这几个历程：冷备双机热备同城双活异地双活异地多活在聊异地多活的时候，还是先看一些其他的方案，这有利于我们明白许多设计的缘由。冷备冷备，通过停止数据库对外服务的能力，通过文件拷贝的方式将数据快速举行备份归档的操作方式。
简而言之，冷备，就是复制粘贴，在linux上通过cp下令就可以很快完成。可以通过人为操作，或者定时剧本举行。
有如下利益：简朴快速备份（相对于其他备份方式）快速恢复。只需要将备份文件拷贝回事情目录即完成恢复历程（亦或者修改数据库的设置，直接将备份的目录修改为数据库事情目录）。愈甚，通过两次mv下令就可瞬间完成恢复。
可以根据时间点恢复。好比，几天前发生的拼多多优惠券毛病被人刷掉许多钱，可以凭据前一个时间点举行还原，“挽回损失”。
以上的利益，对于以前的软件来说，是很好的方式。可是对于现如今的许多场景，已经欠好用了，因为：服务需要停机。
n个9肯定无法做到了。然后，以前我们的停机冷备是在破晓没有人使用的时候举行，可是现在许多的互联网应用已经是面向全球了，所以，任何时候都是有人在使用的。数据丢失。
如果不接纳措施，那么在完成了数据恢复后，备份时间点到还原时间内的数据会丢失。传统的做法，是冷备还原以后，通过数据库日志手动恢复数据。好比通过redo日志，愈甚者，我还曾经通过业务日志去手动回放请求恢复数据。恢复是极大的体力活，错误率高，恢复时间长。
冷备是全量备份。全量备份会造成磁盘空间浪费，以及容量不足的问题，只能通过将备份拷贝到其他移动设备上解决。所以，整个备份历程的时间其实更长了。
想象一下天天拷贝几个T的数据到移动硬盘上，需要几多移动硬盘和时间。而且，全量备份是无法定制化的，好比只备份某一些表，是无法做到的。如何权衡冷备的利弊，是每个业务需要思量的。
双机热备热备，和冷备比起来，主要的差异是不用停机，一边备份一边提供服务。但还原的时候还是需要停机的。
由于我们讨论的是和存储相关的，所以不将共享磁盘的方式看作双机热备。Active/Standby模式相当于1主1从，主节点对外提供服务，从节点作为backup。通过一些手段将数据从主节点同步到从节点，当故障发生时，将从节点设置为事情节点。数据同步的方式可以是偏软件层面，也可以是偏硬件层面的。
偏软件层面的，好比mysql的master/slave方式，通过同步binlog的方式；sqlserver的订阅复制方式。偏硬件层面，通过扇区和磁盘的拦截等镜像技术，将数据拷贝到另外的磁盘。
偏硬件的方式，也被叫做数据级灾备；偏软件的，被叫做应用级灾备。后文谈得更多的是应用级灾备。双机互备本质上还是Active/Standby，只是互为主从而已。
双机互备并不能事情于同一个业务，只是在服务器角度来看，更好的压榨了可用的资源。好比，两个业务划分有库A和B，通过两个机械P和Q举行部署。那么对于A业务，P主Q从，对于B业务，Q主P从。
整体上看起来是两个机械互为主备。这种架构下，读写分散是很好的，单写多读，淘汰冲突又提高了效率。其他的高可用方案还可以参考各种数据库的多种部署模式，好比mysql的主从、双主多从、MHA；redis的主从，哨兵，cluster等等。
同城双活前面讲到的几种方案，基本都是在一个局域网内举行的。业务生长到后面，有了同城多活的方案。
和前面比起来，不信任的粒度从机械转为了机房。这种方案可以解决某个IDC机房整体挂掉的情况（停电，断网等）。同城双活其实和前文提到的双机热备没有本质的区别，只是“距离”更远了，基本上还是一样（同城专线网速还是很快的）。
双机热备提供了灾备能力，双机互备制止了过多的资源浪费。在法式代码的辅助下，有的业务还可以做到真正的双活，即同一个业务，双主，同时提供读写，只要处置惩罚好冲突的问题即可。需要注意的是，并不是所有的业务都能做到。
业界更多接纳的是两地三中心的做法。远端的备份机房能更大的提供灾备能力，能更好的反抗地震，恐袭等情况。
双活的机械必须部署到同城，距离更远的都会作为灾备机房。灾备机房是差池外提供服务的，只作为备份使用，发生故障了才切流量到灾备机房；或者是只作为数据备份。原因主要在于：距离太远，网络延迟太大。
图1 两地三中心如上图，用户流量通过负载平衡，将服务A的流量发送到IDC1，服务器集A；将服务B的流量发送到IDC2，服务器B；同时，服务器集a和b划分从A和B举行同城专线的数据同步，而且通过长距离的异地专线往IDC3举行同步。当任何一个IDC当机时，将所有流量切到同城的另一个IDC机房，完成了failover。当都会1发生大面积故障时，好比发生地震导致IDC1和2同时停止事情，则数据在IDC3得以保全。
同时，如果负载平衡仍然有效，也可以将流量全部转发到IDC3中。不外，此时IDC3机房的距离很是远，网络延迟变得很严重，通常用户的体验的会受到严重影响的。图2 两地三中心主从模式上图是一种基于Master-Slave模式的两地三中心示意图。都会1中的两个机。
本文来源：开云(中国)平台-www.bashangjidi.com
在线咨询