1. 缘起
单点master的设计会大大简化系统设计，何况有时候避免不了单点。
先看一个典型互联网高可用架构：
（1）客户端层：是浏览器或App，第一步先访问DNS-server，由域名拿到nginx的外网IP；
（2）负载均衡层：nginx是整个服务端的入口，负责反向代理与负责均衡工作；
（3）站点层：web-server层，典型的是tomcat或apache；
（4）服务层：service层，典型的是dubbo或thrift等提供RPC调用的后端服务；
（5）数据层：包含cache和db，典型的是主从复制读写分离的db架构。
在这个互联网架构中，站点层、服务层、数据库的从库都可以通过冗余的方式来保证高可用，但至少：
（1）nginx层是一个潜在的单点
（2）数据库写库master也是一个潜在的单点
2. 单点架构存在的问题
单点系统一般来说存在两个很大的问题：
（1）非高可用：既然是单点，master一旦发生故障，服务就会收到影响；
（2）性能瓶颈：既然是单点，不具备良好的扩展性，服务性能总有一个上线，这个单点的性能上限往往就是整个系统的性能上限。
3. 解决单点高可用
3.1 shadow-master
shadow-master（影子master）是一种很常见的解决单点高可用问题的技术方案。
shadow-master：顾名思义，服务正常时，它只是单点master的一个影子，在master出现故障时，shadow-master会自动变成master，继续提供服务。
shadow-master它能够解决高可用的问题，并且故障的转移是自动的，不需要人工介入，但不足是它使服务资源的利用率降为50%，业内经常使用keepalived+vip的方式实现这类单点的高可用。
（1）client会连接正常的master，shadow-master不对外提供服务；
（2）master与shadow-master之间有一种存活探测机制；
（3）master与shadow-master有相同的虚IP（virtual-IP）；
当发现master异常时：
shadow-master会自动顶上成为master，虚IP机制可以保证这个过程对调用方是透明的。
nginx与数据库的主库master可用类似的方式来保证高可用，只是细节上有些地方要注意。
传统的一主多从，读写分离的db架构，只能保证读库的高可用，是无法保证写库的高可用的，要想保证写库的高可用，也可以使用上述的shadow-master机制。
（1）两个主库设置相互同步的双主模式；
（2）平时只有一个主库提供服务，言下之意，shadow-master不会往master同步数据；
（3）异常时，虚IP漂移到另一个主库，shadow-master变成主库继续提供服务。
需要说明的是，由于数据库的特殊性，数据同步需要时延，如果数据还没有完成同步，流量就切到了shadow-master，可能引起小部分数据的不一致。
3.2 减少与点点的交互，是存在单点的系统优化的核心方向
既然知道单点存在性能上限，单点的性能有可能成为系统的瓶颈，那么，减少与单点的交互，便成了存在单点的系统优化的核心方向。
怎么减少与单点的交互，提供两个常见的方法：
3.2.1 批量写
批量写是一种常见的提升单点性能的方式。参考https://www.cnblogs.com/lujiango/p/9376796.html#_label7
3.2.2 客户端缓存
客户端缓存也是一种降低与单点交互次数，提升系统整体性能的方法。
3.3 水平扩展时提升单点系统性能的好方案
无论怎么批量写，客户端缓存，单点毕竟是单机，还是有性能上限的。
想方设法水平扩展，消除系统单点，理论上才能够无限的提升系统性能。
以nginx为例，如果来进行水平扩展？
第一步的DNS解析，只能返回一个nginx外网IP么？No，DNS轮询即时支持DNS-server返回不同的nginx外网IP，这样就能实现nginx负载均衡层的水平扩展。
DNS-server部分，一个域名可以配置多个IP，每次DNS解析请求，轮询返回不同的IP，就能实现nginx的水平扩展，扩展负载均衡曾的整体性能。
数据库单点写库也是同样的道理，在数据量很大的情况下，可以通过水平拆分，来提升写入性能。
但是，并不是所有的业务场景都可以水平拆分。
4. 总结
（1）单点系统存在的问题：可用性问题，性能瓶颈问题；
（2）shadow-master是一种常见的解决单点系统可用性的问题的方案；
（3）减少与单点的交互，是存在单点的系统优化的核心方向，常见方法是：批量写，客户端缓存；
（4）水平也是提升单点系统性的好方案。
884
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
