1、需求来源

显然，架构要求高可用，那么为什么系统会出现单点呢？

答：单点主控的设计会大大简化系统设计，即使有时单点无法避免

什么场景下会出现单点？ 我们来看一个典型的互联网高可用架构。

典型的互联网高可用架构：

(1)客户端层，这一层是浏览器或者APP，第一步是访问DNS-服务器，从域名中获取nginx的内部IP

(2)负载均衡层，nginx是整个服务器的入口，负责反向代理和负载均衡

(3)站点层，Web服务器层，通常是tomcat或apache

(4)Service层，服务层，一般是dubbo或者thrift提供RPC调用的前端服务

（5）数据层，包括cache和db，一般是主从复制、读写分离的db架构

在这个互联网架构中，站点层、服务层、数据库从库都可以通过冗余的方式保证高可用，但至少

(1)nginx层是潜在的单点

(2)数据库写数据库master也是潜在的单点

再举一个GFS（GoogleFileSystem）框架的例子。

GFS的系统架构中主要有以下几个角色：

(1)客户端，即发起文件读写的调用端

(2)master，这是一个单点服务，它有全局业务，掌握文件元信息

(3) chunk-server，实际存储文件的服务器

在这个系统中，master也是单点服务，Map-reduce系统也有类似全局协调master单点的角色。

在系统架构设计中，nginx、db-master、gfs-master等单点服务会存在哪些问题，有哪些解决方案来优化？ 这些都是本文要讨论的问题。

2、单点架构的问题

单点系统一般有两大问题：

(1)非高可用：由于是单点，一旦master出现故障，服务就会受到影响

（2）性能困境：由于是单点，不具备良好的扩展性，所以服务性能总是存在上限。 这个单点的性能上限往往就是整个系统性能的上限

拿出来，我们看看有什么优化方法可以优化上面提到的两个问题

3、Shadow-master解决单点高可用问题

Shadow-master是解决单点高可用问题非常常见的技术方案。

“影子主控”，顾名思义，当服务正常时，它只是单点主控的一个影子。 当master出现故障时，shadow-master会手动成为master并继续提供服务。

Shadow-master可以解决高可用的问题，并且故障转移是手动的，无需人工干预，但缺点是使服务资源的利用率降低到50%。 业界经常采用keepalived+vip的形式来实现这种单点高可用。

以GFS master为例，当master正常时：

(1) 客户端会连接普通master，shadow-master不会对外提供服务

(2)master和shadow-master之间有生存检测机制

（3）master和shadow-master具有相同的虚拟IP（virtual-IP）

当发现master异常时：

Shadow-Master会手动成为Master，虚拟IP机制可以保证这个过程对于调用者来说是透明的

不仅是GFS和MapReduce系统中的主控master，nginx也可以使用类似的方法来保证高可用，数据库的主数据库master（主库）也可以使用类似的方法来保证高可用，但是有有一些需要注意的细节：

传统读写分离的一主多从DB架构只能保证读库的高可用，而很难保证写库的高可用。 为了保证写库的高可用，还可以使用上面提到的shadow-master机制：

(1)双主模式，即两个主库设置为相互同步

（2）一般情况下，只有一个主图书馆提供服务。 含义是shadow-master不会向master同步数据

（3）异常时，虚拟IP漂移到另一个主库软件高可用性，shadow-master成为主库继续提供服务

需要注意的是，由于数据库的特殊性，数据同步需要信噪比。 如果数据尚未同步，流量会切换到shadow-master上，可能会造成少量数据不一致。

4、减少单点交互是单点系统优化的核心方向

既然我们知道单点的性能是有上限的，那么单点（比如GFS中的master）的性能可能会成为系统的困境。 因此，减少与单点的交互成为单点系统优化的核心方向。

如何简化与单点的交互，这里介绍两种常用的技巧。

批量写入

批量写入是提高单点性能的常用方法。

例如使用数据库编写单点生成“ID生成器”的反例：

(1)业务方需要身份证件

(2)使用数据库写单点autoincreamentid后世并返回ID

这是很常见的情况，很多公司都是通过这种方式生成ID的。 它利用了在数据库中写入单点的特性，方便快捷，并且没有额外的开发成本。 这是一个非常可爱的解决方案。

潜在的问题是：ID生成的并发上限取决于单点数据库的写入性能上限。

如何提高性能？批量写入

（1）中间添加一个service，每次从数据库拉取100个id

（2）业务方需要身份证件

（3）服务直接返回100个id中的一个，100个全部分配完后，访问数据库

这样每分配100次就会写入一次数据库，分配id的性能可以认为提高了100倍。

客户端缓存

客户端缓存也是减少单点交互次数、提高系统整体性能的一种方式。

还是以GFS文件系统为例：

（1）GFS调用client客户端访问shenjian.txt，首先查询本地缓存，miss

（2）客户端访问master询问文件在不在，master告诉客户端在chunk3上

（3）客户端将shenjian.txt存储在chunk3中并记录到本地缓存中，然后读写该文件

（4）以后如果客户端要访问该文件软件高可用性，从本地缓存中找到对应的记录，就可以直接访问chunk-server，而不需要请求master。 如果文件被传输，chunk3返回给客户端说“文件不再在我这里了”，然后客户端访问master来询问服务器文件所在的位置。

根据经验，这种类型的缓存命中率非常高，可能达到99.9%以上（因为手动迁移文件的概率很小），因此与master的交互次数增加了1000倍。

5、水平扩展是提高单点系统性能的好方案

无论批量写入、客户端缓存，即使单点是单机，仍然存在性能限制。

理论上，只有想办法横向扩展，消除系统中的单点，才能无限完善系统。

以nginx为例，如何水平扩展？

第一步DNS解析只能返回一个nginx内网IP吗？ 答案其实是否定的。 “DNS协程”技术支持DNS-server返回不同的nginx内网IP，从而可以实现nginx负载均衡层的水平扩展。

对于DNS-server部分，一个域名可以配置多个IP。 每次进行DNS解析请求时，协程都会返回不同的IP，从而可以实现nginx的水平扩展，扩展负载均衡层的整体性能。

数据库单点写入也是如此。 在数据量较大的情况下，可以采用水平分割的方式来提高写入性能。

遗憾的是，并不是所有的业务场景都可以水平拆分。 比如秒杀业务中，条目数量可能不会很多，数据库的数据量也不大，因此无法通过水平拆分来提升秒杀系统的整体写入性能（不可能一个库中有 100 条记录，对吧？）。

六、总结

明天的话题讨论到此结束。 内容较多，占用您宝贵的时间，敬请谅解。 恐怕我不记得其中的大部分了。 至少记住以下几点：

(1)单点系统中的问题：可用性问题、性能困境

(2)shadow-master是单点系统可用性问题的常用解决方案

(3)减少与单点的交互是系统单点优化的核心方向。 常见的方法有批量写入和客户端缓存

（4）水平扩展也是提高单点系统性能的一个很好的解决方案

如果您有什么收获，请帮忙转发。

==【完】==

返回【搜索】

返回【钱包】

返回【留言】

返回【秒杀】

返回【设置】

回来[延迟]

返回【推荐】

【小游戏：返回小于10的整数，随机返回一篇好文章，猜猜怎么实现】

欢迎讨论，解答各种问题。