（二）高可用比高性能更复杂吗

一、高性能：对于超出平常很多的请求量，系统仍能及时的响应。

1.高性能是高并发吗

网上多篇博客有源头并不可考的说法：“互联网的架构设计有三高：高可用、高并发、高性能”

把高并发分门别类，虽然它与高可用、高性能有不少区别，但其实也有非常强的关联性。

只有在高并发时响应请求及时，才能让项目保持高可用。而不支持高并发，也就没有高可用的实现前提。

另外，高性能与高并发也有并集，相对来说，高性能的涵盖范围比高并发更加广，而高并发只注重细节化的单项技术。

2.技术难度在哪里

可以从以下两方面选择做负载均衡，分散请求并保证高性能：

①硬件：考量服务器的地理位置；购买合理的配置

           优点：功能与性能强大；高稳定性；支持安全防护；

           不足：扩展性差；价格昂贵

②软件：需要有防护与监测系统；高效的算法；

       算法有以下几类：

                 1）任务平分类：采用轮询

                 2）负载均衡类：从服务器角度设计；

                 3）性能最优类：从客户端角度设计；

                 4）多次访问同一个服务器：用Hash值判断

           优点：简单；便宜；灵活；

           不足：性能一般；

       同时要了解使用工具的性能阀值，并按预估项目将会达到的调用量调整，让其发挥出最大的价值。

3.示例

比如一个投票系统，QPS峰值100次/秒，那么为防请求失败，设计应至少达到200次/秒，除了数据库查询增加的时间外，IO吞吐量上升带来的响应时间也会增加，而用户的体验仍要保证是毫秒级别的无感差别，这样实现了才算是高性能。

我们大多数经手开发的项目并不需要高性能，甚至于一个OA系统单台服务器也是足够的了，并没有足够多的诸如mongoDB、hadoop等大数据项目才需要的存储工具运用经验，其实我们自己可以接触到这些工具，那就是购买特价云服务器。腾讯云、百度云、阿里云以及比较经济的新浪云，都偶尔会搞促销活动，重要的是云上带有一些比较前沿的技术，如可按天收费的Redis与MQ中间件，学着运用的话至少可以填补这方面的空白。

二、高可用：任何时候，系统都可用并能响应请求。

1.衡量指标只有系统可用时间吗

简单来说是的。但我们一般会根据实际情况考虑，因为不是所有项目都需要高可用。

2.技术难度在哪里

系统持续可用时间自然是越长越好，可是越长实现的难度就越大。一般系统都有足够的容灾设计，但宕机都是不可预测的，原因也千奇百怪，按预想情况进行的设计也不总是完美的。

高可用即意味着彻底告别单点服务，即使服务稳定的阿里云也会有升级硬件而强制重启服务器的时候，所以最好有一个备机作为冗余。按CAP理论，搭备机之前要做好分区与可用性的平衡。作为一个软件产品，首先要满足系统的可用性，而在客户端使用时要满足数据一致性。可是当分区后，由于数据传输的必然延迟，无法100%及时同步，这就出现了在“分区容忍”范围内要满足系统运行要求的平衡点。

即使技术上无法完美解决分区与可用性的平衡，也需要尽量避免分区带来的影响。比如通过日志恢复，从而在一定时间后，系统也最终能够达到一致状态。

推荐一个排除架构可用性隐患的利器，FMEA（Failure mode and effcts analysis）结果分析方法：

              ①给出初始的架构设计图

              ②假设架构中某个部件发生故障

              ③ 分析此故障对系统功能造成的影响，组成部分有：

                     1)业务功能点

                     2)故障模式

                     3)故障影响

                     4)严重程度

                     5)故障原因

                     6)故障概率

                     7)风险程度

                     8)已有措施

                     9)规避措施

                     10)解决措施

                     11)后续规划

              ④ 根据分析结果，判断架构是否需要进行优化 

3.示例

还是投票系统，如果单台服务器线程数不够处理投票的请求，而投票量还在持续加大，就可能会出现投票请求无响应的情况，这时就需要考虑用集群了。

三、高性能与高可用难度比较

   对于一个投票系统，在技术上讲是及时做出合理响应难呢？还是搭建集群难呢？

   个人认为应该是前者难，从用户看到界面、发出请求、系统处理请求并返回数据这整个链路任何一点都不能出问题，难度是乘级的。

   而后者只需要集群中的其中一台能够响应服务即可，难度是加级的。且实现并不复杂，简单如mysql数据库的主备搭建，目前都已经有比较成熟的功能支持。

可搭建的常见双机架构设计有：

      ①主备复制

              1.互连式：主备机直接传递状态

                缺点：传递通道本身故障会造成双主机

              2.中介式：主备机通过中介来传递

                优点：主备机作为中介的客户端，降低了连接复杂度；故障时中介及时调整主备机角色

                缺点：中介出现故障则没有主机；而要避免则只能设计中介的高可用方案              

             3.模拟式：备机模拟客户端访问主机，状态决策基于有限的响应信息

               优点：切换简单，并且客户端无感知

               缺点：备机有硬件上的浪费，故障需要人工干预

       ②主从复制

           优点：读操作发挥了硬件的性能

           缺点：复杂度比主备高，客户端感知主从关系；数据延迟可能会出现问题；故障需要人工干预

       ③主主复制：两台主机的数据双向复制，因双主数据无法完全复制，适用于临时性可丢失的场景（例如论坛草稿）

搭建时需要注意的点：

              1.均衡性：每个集群数量应差不多

              2.容错性：故障时，分配故障区数据分区给其他服务器

              3.可伸缩性：自动迁移数据到新服务器